Last week we looked at the crazy things people insist are the lore of Release Management. This week we continue to highlight so called “truths” and debunk them. My goal here is to put you in charge of determining what Release Management is. After all, you’re the one on the hook for making it happen!
5: Not every change needs to go through the release management process – wrong!
Every change needs to go through some process of verification (testing) and approval. However, it doesn’t necessarily mean that every change goes through the same process. Emergency fixes need a fast-track process with minimal stage gates and approvals. Major releases need more rigorous processes and complete stage gates.
4: A release management infrastructure will slow down my project – wrong!
Imagine if there were no air traffic controllers (ATC’s): would the free-for-all that ensues be good for on-time departures and arrivals, would it be safe, would stakeholders be happier, would it be quicker? Of course not. In fact, the point of ATC is to improve the throughput of flights to maximize the use of the runways. The same is true of release management. Without the infrastructure in place, you will never be able to deal with the volume of changes, the complexity of the dependencies between releases and the competing needs of the many stakeholders. With the right release management solution, you can increase the number of releases you deploy, improve control and governance, eliminate errors and downtime and do it with fewer resources.
3: We cannot make our releases any smaller – wrong!
A major reason why release management has become more complex is because the size of the releases has increased to a point now where they are often bigger than the original system they are based upon. This size means that the releases are very difficult to test and the inter-dependencies of other changes in other projects in the release make it nearly impossible to have any confidence in the testing outcome. Many organizations are taking a leaf from the Agile-playbook and moving to smaller, incremental releases more often. By breaking the release into dependent and non-dependent changes, it improves the testability of the code and the deployment is no longer held up waiting for other changes. Also, moving to thematic releases, keeping the changes to a small area of the code base, improves the ability to test and deploy with confidence.
But many more releases cannot be achieved without automated infrastructure in place. One release manager told me that they were moving from 4 releases per year to 3 releases per year because “it is taking too long to test and deploy.” When I asked the business what they wanted, they told me “more stuff sooner.” The answer is not bigger releases less frequently; it is smaller releases more often. And that is only possible through automating release management processes.
2: The business wants us to change things less frequently – wrong!
No they don’t. What they want is that the changes are deployed more successfully. Think about your smart phone: you get updates every day; you have become the release manager on your own device. You now update without caring because you know the changes are small, unlikely to disrupt the functioning of your device and are, in short, safe. We need to get the business to have that same confidence in our releases. Small changes more frequently are easy for users to absorb, have a smaller impact, require little (if any) training, are easier to test and, generally, low risk. The business gets to prioritize the changes they want and constantly adjust those priorities almost up to the point we put things into production.
1: Developers won’t accept not having access to production– wrong!
With the requirement for the “separation of duties” now being the law, the very idea of anyone having access to the production area seems very 20th century. Still, in many organizations, for whatever historic reasons, many people have access to the production areas and they use this privilege wisely and carefully. But the time for this has to stop! Now! As we have seen, the addition of a layer of process automation improves the speed of the release process and improves the audit trail. In an emergency outage situation, the first question anyone asks is “what changed?” Unapproved changes, even those with the best of intentions, are often undocumented changes. Even if they are not the cause of the outage, the inconsistencies they represent hinder and delay the analysis and remediation of the problem. If someone needs access, then ensure there is a process to let them have it, with appropriate approvals and a mechanism to withdraw it when the need has gone away.
I hope you have enjoyed some of these thoughts. Please share your own debunking examples of the “rules” of release management.
|Kevin Parker is a 30 year industry veteran, holder of three technology patents and is VP of Worldwide Marketing at Serena Software. He speaks and writes on application development methodologies, business analysis, quality assurance techniques, governance, open source issues, and tool interoperability, from the mainframe to distributed platforms to the web and mobile and embedded systems.|
[...] 원문: http://www.serena.com/blog/2013/07/enterprise-release-management-the-top-10-myths-part-two/ [...]
My query is, what is the risk in case we skip the gate date e.g. if as per gate the changes are supposed to move on 20th but the project wants the changes to be moved on the 10th itself. do you see any risk in this?
Perry that’s a great insight. Impact analysis has become one of the most critical tasks facing release managers and build engineers. We need to increase the cadence of delivery so that the changes are small, incremental and (wherever possible) have little to no dependency on other changes. This gives us the confidence that the risk is low and allows us to adjust the delivery dates more easily to meet the ever changing exigencies of the business.
Of course it is not possible to achieve small, incremental and dependency-free releases too often these days. This is why release automation is critical. Here at Serena we have a technology designed to track dependencies in releases both application-to-application and intra-application dependencies. This means that you can choose part of a release and change it’s delivery date and have the solution report back what the impact will be of the date change on other releases yet to be deployed and on the ones already deployed. By having the release monitored and controlled by a Release Management Solution you can track the release through the lifecycle and be notified when dependencies are shifting so you can, if needed, remediate the code to eliminate the undesirable consequences.
Thanks for the great question.