What Is vs What Should Be

Along the lines of "What is it We Do Again?":

• Product Management is all about what should be;
• Release Management is all about what is.

It is very easy to get the two confused. For example:

• You build a piece of software after a developer commits a fix. The bug should be fixed. Is it?
• You deploy a war file to a tomcat server. The service should be updated. Is it?
• ...

It is very easy for release managers to go and push buttons, and then infer that the buttons did their job - and 99% of the time they will be correct, but every once in a while, things break.

It's therefore very important to always locate the source of truth for any statement you wish to make.

For example, in my previous post describing my tagging process, I do something which appears to be bizarre: I go and retrieve build manifests from the actual production sites and use those as my source of truth for tagging the source trees.

The reason I do it that way is that I have a fairly bullet-proof chain of evidence to prove that the tagged revisions truly are in production:

• The build manifests are created at build time, so they reflect the revisions used right then;
• The build manifests are packaged and travel along with every deploy;
• The build manifests can only get to the target site via a deploy;
• The build manifests contain hash signatures that can be run against the deployed files to validate that the manifest matches up with the file.

So, retrieving a build manifest from the production site gives me very high confidence that the revisions referenced are in production.

Consider common alternatives:

• Tag at build time. Problem becomes identifying the tag actually deployed to production - so this doesn't really solve anything.
• Rebuild for deploy. Problem becomes identifying the source tree configs used by QA. In addition, can you really trust your build system to be repeatable?

My method of relying on what is gives our QA team a wide variety of options on how to proceed:

• They can release pieces incrementally as they pass QA;
• They can try different combinations of builds;
• They can roll back to previous builds;

Now there is a problem still: it might take a while to collect the truth, and as we saw with in the tagging of shared code, the truth can be quite messy at time. Hence the importance of timestamping your data, so at least you can say "this was the truth as of yesterday at noon".

The complexity of modern software as a service environments isn't going away, and we will need to get used to the idea of many versions of the same thing co-existing in a single installation. The fewer assumptions made in the process of presenting the state of these installations, the better.