- Product Management is all about what should be;
- Release Management is all about what is.
- 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'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.
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?
- They can release pieces incrementally as they pass QA;
- They can try different combinations of builds;
- They can roll back to previous builds;
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.