In a typical three-system SAP landscape, there are several options for moving changes from development to testing and then to the production environment. Over the years, and after the introduction of Solution Manager and Change Release Management (ChaRM), this process became much more robust and organized, but also a bit complex and intimidating. Additionally, SAP introduced the dual-track concept, which was widely adopted as a better alternative to refreshing or swapping systems. In early 2014, a large implementation by one of the many Canadian government organizations using SAP started to use ChaRM for releases. I worked on two large implementations in two different government organizations, and I saw similar issues and struggles in both. About 18 months after Go Live and the completion of a number of small and big releases in the second project, we understood that the simpler and easier technical way of managing projects with ChaRM was not the only option. With some help from SAP and a lot of reading, we discovered an alternative. It takes a little more technical involvement, but offers greater benefits to the release management process. We started learning this second option and additionally improved on it with a few custom details to adjust to the organization’s release management model. The two options are:

• Option one – Use the same project for all releases and move the phases back and forth on the cycle transaction
• Option two – Instead of using the same project for all releases, start using different types of projects and use them differently

Option one is the easiest to use and understand: single-cycle transaction and moving the cycle phase back and forth to allow different activities. For example, after moving the phases all the way to Go Live and Finish of a Release, it is possible to move the phase back to Go Live Preparation, back to Test, and back to In Development with Release. This technically allows you to continue normal development and testing activities related to future releases. Option two is to choose not to revert the cycle phase back. You move the phase forward to Being Completed and then to Completed. You use a new project and a single task for new implementations or major releases, and reuse the same project, but with multiple tasks for maintenance releases.

Assumptions and Prerequisites

The discussed options are valid for SAP implementations in which Solution Manager ChaRM is configured and used for all transports and releases on a typical dual-track landscape. Other assumptions include:

• The reader is familiar with the concept of minor versus major releases in a typical dual-track landscape with retrofit
• The organization is using the concept of a release calendar (regardless of whether it is inside Solution Manager or outside) and during the year has a number of minor (maintenance) releases on a regular basis (weekly, biweekly, monthly) and two or three major releases

Landscape

A typical dual-track landscape, as shown in Figure 1, is used to support parallel deployments (releases) with minimal risk. The dual track is formed by the two separate tracks used for maintenance (three) and implementation (five), allowing for parallel development in both tracks. The biggest advantage of parallel development is efficiency—not wasting resources’ time to wait until the Go Live of one release to start developing the next release. The three-system landscape is for regular support maintenance of a productive solution, while the five-system landscape is for major initiatives and typical development work. Any changes made in the three-system maintenance landscape are retrofitted to the development system of the five-system landscape to ensure the same configuration and customization across the landscape. After the retrofit is completed, additional unit testing is executed in the target system (DEV2 in Figure 1). Typical regression testing is usually performed in the quality assurance (QA) environments as per the normal testing process. The synchronized changes imported by the retrofit process are included and covered by the regression testing executed in QA2 in Figure 1.

The ChaRM Part

The releases are supported by a ChaRM-activated project in a Solution Manager system, where the managed systems are assigned via a logical component. A logical component contains the systems necessary to provide a change to the production (PROD) system. It defines the exact transport routes by identifying the system ID, client number, and assigned role. Each system has an assigned role, according to the landscape diagram (development [DEV], QA, and PROD). This configuration is done in transaction code SOLAR_PROJECT_ADMIN (Figure 2). Projects in Solution Manager are of several different types, to support typical types of work. These types are:

• Implementation
• Template
• Optimization
• Safeguarding
• Upgrade
• Maintenance

The difference between these types is not the subject of this article. They all support change management (with ChaRM activated), and the concept described here is applicable to all of them. When a Solution Manager project is activated for ChaRM, two special transactions are generated. They are a project task list and a project cycle transaction. In transaction code SOLAR_PROJECT_ADMIN they can be seen in the Change Management tab (Figure 3). It is important to mention that these two transactions are in a one-to-one relationship with the project. All change documents used by ChaRM, such as Normal Change, Urgent Change, or Admin Change, are created from the approved requests for changes and are linked to the project cycle. The cycle transaction is controlled by different phases shown in Figure 4. The phases control what can be done (or not) with the change document and transports. The project task list has exactly the same phases as the project cycle transaction. They are always in sync, but the manipulation of the phase is done only via the cycle transaction from the IT Service Management (ITSM) web interface, and the task transaction is updated automatically by the system. With Solution Manager 7.0, the task list was also modifiable from the SAPGUI, but with 7.1, SAP straightened out the process. With 7.0 it was possible for the two to go out of sync. This represented a serious issue and required a difficult fix process.

Examples of the Phases’ Restrictions

During the In Development with Release phase, change documents can be created, transports can be created from these change documents, and transports can be released and imported to QA, but not to PROD. During the Test phase, transports can be created only from Defect Correction, but not from change documents. During the Go Live phase, import to PROD is possible, but creation of change documents and transports is not possible. The general documentation does not go very deeply into how project task lists and cycles are to be used, and in my experience, many organizations do not completely understand this complex relationship and the difference between the following options for using these transactions. Option one: In my opinion it is more common to use the one cycle transaction and move the phase back and forth. This allows different activities related to the project needs and to have one permanent project for support activities that never closes. Example: After moving the phases all the way to Go Live and Finish a Release, it is possible to start moving the phase back to Go Live Preparation, back to Test, and back to In Development with Release. This technically allows you to continue normal development and testing activities related to future releases. Option two: The second option is to never revert the cycle phase back, but to close it after implementing the changes in PROD. This is done by moving the phase forward to Being Completed and Completed. You then open a new cycle for the same project to be used for the next release in the release schedule. These two phases (Being Completed and Completed) are more restrictive and do not allow going back. (Tip: If an administrator mistakenly moves the phase forward from Go Live to Being Completed, the only option is to complete the cycle, as Being Completed does not allow you to change back to Go Live.)

Initial Model

Initially, the implementations I worked on used only one ChaRM-activated project of the maintenance type. After about a year we had our first audit and had to do hours of work to find traces of when and how some transports went to PROD. We were lacking important details about some of our early change transactions when our release model was in its baby phase. Later, we realized that our maintenance project, used with one single cycle, was being reversed back and forth and was reused for each release. It was becoming too slow to operate and navigate, as the number of attached documents was growing each month.  This was option one. We had one maintenance type project activated for ChaRM, and we never closed the cycle transaction. This means that after each maintenance release we would change the phase from Go Live back to In Development with Release, which is possible. The advantages of this model are that the project does not require any maintenance as the IT operator and change manager have the ability to change the cycle back and forth.  However, over a single year of using this model and going through a large number of weekly releases, we noticed the following issues: 1. When analyzing some changes implemented during the last year, we did not have any evidence about in which planned release they were done. Of course, we had some other records—via test reports or emails, but not in the system. The reason was that one single cycle was associated with the growing number of change documents, and they all belonged to various releases. 2. The cycle transaction performance was good during the first six months, but as the associated number of change documents kept growing, this became an issue at the end of the year. This performance could eventually be improved with more network resources, but in our case, this option was not available. 3. A complete lack of easy and reliable reporting on historical data based on release number or date, even though all records were in the system.

The New Release Strategy

We planned and developed a new release strategy, which consisted of a number of steps, the most important of which (from an Application Lifecycle Management [ALM] ChaRM perspective) are:

• Use a ChaRM-activated implementation project for each major release (one to two times per year) and close the cycle transactions once the project is completed, adjust the documentation to the solution, and finally close the project
• Use one ChaRM-activated maintenance project for all maintenance releases (weekly or biweekly), close the cycle transaction and task for each release, and create a new cycle transaction and task for the next release.
• Introduce to the Request for Change header, a Release ID field, to help with forward release planning and reporting.
• Use a specific naming and numbering convention to distinguish release types, and use this same ID in two places—the Release ID field and in the Description of each cycle transaction—to match the release as per the release planning calendar. This concept helped us to do the release planning for the next few releases, regardless of the maintenance or implementation release and independent of the ChaRM project. Once a ChaRM project is created, the link to the project is created, but also the release ID is used as a naming convention for the release cycle, to allow full transparency and traceability from planning to release.

Then we developed the new model based on option two. In this model we took a more sophisticated approach and decided to use different types of projects for the activities for which they are designed. As mentioned above, the project-task-cycle relationship is one-to-one-to-one. However, the project can be reused, with the current task and cycle being closed and the new task and cycle generated. This is a clever design to preserve work in progress. For example, if a change is under development, but cannot make the deadline for a particular maintenance release, it is still linked to the cycle, and the cycle can still be completed. What happens then with work that is not finished, with a change document with still-open transports? This document is still associated to the main project, but when the cycle is closed, only completed change documents remain linked to that cycle. Any uncompleted change documents are left behind, in a temporary orphan state, but when a new task and a cycle are generated for the same project, they immediately link to the new cycle. That functionality is behind the best benefits of this option:

1. The completed cycle and all change documents that belong to this cycle immediately become a perfect system record on what a particular release contained.

2. Several maintenance releases on the same Solution Manager project can be developed in parallel, without additional administration. This is also a very easy solution for changes that need to be delayed and moved to the next release (for the same project), as they were not ready but were already under development.

To be able to use the best SAP-recommended practices and to adjust our documentation, we further improved our release strategy by using an implementation type of project for major releases (two to three times per year), a maintenance type of project for minor releases (weekly or biweekly), and an upgrade type of project for upgrade releases (once each one to two years). The big difference is that with an implementation or upgrade project, we use only one cycle transaction. After finishing all post Go Live activities and documentation adjustments, we close the cycle, the task, and the project, and we never use this project again. For minor releases we keep reusing the same project (maintenance type), but close the cycle after each release and create a new cycle—therefore, the same project with multiple cycles. This makes much more sense as a typical maintenance release has 10 to 20 changes, usually bug fixes or master data adjustments, and does not require documentation adjustments. However, it is still subject to release planning, approval, testing, and tracking. The use of different types of projects is shown in Table 1.  

Project type	Release type	Task and cycle	Closing after the release	Adjusting documentation
Maintenance	Minor biweekly	New task and new cycle for each release	Task, cycle - Yes Project - No	No
Implementation	Major two per year	Single task Single cycle	Task, cycle - Yes Project - Yes	Yes
Upgrade	Upgrade once every two  years	Single task Single cycle	Task, cycle - Yes Project - Yes	Yes

To be able to follow a strict release calendar and release-planning process, we also needed a naming convention. In the convention the idea was to be able easily to distinguish by the number if the release is minor or major. This was achieved by using the convention in Table 2.

Release type	Release number	Why
Minor	R2.1.4	If the last major release was R2.1, the following maintenance releases are R2.1.1, R2.1.2, R2.1.3, and so on until the next major release
Major or upgrade	R3.1	The next major is R3.1

In the above convention the major release uses two numbers (for example, R2.1). This reads as First Major release in the Second year of using this SAP system. The first digit is for the year, and the second is for the number of the release in this year. This is unique for each organization, and it is shown only as an example. The next challenge was how and where to use the well-developed naming convention. Naturally, the most logical way was to use the name of the project, task list, and cycle, as descriptions allow free text, as shown in Figure 3 and in the details in Figure 5. Then release planning faced an additional challenge. As each active project has only one single cycle, it was very challenging to allocate work that would be addressed one to two releases later. A small custom solution helped—the Release ID field on the Request for Change (RfC) header.

Release ID Custom Field

The Release ID field (Figure 6) was developed to serve our particular organization’s release-planning needs and could vary for other organizations. The presence of this field does not make any difference in the use of option 2, but was extremely important for reporting and planning purposes. The new custom field was created as a minor user interface enhancement with one ABAP table to store the release ID’s values. Release management was given access via a custom transaction code to modify the table directly for its needs. Table 3 summarizes how this field is used for release planning.

Release type	Release ID on RfC
Minor	MAINT
Major or upgrade	R3.1

 

• There is no need to adjust if one change is late for the current maintenance release, but will be completed with the next maintenance release. The exact release number (R2.1.2) is visible from the related cycle.
• Less frequent maintenance of the Release ID table by the release manager

Planning for Future Releases

Planning now is done by using the Release ID, regardless if the respective project, task, or cycle is created. As the Release ID is also activated for reporting, filtering by this value is very convenient. Figure 7 demonstrates the use of the new Release ID as report criteria and in the report results table.

Reporting on Past Releases

Let’s review in more detail the reporting for several months in the past. Example: Maintenance release reporting Even though the same Release ID = MAINT is used for planning simplicity, we now have a unique cycle per release and easy access via the cycle transaction to each maintenance (biweekly) release. Case 1: How many maintenance release cycles did we have after the last major release R2.3, and what did each of them contain? We searched for Completed Change Cycle of type maintenance (the technical type is SMMN) with the description containing a string that we know is used. In this case, as each maintenance release is numbered R2.3.x, the search is for R2.3 to include all matching values. Figure 8 demonstrates that with these search criteria we found eight maintenance cycles. Each one of them represents a single completed release, and the description includes the Release ID. Similar to the maintenance example, the reporting works for all other types of Solution Manager projects, as shown in Figure 9. For example, the implementation project is using a cycle of the type SMDV. Consult with your ChaRM configurator for technical details on projects used in your organization and how to recognize the ones you need to use. Do not use any marked with (old). These types were used before Solution Manager 7.1. If you are not sure what type your project is, there is visibility from any change document (Urgent Change, Normal Change) that is associated with the same project, as shown in Figure 10. Now, each of these cycles is associated with only the completed change documents, and is a true representation of what moved to the production system with this particular release. The exact release date is not the posting date shown in Figure 8, but the date the cycle was in Go Live status, which is available in the cycle log. Figure 11 shows the overview and the related transactions assignment blocks of a particular completed cycle transaction. In the current design, SAP adopted the name Assignment block for all the horizontal sections that can be opened and closed. For example, in Figure 11, two assignment blocks are visible and open—Status Overview and Related Transactions. Each transaction type has different assignment blocks visible by default, but this is a very flexible configuration and the user has access to more assignment blocks to make visible or hidden, as well the ability to change the order of appearance (up and down). The example from Figure 11 shows that with release R2.3.5 one urgent (ZMHF), one admin (ZMAD), and five normal (ZMMJ) changes were moved to production environments. Case 2: Starting with a transport ID you need to find out which RfC and release were used:

• From transaction code SE10 or STMS and the transports’ queue, you have visibility into the change document ID in the transport description. Copy the Change Document ID from one of these queues that are in SAPGUI and open ITSM via transaction code SM_CRM (or a web link) to use the Change Document query. Opening the change document takes you to Figure 12.
• From the change document Related transactions assignment block you have complete visibility to the cycle and release, shown in Figure 12.

Transition Time

Naturally, if an organization changes the release strategy with a new project procedure, there will be a transition time when the old projects need to be retired and the new ones start being used. For a short period of time, a stricter discipline needs to be in place that monitors to ensure that the new RfCs are assigned to only the new projects and old projects are used only to finish what was in progress, and then closed.

We found this was also excellent time to clean up records, to develop process and training documentation, and to educate the right audience on the new release strategy. After the transition was over a few months later, and only the new projects were in use, it was very comfortable for all players. Definitely, during the transition there were some mistakes and confusion, but it was a small learning curve compared with the improvements realized. We achieved these process and reporting advantages with the adoption of option two:

• Improved release planning
• Improved release tracking
• Improved release reporting
• Improved auditing trail
• Improved statistics for past releases

And, finally, we achieved improved performance. Our specific network was becoming slow and difficult to manipulate once the maintenance cycle transaction was linked to more than 1,000 documents. This was not the reason for the above change strategy, but it came as an extra bonus. With the above changes, we have a perfect auditing trail as well as easily available statistics for all completed releases. We are pleased to hear that SAP is introducing the Release ID field with Solution Manager 7.2, and we are proud to know that our forward thinking matches industry needs.