There’s an age old saying in the world of Project Management – every project has three aspects – Risk, Cost and Time. The paradox is that you can deliver on no more than 2 at any given time.
DevOps however, promises to deliver all three – provided the practitioners understand what what each means. In this post, I will talk about what Release Risk means in today’s world.
- Release Risk talks about Integrity of the “Release Package” – a blackbox of disparate assets/artifacts that may be deployed to hybrid environments but together make up the whole Release Package. Enterprises today can guarantee that a particular Release artifact (lets call it “Deployment Unit” or “Release Unit”) was tested and released but as far as the whole package is concerned, that remains a mystery. Ability to create this immutable object, promote it from environment to environment and report on it is the key to determine Release Risk.
- Historical Data – how successful/problem ridden this particular Release has been determines how risky it will be this time around. Collection and display of historical data is a must to determine the risk of this release.
- Number of changes – The (new) content in the release is a critical factor in determining the risk. The greater the number of changes, the more risky the release is.
The three factors above, combined with the preliminary test results give a fairly accurate and quantifiable Risk associated with your releases.