4 ms·
Assuming your project supported continuous development, I'd probably say you should break that project up into multiple deployments, ideally hidden behind a fla
by mrdonbrown 6y ago
Assuming your project supported continuous development, I'd probably say you should break that project up into multiple deployments, ideally hidden behind a flag and each easily revertable. This would reduce the risk of each step and hopefully eliminate a whole host of potential incidents.
- inertiatic 6y agoHow does code hidden behind a flag become less risky if it's deployed in increments? You will only find out when you allow it to run.
- mrdonbrown 6y agoWell, for example, say you were adding a new preference page. First, I'd do a deploy of the new database table(s), even though they aren't used. Then, I'd add a link to the page in the UI and put that behind a flag, maybe with a small non-functional UI so that the designer could play with it. Then, I'd implement the basic functionality and open it up to my team to start playing with it. Then, I'd ship other deploys for things like tests, more edge cases, UI tweaks, etc. At some point in there, I'd open that page up to my beta customers, trial customers, or whoever is less risk-adverse. Once I'm happy with it, I'd do a percentage rollout to ensure any issues don't affect all customers at once. Just an example, but the idea is to reduce risk of each step and make each step easily reversable/hidden if something comes up.
- cced 6y agoIt's not, and it cannot ben deployed in increments. What OP and many people are missing is that a lot of us don't work on cool and hip new apps. Some people aren't in a osition to push incremental changes to a payroll system.
- mnm1 6y agoSo release for release sake. Push it to production to make the release quota but hide it because it's incomplete and doesn't work. What's the point of that theater?
- LaurensBER 6y agoReduce the scope of each deployment which results in deployments being predictable and safe.