Managing the release-and-deployment process can be very difficult to accomplish in high-risk environments. It's also precisely where you have the greatest potential for reward. I have had some spectacular successes as a release-and-deployment manager and no shortage of painful moments, too. Sometimes, it seemed that I had the magic to tame the most savage release scenario, and other times I couldn't move the needle and show any significant improvement at all. I have learned a lot from these experiences, and this article discusses what I consider to be release management and deployment essentials.

Stepping into the Line of Fire
My approach to fixing the processes around release management and deployment has always focused on stepping right into the line of fire and assuming the role of the release-and-deployment manager. This isn't always practical, as sometimes I am asked to come in on a consulting basis simply to observe and advise. I have done this job enough times that I often know exactly what needs to be fixed. Unlike most process improvement folks, I really prefer to get hands-on and make recommendations directly from my own experience. That puts me at great risk for failure.

Failing as the Release Manager
When writing the chapter “Mistakes that I Have Made” in my book Configuration Management Best Practices [1], I noted that I could have written a whole book describing my own mistakes. But, the reason that I have been successful in CM is, in part, because I was willing to take risks, which also resulted in my recommendations often being precisely what needed to be done to fix the problem. Understanding release management and deployment essentials is a lot easier when you look at a few failures first.

Knowing When to Ask for Help
I love being hands-on and technical, which is a good thing, but technology can be very complex. Developers spend years getting up to speed in different development frameworks and methodologies, yet I may work on automating release management in C#/.NET one day and on IBM mainframe deployments the next. Within the past three months, I have worked on developing release practices for software as a service for customer relationship management (CRM), data warehousing, databases, and complex Java J2EE N-tier applications with WARS and EARS running under a variety of web and application servers. It is certainly nice if you have a development background with the technology that you need to automate, but you also need to know when to ask for help. It is essential for you to ascertain and communicate what you need in order to be successful with the release-and-deployment process.

Involve the Developers
Developers are often very busy and sometimes not very open to being told to do things differently. It may seem prudent to just handle the work yourself, but I have learned that sometimes it is better to share the work with developers and show them that improving the release-and-deployment process is in their best interest. For example, it is essential to have procedures identifying the version of every configuration item (CI). Being able to conduct a physical configuration audit often requires embedding an immutable version ID into the CI. For example, in C++, you usually create a static char variable via a global header file and stamp the version ID at the time of the build. (Search CM Crossroads for articles showing how to do this.) In Java, we tend to create a class that returns the version or, even better, we stamp it into the JAR (WAR or EAR) manifest and provide a method for pulling out this value.

Communicate Early and Often
Effective communication with all stakeholders is also essential in release management and deployment. Ensuring that all stakeholders understand their roles and deliverables is obviously critical, but I have also found that communicating obstacles and challenges can help, especially when seasoned colleagues have experience dealing with these challenges and may even offer to assist.

Don't Try to Boil the Ocean
Usually, you cannot automate the entire effort overnight. I start by documenting the manual process and then automating pieces, effectively reducing the size of the manual checklist. This is a very pragmatic approach and shows immediate results. Your goal must be to automate the entire approach in what one leading vendor is calling “zero-touch deployments.” Using a deployment framework that provides the structure around each piece of the automation you have created is an effective way to manage this effort.

Moving Upstream
I’ve learned to always move this effort upstream as quickly as possible. You will be much more successful if you can provide a service to developers. Release management and deployment usually is required to take over by the time the release is ready for production. It is much better to get involved earlier, when the release is ready for QA and user acceptance testing. Better still is to get involved during the development effort using your automation to build, package, and deploy to develop test regions. This is precisely where continuous integration has shown the most value.

Conclusion
Taking some lessons from agile and lean, it’s best to develop your release management and deployment processes in an iterative and pragmatic way. I try to keep my processes as light as possible, with automation that is structured and can be refitted easily as requirements change. I also try to start at the beginning and provide a service to the developers. Release management and deployment practices are essential for your success. Please drop me a line and share some of your own release management and deployment essentials!

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment