Bianca Koene
Read all my blogsHow to release your changes in an Agile/ Scrum project
Currently I work for a customer that works Agile. This means we work in 2-weekly sprints, after which we bring tested functionality to production. We make a distinction between minors (every two weeks) and majors (every 6 weeks).
Because we also make quite some changes to page layouts, Software Development Kit (SDK) solutions and SAP Cloud Platform Integration developments, we do a regression test before every major. This way we make sure that already used functionality in production is not affected with a Go Live that is part of the major. So, this means only with the major we bring live (changes to) SDK solutions, SAP Cloud Platform Integration developments, change projects and changes to page layouts.
With the minor we bring live ‘simple’ functionalities, meaning ‘standard’ changes to production that are linked to for example workflow rules, code list restrictions, organisation changes, business roles, reports, so mainly functionalities that are not dependable on page layout changes and SDK developments.
For our customer, this is the best way for bringing ‘projects’ and functionalities live without impacting business processes that already use SAP Sales Cloud.
So, how does it work when you bring live changes that are linked to change projects, SDK solutions, SAP Cloud Platform Integration changes and page layouts? What is the right order and what are the steps to follow? I thought it would be helpful to everyone working with SAP Sales Cloud (or SAP Service Cloud for that matter) to summarise it in this blog.
Steps to follow when releasing changes to production tenant
- Create Transport Requests in Transport Management for the available transport objects like business roles, code list restrictions, Adaptation Changes, Workflow Rules, etc.
- Deploy Partner Development Infrastructure (PDI) and SAP Cloud Platform Integration solutions
- Bring Change Project Live
- Create a new Change Project
- Release Transport Requests
Create Transport Requests
For creating a Transport Request you have to go through the following steps:
- Go to Administrator -> Transport Management
- Hit the “+” to create a new Transport Request
- Give the Transport Request a description and optionally add a note
- “Save and Open” the Transport Request
- Go to Available Transport Objects and select the Object for which you want to create a Transport Request (e.g. Adaptation Changes, Workflows, Code List Restrictions etc.)
- Select the objects you want to transport in the “Available Transport Objects” and click “Add” to move them to the “Selected Transport Objects”
- Go to the tab Target Systems (the next tab) and choose the system the transport objects need to be transported to
- The next step would be to assemble the Transport Request by choosing “Actions” -> “Assemble”, but my advise would be to assemble only just before you actually are going to move the transport objects to your production tenant. This way you are always sure the latest changes are part of your transport.
Deploy PDI solutions (and SAP Cloud Platform Integration changes)
This is something that will be done by a developer. I am writing this from a functional perspective, therefore this and also SAP Cloud Platform Integration development deployments are not part of this blog. For our customer, deploying PDI solutions and SAP Cloud Platform Integration changes are done before the “functional” Go Live. This is because the versions of the PDI solutions need to be the same on your test tenant and production tenant before you can merge your change project. The PDI developer and the SAP Cloud Platform Integration developer coordinate their activities amongst each other.
Bring Change Project Live
These are the steps to bring your change project to production:
First you simulate a merge, with the following steps:
- Go to your test tenant from which you are releasing the change project to production
- Go to Business Configuration -> Implementation Projects
- Open your current project
- Click on “Actions” -> “Simulate Merge”.
One of the most important things that is checked with the merge is if your PDI solutions of the test tenant and the production tenant are the same. They need to have the same name and version! If not, you cannot merge your change project. You first have to make sure the versions are in sync for both tenants. For this reason, we always first bring our SDK solutions live before we simulate a merge.
If the simulation was successful, you can start moving your changes to production with the following steps:
- Select your current change project that you want to release to production and choose “Open Activity List”
- Make sure you close all the activities in the project (except for “Merge Changes” and “Close Project”). You can do this by selecting the activities and via “Change Status” change all the statuses at once to “Closed”.
- Open activity “Merge Changes”
- Hit the option “Start Merge”. This will merge your changes to production, this might take some time.
- Once you can see your change project successfully on production, you can close the project on your test tenant with activity “Close Project”.
- On your production tenant you can now open the Change Project and the activity list and close all actions!
Please keep in mind that it is advisable to do a Merge of Changes outside the release windows of SAP. Because in the weeks where the version of your production tenant is lower then the version of your test tenant the merge might fail!
Create a new Change Project
It is important to create a new change project immediately after you bring your previous change project to production if you work with PDI solutions. Because if your developer starts making changes in the PDI solution, you have a difference in versions and you cannot create a new change project anymore, unless you release your SDK changes to production. And this is probably not what you want. Therefore, it is advisable to immediately create a new change project after you bring your current change project to production. These are the steps to create a new change project:
- Go to you production tenant
- Go to Business Configuration -> Implementation Projects
- Choose New to create a new project
- It runs you through a wizard where you can adjust the scoping already (which you can also do later!) and where you give your change project a name.
- Click Finish
- Go to Service Control Center -> Systems
- Select the production URL and choose “Copy Solution Profile” and follow the next steps. In these steps you select the solution profile and the tenant where the solution needs to be copied to.
- It can take some time before the change project is visible in your test tenant.
Release Transport Requests
Now that your change project is on production you can start releasing your Transport Requests:
- Go to Administrator -> Transport Management
- Open the Transport Request you want to move to production
- Assemble the Transport Request by choosing “Actions” -> “Assemble”
- Next you can release the Transport Request by choosing “Actions” -> “Release”. After this step you can find the Transport Request in your productive environment in the status “Ready for activation”.
- Now you can activate the Transport Request in the productive environment by opening the Transport Request and choosing “Actions” -> “Activate”
- The activation of the transport request might take some lead-time, depending on the number of changes in the object.
That’s it. Happy releasing!