Catching up on thedailywtf after some time away, and I saw a non-WTF entry on release management. Call me boring and bland, but what interests me the most about programming and software engineering is the process behind it.
I haven’t “been around the block” much as of yet in my career, but it strikes me that no matter the size of the company, they probably have LOTS of room for improvement in their release management process. Small startup? Probably hasn’t thought about “release management” at all – the product is too small, there’s more important things to do, and it’s probably (in their minds) best not to inhibit developer productivity. Tech giant? Probably thought about it a lot (likely overthinking it), but only in terms of using it as a tool to improve the quality for the end user.
So, what do I think is important for a release management process?
One-step: However the release is built (and in the case of web apps, deployed), it should ideally be a one-step process. As in, you go to the website or log in to your build/deploy server, run “# build_and_deploy” and some amount of time later, it’s done. No configuration, no billion cli flags that you need to remember every time, just run it and done. If there are configuration parameters needed, they should be stored in (private) SCM somewhere, and the defaults already set. Overriding should be possible if needed. Alternatively (for web apps), if you’ve got a good set of automated testing tools for your code and infrastructure, the code could get deployed automatically after every push to the main source code repository.
Same steps for development and for production/releases: A new developer on your team should be able to build and test his setup in the same way that the build/deploy is done “officially” (with perhaps an extra parameter, e.g., “# build_and_deploy –dev”).
Components are isolated, and can be rebuilt individually: That is to say, if a developer makes a change to the authentication subsystem, “build_and_deploy” should notice that it only needs to rebuild that part. It should then package everything together – the already built stuff with the parts that were repackaged (see the daily WTF link), and deploy to production or a test bed for the developer.
Everything is included: The build and deployment process should understand every part of your system (for both ‘dev/testing’ and ‘production’) – application components, backing data stores, caching solutions, etc.
Everything should be reversable: Upgrading the database version? There should be a way to reverse it for your environment, and your deploy process should understand it. Changing the schema? Have a way to reverse it. Updating the app servers? Should be able to backout SCM changesets. And so on.
If you’re release process is missing these, I won’t call it “broken” – but I will say I think you’ve got room to improve.