3 ms·
> Don’t do CD as a tech/ego benchmark thing, however (or Facebook/Google envy). Do it if you can agree that this brings some benefits to the business This is a
by lhorie 6y ago
> Don’t do CD as a tech/ego benchmark thing, however (or Facebook/Google envy). Do it if you can agree that this brings some benefits to the business
This is a really important point. Rapid releases are not always inherently better. I used to work in a company that dealt with heavy regulatory bureaucracy (in the sense that putting out wrong/misleading information could result in class action lawsuits), and because of that, workflows were highly optimized for waterfall delivery. This meant aggressive reliance on classical project management tools and techniques, and hyper-specialization (as opposed to the sort of full stack engineer approach taken by many bay area tech companies) - and this has worked well for that company for decades.
You can also do hybrid approaches, e.g. continuous deployment to a QA environment, and have dedicated QA teams, while delivering to client on a waterfall schedule.
- bmhin 6y ago> You can also do hybrid approaches, e.g. continuous deployment to a QA environment, and have dedicated QA teams, while delivering to client on a waterfall schedule. I feel like this approach lets developers still spot check and make sure their code looks good when in QA while still giving the more anxious folks who need production to be holy to have their manual button press to get things live. Ideally, your pipeline is also at that point a simple button press to go from QA out to production. It also hopefully isolates any production issues to environmental differences as you will be in the "bundled changes" territory referenced in the article. From what I've experienced the FUD around letting things get into production rapidly really freaks out some organizations and having it hybridized is better than nothing.