Depending on your organization you may or may not have a formalized release management process. You may be handling this though some other process entirely, the question that you should be asking is whether the releases are managing you.
How can you tell if things aren’t going the way that you want them to? Firstly you probably are pushing code into production at a rapid rate (someone might say that this is agile but if the end result is more issues that smiling faces on the business end you are probably doing it the wrong way.
If this is you or you are not managing releases at all the next question why not? Generally the answer you will get is that it’s either really hard to do or that its complex. That might be the case but it doesn’t have to be so difficult.
You can make it as simple as you want. Start out with a specific portfolio of what services you want to include in your release process – watch out for scope creep! Once you know what you are including you will be able to prioritize the release and generate better planning.
Get into a rhythm. Figure out what works for you and your business. It might be quarterly, monthly, weekly or more often. The key is to ensure that you can manage what is in the release throughout the lifecycle from planning to deploy in production.
The point of release is to ensure that you are integrating all components of people, process and technology across your organization to produce consistent results for each release. Being able to control the regular flow of releases improves the likelihood of business satisfaction with the end result.
In order to do this you need to make sure that you are validating progress in each of the stages including; planning, design, development, and deployment into production.
Here are a few to check at each stage (there are others):
- Make sure the development and operations teams are included in the planning
- Ensure that any system requirements gave been vetted
- Ensure that the IT team has been notified of the upcoming deployment
- Has all the business input been reviewed
- Is the Service desk ready for the upcoming deployment
- Have we reviewed all the deliverables to validate completion
- Ensure all the tests are finalized
- Have SLA’s been reviewed where they apply
Overall before we get ready to deploy into production we should have a document which checks off and validates the following:
- What does the backup schedule look like
- What is the business continuity plan
- A completed network and infrastructure diagram for all environments
- Any security requirements have been addressed
- All of the hardware and software has been installed and a list of the assets
- Has the deployment had appropriate levels of communication
- Has training been provided where necessary
- Are staffing levels appropriate for the deployment from support including the Service desk and various tiers
Being able to address the simple questions will better position you and your teams to handle releases before they handle you.
Follow me on Twitter @ryanrogilvie or connect with me on LinkedIn