3 Myths about Release and Deployment Management
At Urbancode, our AnthillPro and uDeploy products are often used primarily by Release and Deployment teams. As we work with our customers, who have or are considering creating these teams, we encounter a handful of misconceptions about the practice.
Release and Deployment Management can’t be Agile
Many release management teams act as gate-keepers and many release teams require excessive documentation in order to approve a deployment to production. However, the trend in the industry is towards increased agility. Release managers less and less as gate keepers and increasingly, facilitating Development – Operations cooperation.
As this DevOps approach takes hold with practices such as automated provisioning and deployment, the deployment team is better able to keep pace with the Agile development teams.
We need consistent, massive controls
We absolutely need some controls, especially for mission critical, chain of care, or financially sensitive applications. However, we don’t need the same sort of rigor around some of our internal applications.
Most of our applications aren’t going to make or break our companies, or be responsible for people’s lives. Change control and release management teams should be able to identify applications which can follow more streamlined release processes that require minimal sign-offs and checks allowing the business to derive value from development more quickly and easily.
Release Management is Everywhere
Release management is still an emerging, and highly varied, practice. It seems to emerge within organizations as architectural and team complexity grows. When the knowledge of how a system hangs together, and what the runtime inter-dependencies are becomes widely distributed, release managers are usually tapped to provide a level of coordination. The shape of that coordination still varies a great deal.
For more on this topic, see our recent webcast on ITIL, Release Management and DevOps.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)