In this post, I want to show you how to work with change projects, after a tenant has been set to live.
Change Projects can be used to do configuration in a test environment and then push the changes to production. This can be done by creating a change project in production, copy it to a test tenant, do configuration and finally merge it back to production.
Create a local change project in production
After setting your production system live, the implementation project will be completed and the implementation project list will not show any current implementation projects.
In the production tenant you can create a new change project by clicking “New”.
When creating a new change project, you can adjust the scoping already, but this can be done later. Hit “Next” three times, enter a Title for the change project and click “Finish”.
This step will create the change project.
The new change project will show up in status “Started”. It does not contain any configuration yet.
You are now able to do local corrections in the fine-tuning on the production tenant and merge the change project locally to set the changes active. This is usually not wanted, as changes should be tested first.
Therefore we push the change project to a test tenant, do the changes there and then merge it back to production.
Push the change project to a test tenant
In order to test your changes on a test tenant, the change project must be copied over. This can be done in the Service Control Center.
Open the Service Control Center -> Active Systems
This list shows all your tenants. Select the production tenant and click “Copy Solution Profile”
The source system will automatically be filled. Use the value help and choose the solution profile ID that matches the change project you have created.
As a target system, choose the test tenant you want to copy the change project to.
Prerequisites for this step to work:
- The test tenant must not have an open implementation project. Close or cancel open implementation projects.
- Active custom development solutions must be present in the source and the target tenant in the same version.
Within the next 1-2h the change project will appear in the selected test tenant.
Once the process has been finished, you will see in the production tenant, that a test system for this change project is now available. The change project is now not editable from production anymore.
Looking at the test system, you will see that the change project appeared there:
At this point the configuration from production has been copied over to the test tenant. The two tenants are now in sync.
You can change configuration / fine-tuning on the test tenant in this change project by opening the activity list and adding activities to the project.
Merge back to production
Two activities are automatically available: “Close Project” and “Merge Changes with Production”.
Once all configuration activities have been performed, you can merge the changes back to production.
The Merge functionality allows you to copy the changes back to production.
Prerequisites for this step to work:
- Active custom development solutions must be present in the source and the target tenant in the same version
- This step might fail in the upgrade week where production tenants are on a lower release than test tenants. It can work when the touched configuration is still compatible across the two release versions.
The merge back can be performed multiple times. Once you’re happy with the configuration, you can close the change project.
When custom development is involved, it is a best practice to keep a change project open all the time. While a change project is open in the test tenant, you can do custom development updates without loosing the ability to change configuration in the tenant.
I hope this blog post gives you some insights about how you can work with change projects.