Over the last few years providing ALM* services and eventually creating InRelease, I came to discover a few fundamentals around which we are building our product. The first such fundamental I call the “First Law of Deployments”, and here it goes:
Okay, any ops person will agree with this readily (probably telling themselves – can he be more obvious?). Actually, this is not as clear to everyone as one would think. There are a few reasons for that.
We have been hearing about build-test-deploy, and this is always a little confusing. The typical release cycle, at a very high level, is to build,test and then deploy to production. More or less like this:
And this is true at 10,000 feet, it is a bit of an oversimplification. When we look at it closer, the process often look more like this:
This is an example of releasing through 3 stages (ex: dev,integration,staging) prior to hitting production – with one bug fixed after being discovered in the first validation stage.
There are 2 main points on that diagram. First, in order to make sure that the version that goes to prod is the same code as was tested in previous environments, we do not re-build the code between stages. Instead, we promote the same binaries to all the environments and can ensure traceability from the original build to production.
Where things get confusing is that on each stage, we do a deployment and a test run. Actually, when teams do not promote binaries but re-build the code for each stage, they end up with a build-deploy-test loop inside the stages. This makes the vocabulary somewhat confusing.
The second point in that diagram is that the deployment to prod is a fundamentally different than the preceding ones, as stated in the First Law. That’s why I renamed it Prod Deploy on the diagram.
Here are some additional requirements for production deployments:
You cannot take prod down for long, if at all. In dev, you can.
In Prod, If a deployment fails, you need to fail elegantly and be able to rollback quickly. You can’t just re-create the environment as you would in dev.
In Prod, you need to preserve and protect the existing data. In dev, not so much.
In Prod, you need to configure the infrastructure, not just re-create it.
In Prod, you have server farms, mirroring mechanisms, and more dependencies. In dev, you can keep it simple (simpler?).
In Prod, you need to keep logs on everything so that you can investigate or diagnose if needed.
In Prod, you need to limit who can deploy what top preserve against fraudulent activities.
And, probably one of the most important ones:
In Prod – everyone can hear you scream! Really, they can. Prod deployment failures are always very public.
Hence the First Law of Deployments: Dev deployments ≠ Ops deployments
In fact, what we propose with InRelease is to use your prod deploy as early as you can in the development cycle so that it is tested over and over before hitting Prod.
Of course, to do that, you need to automate the deployments and you need to be able to transform the config files for each server, that’s what InRelease and other release automation products do. If you are interested in knowing more about how InRelease specifically implements this approach you can contact me or go to the InRelease Site.
*If you are reading my blog I assume that you probably know that ALM means Application Lifecycle Management. Well, if you didn’t…. now you do!