for dealing with compliance. By tightly integrating release management into your change and configuration management practice, you build the capability to deal with larger change volumes, and demonstrate key compliance criteria, including:
- What business requirements are addressed?
- Which artifacts make up this release?
- Who developed the artifacts contained in the release?
- Who approved this release for each environment it was promoted to?
- When was it delivered to production?
- If a failure occurred, what action took place?
Plan Your Release Management Process
A starting point for release management is to define the requirements your organization has for a solution.
- What kind of platforms do you need to release to, do you need to support legacy environments?
- Does an active SOA strategy how is SOA being adopted today?
- What are your objectives in adopting formalized release management practices, efficiency, greater collaboration amongst teams or a need to better meet compliance goals?
With a clear set of requirements defined you can be realistic about what you hope to achieve and the necessary steps to achieving your objectives.
It is also important to leverage existing methodologies or industry practices where they fit. ITIL and other industry accepted frameworks for change, configuration or release management can provide a solid footing for implementation, but you need to be sure that they realistically align to the way your IT team needs to function.
Change and Configuration Management
The next logical step in defining a release management solution is ensuring you have adequate change and configuration management practices in place. It is important to ensure that the appropriate balance of change and configuration management tool support exists to support all of the environments that your IT project may span. This is especially true where multi-platform dependencies exist. Without a solid change and configuration management footing, anything that is released into a production or pre-production environment will be suspect.
Integrated Deployment Support
With the appropriate CM tools and policies in place organizations should look to achieve integrated deployment support, where the deployment of artifacts only occurs with the appropriate change approvals using secured configuration management baselines.
Technologies for deployment should be selected based on their ability to scale within your organization and their ability to form an integrated release management solution. Managing high volumes of change is about having the right tools in place, forming an integrated scalable solution in order to deal with the magnitude of change you face.
Automating the Deployment Practice
Once you've achieved integrated deployment in your change and configuration management environment, automation should be a key objective in order to drive further efficiency and to reduce risk.
Automation can be employed to reduce risk exposure and to force teams to work in a more repeatable manner. On the surface project teams and teams on differing platforms will appear to work in a unique manner, by initiating an automation project you will be forced too examine the commonalities.
Automating the deployment of change is one area to focus on, but of equal importance is the automated rollback and recovery. Consider the scenario where a release to production fails, as the result of a software defect or perhaps due to a lack of capacity on the production system. How do you invoke rollback and recovery in this scenario? In many cases if rollback doesn't occur in a timely manner, a disruption to business including potential financial penalties may be incurred. By automating your rollback and recovery procedures you are eliminating the scramble for resources to fix production issues and reducing your overall risk exposure.
When you stand back and look at the whole