February 8, 2011
Ever hear about the "First Rule of Holes"? It's pretty simple — if you find yourself in a hole with a shovel, the first thing to do is…. stop digging!
That's kind of what it's like in app dev when it comes to release management: We've dug ourselves a pretty deep hole, and it's impacting our overall ability to ship software on time. We recently ran a survey of app dev professionals that confirms what we hear in our client inquiries: Most development leaders are frustrated with slow software delivery and their release management process (see Figure). While Agile speeds software design and development, it doesn't do much to speed up release and deployment — creating a flash point where frequent releases collide with slower release practices.
But some organizations have stopped digging themselves in deeper. They are working with their peers in operations to streamline release management and cutting steps into the side wall of their hole so that they can climb out, step by step. Here are five steps that they are taking:
- Investing in improving their pre-build processes. Many problems that occur during a release cycle have their root cause in inadequate pre-build tasks and activities.
- Expanding release management throughput. Projects that have large code bases or extensive testing cycles are using parallelism and intelligent testing processes to speed up the early stages of the release cycle.
- Optimizing their release pipeline. After taking care of the early stages of the release pipeline, advanced teams are implementing virtualization, parallel testing, and developer self service to further compress their release cycles.
- Architecting software for rapid change. Developers like to build software quickly but are not always as attentive to building software that they can change quickly. Improving system modularity and adopting a configuration-based release model can help improve the resilience of the release process.
- Creating common release portals. A release portal is a project's “home base”; it's where managers, testers, developers and even business stakeholders go to find out what's in the pipeline and when they can expect updates to the system.
If you're interested in some of the specific tactics that are behind these steps, check out the new research I've published on the topic.