One aspect of software change management are transports through a system landscape. The basic idea is that you use one system for creating content, another one for testing and on a third one the content is used productively by the end users. The challenge is now to make sure that the content created on the development system is available on the QA system and that after testing exactly the tested objects become available on the productive system.
The change and transport system (CTS) is also able to handle Java transports. In this example, you can learn how the process of transporting portal content changes if you are using CTS.
As a starting point, two portals are available. C01 is used for creating portal content, XS1 is the QA portal and there are other portals in the landscape that we summarize under the SID ETC.
Take a look at the videos that are linked in the graphic below for step one, two and three.
The requirements video (step 1) shows the initial situation. C01 contains some content that is missing in XS1 – so a transport would be necessary. In the Design or Build video you can learn how to configure the portal landscape in the CTS. In addition, the video shows what has to be configured on the development portal to enable transports via CTS. If you take a look at the test video as well, you will see CTS in use for a portal export.
CTS can be used in a very similar way for other applications like PI or SLD. So if you use CTS you will have one tool that supports a big variety of transports, one central place for monitoring transports and viewing logs.
For more information on CTS, take a look at the Change and Transport System
…and turn on your sound before watching the videos. There are a lot of explanations on CTS