Monday, 22 July 2013

Release Management

 This is my first blogs for all the guys who are interested in Software configuration Management(SCM).

Aim of this blog will be more into the Release Management and helps in implementation.

Main Objectives
The objectives of this section are to enable you to:
• Release Management concept and its benefits
• Release Management Process involvement
• Release Management Person roles and Responsibility

What do you mean by Release Management?
Release Management is for managing the release cycle within the software project for the unique set of the files for other to use.
Its about planing the process for the any release of the product.
Its purpose is to ensure that a consistent method of deployment is followed. It reduces the likelihood of incidents as a result of roll outs and ensures that only tested and accepted versions of hardware and software are installed at any time.

Why to use Release Management?
Release Management is proactive technical support planning for the below use.
• It help to plan expenditures and resource allocation proactively.
• A systemically and the structured approach for the rolling out all new software or hardware, which is
efficient and effective
• Plan the Rollout process to minimizes incidents if its occurs.
• Training in advance of rollout, which means that users do not experience system
downtime while learning new features
• Release Manger responsibility is make sure that the user acceptances testing is done
• Version control and central storage of software, ensuring that correct versions are
installed at all times, which minimizes incidents and the need for re installation.




Its closely coupled with the Change Management process to enable implementation and
to the Configuration Management process to maintain configuration records which you can see in the above diagram.


Release Policy
The Release Policy represents a set of rules for deploying releases into the live operational environment, defining different approaches for releases depending on their urgency and impact.

The Release Policy typically contains the following information: 
Release identification -- Release identification, numbering and naming conventions
Requirements -- Requirement that only software from the Source control repository may be included in Releases
Release levels --- For each release level, e.g. major, minor, emergency releases:
1.    Definition of release level
2.    Expected frequency
3.    Roles and responsibilities as well as entry and exit criteria for the different stages of the Release and Deployment Management process (these may be modified for specific transitions as the necessity arises)
4.    Approach and guidelines for grouping Changes into Releases
5.    Planning and documentation requirements, e.g.
1.   Minor Release deployment uses the simpler Minor Change Deployment process and is documented in Release Records and Change Records
2.   Major Release deployment requires setting up a formal project with full documentation
3.   Emergency Release deployment requires authorization by ECAB and is planned, coordinated and documented by a Major Incident Team

Guidelines for different approaches to Release deployment
What are the specific conditions which make a certain approach the preferred option, e.g.
1.    "Big-bang" vs. phased deployment
2.    "Push" vs. "pull" deployment
3.    Automated vs. manual deployment

Constraints for Release deployment
Service Level and Operational Level Agreements typically specify availability targets, including allowed windows for maintenance during which the service might be unavailable. Unless Emergency Releases are required, Releases are routinely deployed during these maintenance windows. Release Management therefore needs to translate the service-specific constraints into Release deployment constraints for the systems, applications and other components which are required for the service to be available.
1.    Service-specific Release deployment constraints as defined in the Service Level and Operational Level Agreements
1.   Service A
1. Allowed frequency of new releases according to Release type
2. Release windows and constraints (e.g. Saturday 01:00 – 04:00, not in December)
2.   Service B
3.  
2.    Release deployment constraints for systems, applications and other components supporting the above services
1.   System A
1. Allowed frequency of new releases according to Release type
2. Release windows and constraints (e.g. Saturday 01:00 – 04:00, not in December)
2.   System B
3.  
Preferred mechanisms -- Preferred mechanisms to automate the deployment of Releases


I will complete tomorrow about Each section of Release Plan