4 ms·
> You may only continuously deploy to an environment before ‘Prod’ – UAT/Pre-prod…, but the environments you do deploy to should be ‘production-like’, so you kn
by wdewind 13y ago
> You may only continuously deploy to an environment before ‘Prod’ – UAT/Pre-prod…, but the environments you do deploy to should be ‘production-like’, so you know with very high confidence, that the final deploy to production will work without issues, when you do really need to deploy to it.
In my experience this is a pretty dangerous way to think about it. One of the best reasons for continuous deployment is to allow you to push small changes to production. This is desirable because small changes are easier to debug when things go wrong, and are less likely to make things go wrong overall. But the core assumption behind this is "the system is really complicated and has a ton of moving parts that are virtually impossible to think about at all times." Continuous delivery makes the assumption that a preprod environment is highly likely to be similar to a prod environment, and making that true is usually extremely hard at scale. Couple that with the fact that prod will (especially for large, consumer facing sites) often expose you to many more edge cases, and the fact that a developer who has pushed to preprod may not be there to help debug when his or her code finally gets to prod and breaks things, I see continuous delivery as a pretty suboptimal alternative to continuous deployment.
- nimblegorilla 13y agoComing from a banking and healthcare background it seems pretty suboptimal to build a process around waiting for stuff to break in production. It also seems rare to find bugs in production that cannot be replicated on developer machines so I don't think getting an exact match on the preprod environment is a huge obstacle.
- wdewind 13y agoThe important part is being able to push very small changes without it slowing you down (you need a quick and easy deploy process). If you have a small change, it is easily testable, and the chance of it breaking something is small. The goal isn't to discover bugs on production, it's to make it extremely easy to fix bugs on production. Continuous delivery batches up many small changes and thus makes it more difficult to figure out what exactly the issue is when you discover one. I have yet to see a process that is able to release bug free code, so knowing that bugs do get to production as a matter of life, it is highly optimal to make your process make those bugs easier to fix. Ultimately you end up with fewer bugs, when you do have bugs they have smaller impact, and when you need to fix them they are easy to track down and fast to change. Getting an exact match on preprod is extremely difficult when you have a relatively complex data environment (sharding etc.), a relatively complex build environment (assets built differently in production than dev) etc.
- nimblegorilla 13y agoI still don't believe it's that hard to create a preprod that matches production. What kind of asset generation are you talking about that can only run on the production server? Is continuous deployment just something for teams that don't know how to make a copy of their production server?