Release management is the process of managing, planning, scheduling and controlling a software build through testing and deploying in the production environment.
Release & Deployment Management is responsible to manage successful deployment of all related changes into a productive environment
Release Management defines dates and schedule for Releases
Release content determined by Projects and Work Packages or Requests for Changes and related Work Items or Change Documents
Release Cycle acts as technical container and model for the release content
Types of Releases:
a. Major Releases:
Major Releases are typically big releases which contain big changes to the solution. This includes changes to the user interface, new business processes or renovated processes. Often major releases also contain technical upgrades to newer support packages or software versions. The frequency of major releases is typically between 1 and 4 per year.
b. Minor Releases:
Minor Releases are usually processed in parallel to Major Releases. Minor Release contain smaller enhancements and features, which only have a smaller impact to the end-user. Typically no drastic UI changes or major changes of business processes. The frequency of minor releases is much higher compared to major releases. Mostly per major release several minor release will be deployed in between.
Release Management helps in easier planning and more flexibility in planning change execution. It also aids in –
Whenever something shall be deployed into the productive environment, it will be handled via a Release. The release content consists of all developments during the Build Phase, that have been created as part of the same release. The release has many different phases which all have a defined process. The phases of the release also control which activities are possible during that phase related to the release e.g. assignment to a release, development, testing, import of transports, deployment to production etc..
1. Scope: In the scope phase, the business requirements that have transitioned to IT Requirements is reviewed. The Business Manager evaluates the needs of the changing or evolving business to approve business requirements. Business Process expert will be involved in defining the business requirements. The Requirements Manager is responsible for collecting, effectively processing, and documenting missing information. He or she should have a good understanding of the requirement as well as an overview of its possible technical implementation. For this reason, the requirements manager is often referred to as the “interface between business and IT.” The requirements manager, is responsible for managing the requirement, which involves changing the status of a requirement, defining dependencies, or assigning dependencies to a release. The solution architect translates IT requirements created by Requirements Manager into the architecture for that solution.
2. Build: In the build phase, the content of the release will be finally defined. This is the time, when the release manager needs to make a decision about which changes shall take part in the release deployment and which shall be taken out (e.g. postponed to next release).
3. Test: In the test phase, the testing of the release takes place. The content is finalized.This is the final release test, which means the entire package needs to be validated and tested for functional and technical correctness before the import into the Production environment.
Usually this involves a whole series of tests including
–Acceptance Test
–Regression Test
–Integration Test
In case of bugs or issues, a defect correction can be created to fix the errors.
4. Deploy: The deploy phase includes actual technical cutover of the entire release into the production environment.
--This means all transports will be imported into the production environment.
--The activity to trigger the import will be done by a Administrator or Technical Release Manager from within SAP Solution Manager.
--The content of the package will be calculated automatically by SAP Solution Manager and imported in the correct sequence.
5. Hypercare: After the deploy phase there is a special phase called “Hypercare”. This is due to the fact that usually shortly after a go-live, the number of incidents increases significantly. Sometimes this is due to missing information about the new functionality, wrong documentation or bugs which have not been detected and solved before. During this time, there is still a high attention on the release and a consistent monitoring of the incident queue. Usually this phases ends after a few days or weeks –
6. Operate: The release will be formally handed over from the Project Team to the IT Operation Team, which ensure production support.
Now let's go through the steps in SAP Solution Manager 7.2 to plan, create and assign requirements and changes to a release (Major or Minor) :
1. Planning and Creating Releases and Release Cycle.
A. Open the CRM UI with transaction SM_CRM to access the SAP Solution Manager ITSM. Click on the Change Request Management Tab and then choose "Release Planning"
B. Select "Create" and then address the fields that require input
C. An example is shown below.
D. Create Release Cycle
E. The Release cycle should then be activated
F. After activating the task list, we need to make sure that the transport routes and landscape track is defined correctly
G. The release cycle can now be set in the phase "Build" to start development work
2. Assigning requirements to a release -- The business requirements that evolve from the business and translates to IT Requirements can then be assigned to the respective releases (Major or Minor)
3. Assigning Changes to a release -- Similarly there are opportunities to assign changes to releases (Major or Minor)
Part 2 of the blog is in the below link
https://blogs.sap.com/2017/01/02/integration-of-requirements-management-with-sap-project-management-...
Release & Deployment Management is responsible to manage successful deployment of all related changes into a productive environment
Release Management defines dates and schedule for Releases
Release content determined by Projects and Work Packages or Requests for Changes and related Work Items or Change Documents
Release Cycle acts as technical container and model for the release content
Types of Releases:
a. Major Releases:
Major Releases are typically big releases which contain big changes to the solution. This includes changes to the user interface, new business processes or renovated processes. Often major releases also contain technical upgrades to newer support packages or software versions. The frequency of major releases is typically between 1 and 4 per year.
b. Minor Releases:
Minor Releases are usually processed in parallel to Major Releases. Minor Release contain smaller enhancements and features, which only have a smaller impact to the end-user. Typically no drastic UI changes or major changes of business processes. The frequency of minor releases is much higher compared to major releases. Mostly per major release several minor release will be deployed in between.
Release Management helps in easier planning and more flexibility in planning change execution. It also aids in –
- Better Risk mitigation through extensive testing possibilities.
- Less risk for downgrades or over taker situations.
- Stable test system environment due to central release schedule.
- Increased productivity due to increased standardization along the entire process.
- Better tracing and tracking of implementation activities (also post go-live).
- Possibility for controlled handover and maintenance processes
Whenever something shall be deployed into the productive environment, it will be handled via a Release. The release content consists of all developments during the Build Phase, that have been created as part of the same release. The release has many different phases which all have a defined process. The phases of the release also control which activities are possible during that phase related to the release e.g. assignment to a release, development, testing, import of transports, deployment to production etc..
1. Scope: In the scope phase, the business requirements that have transitioned to IT Requirements is reviewed. The Business Manager evaluates the needs of the changing or evolving business to approve business requirements. Business Process expert will be involved in defining the business requirements. The Requirements Manager is responsible for collecting, effectively processing, and documenting missing information. He or she should have a good understanding of the requirement as well as an overview of its possible technical implementation. For this reason, the requirements manager is often referred to as the “interface between business and IT.” The requirements manager, is responsible for managing the requirement, which involves changing the status of a requirement, defining dependencies, or assigning dependencies to a release. The solution architect translates IT requirements created by Requirements Manager into the architecture for that solution.
2. Build: In the build phase, the content of the release will be finally defined. This is the time, when the release manager needs to make a decision about which changes shall take part in the release deployment and which shall be taken out (e.g. postponed to next release).
3. Test: In the test phase, the testing of the release takes place. The content is finalized.This is the final release test, which means the entire package needs to be validated and tested for functional and technical correctness before the import into the Production environment.
Usually this involves a whole series of tests including
–Acceptance Test
–Regression Test
–Integration Test
In case of bugs or issues, a defect correction can be created to fix the errors.
4. Deploy: The deploy phase includes actual technical cutover of the entire release into the production environment.
--This means all transports will be imported into the production environment.
--The activity to trigger the import will be done by a Administrator or Technical Release Manager from within SAP Solution Manager.
--The content of the package will be calculated automatically by SAP Solution Manager and imported in the correct sequence.
5. Hypercare: After the deploy phase there is a special phase called “Hypercare”. This is due to the fact that usually shortly after a go-live, the number of incidents increases significantly. Sometimes this is due to missing information about the new functionality, wrong documentation or bugs which have not been detected and solved before. During this time, there is still a high attention on the release and a consistent monitoring of the incident queue. Usually this phases ends after a few days or weeks –
6. Operate: The release will be formally handed over from the Project Team to the IT Operation Team, which ensure production support.
Now let's go through the steps in SAP Solution Manager 7.2 to plan, create and assign requirements and changes to a release (Major or Minor) :
1. Planning and Creating Releases and Release Cycle.
A. Open the CRM UI with transaction SM_CRM to access the SAP Solution Manager ITSM. Click on the Change Request Management Tab and then choose "Release Planning"
B. Select "Create" and then address the fields that require input
C. An example is shown below.
D. Create Release Cycle
E. The Release cycle should then be activated
F. After activating the task list, we need to make sure that the transport routes and landscape track is defined correctly
G. The release cycle can now be set in the phase "Build" to start development work
2. Assigning requirements to a release -- The business requirements that evolve from the business and translates to IT Requirements can then be assigned to the respective releases (Major or Minor)
3. Assigning Changes to a release -- Similarly there are opportunities to assign changes to releases (Major or Minor)
Part 2 of the blog is in the below link
https://blogs.sap.com/2017/01/02/integration-of-requirements-management-with-sap-project-management-...
- SAP Managed Tags:
11 Comments
