Comment by derefr

6 years ago

You gotta CI/CD from somewhere. Whatever that somewhere is, it can go down.

You can, of course, override your CI/CD and do a manual deploy. It's not a matter of "can." It's a matter of not fully understanding all the checks the CI/CD system does to the code, and all the build steps for prod builds, and therefore not having the confidence to deploy to prod without CI/CD holding your hand. (Which I don't at-all blame devs in bigcorps for not knowing; release management is its whole own thing, and division of labor means that at sufficient scale it doesn't make sense to learn about it.)

2 comments

derefr

strenholme 6 years ago

Well, the place I run my CI tests is on a VMware virtual machine, e.g.

  #!/bin/bash -e
  git clone https://git.example.com/myrepo
  cd myrepo
  sh do.tests

If the tests are automated enough to run with every Git checkout, they can be easily enough be run by hand too.

The real world script I use is a little more complicated, because the code base in question is two decades old so I need to make some changes to how the code looks to the tests so that the tests can run.

I once worked for a company which had a series of tests which took eight to ten hours to run. Running those tests with every single Git checkin was out of the question; we instead used cron to run the tests every night.

throwanem 6 years ago

Part of the point of having release infrastructure is so that every engineer doesn't have to know how to manage a deployment, even. Having worked both with and without it, I have to say I favor the former. The occasional loss of productivity due to a service provider outage, or even due to whatever the hell's going on today, is vastly outweighed by the day-to-day baseline requiring next to no time spent on the mechanics of taking code from review approval to live in prod.