DevOps

DevOps moves your integration objects from one SAP system to the next. A ticket collects the tracked object versions that belong to one piece of work, a transport carries them across a single hop of a landscape, and a release groups tickets so they can be tracked and closed together.

Because the objects come from Change Tracking Tool and the route between systems is a landscape, both have to exist before you can create a ticket.

Requirements:

All required Agent Systems have been configured (see Agent Configuration to learn how to do that).
Synchronization of all required Agent Systems has been done (see Synchronization with Agent system section).
You should have enough licensed tracked object versions in CTT (i.e. DevOps licensing plan), otherwise, once new version is registered, the oldest will be deleted if the limit is reached. It causes loss of transport items if deleted tracked object version was used in the transports.
If you use PRO Agents, additional SAP PRO client libraries must be available in runtime classpath. They are not included into the build, so they should be added to a folder (you can create libs folder in the folder with jdbc driver) and then the path to that libs folder should be passed through -Dloader.path parameter in the bootstrap command (see that section). If any of these libraries are missing, you will see the following error during transport creation or checking imported objects:

Required libraries:
- com.sap.aii.utilxi.core.jar - can be downloaded from <PRO system root url>/dir/directory/com.sap.aii.utilxi.core.jar
- com.sap.xpi.ib.core.jar - can be downloaded from <PRO system root url>/dir/directory/com.sap.xpi.ib.core.jar
- com.sap.xpi.ibdir.core.jar - can be donwloaded from <PRO system root url>/dir/directory/com.sap.xpi.ibdir.core.jar
- sap.com~tc~bl~guidgenerator~impl.jar - can be downloaded from <PRO system root url>/dir/directory/sap.com~tc~bl~guidgenerator~impl.jar

1. How DevOps works

Create a landscape describing the systems your changes travel through, and synchronize the source system.
Create a ticket on the Tickets page and attach the tracked objects it covers, together with their dependencies.
Move the ticket to its transport stage. If the landscape has Integrated transport management, the transports are created for you; otherwise you attach them yourself.
Open each transport, adjust its transport configuration if the target system needs different values, and import it.
Resolve the ticket once all of its active transports are imported.

A ticket is either a Development ticket, used for changes made within one landscape, or a Migration ticket, used to move objects from one landscape to another. The two follow a similar workflow but do not share their stages: development tickets end at Completed, while migration tickets begin at Prepared and end at Migrated. Both can end at Canceled. The stages are described in full on the Ticket page.

Transports move through their own statuses — from CREATED or IN_PROGRESS through to IMPORTED, and possibly REVERTED, DECLINED or CANCELED. Whether a transport needs approval before import depends on the Require Transport Approval setting of its landscape. See Transport Statuses.

2. What you need

Attaching an object to a ticket consumes an object license: DevOps for development tickets, Migration for migration tickets. See Configure Object Licenses.

Access is governed by roles described on the User management page: IRTDevOpsOperator works with tickets, releases and transports, IRTDevOpsConfigurator may modify transport configuration, and IRTDevOpsManager has full access. If a landscape has Restrict Execution enabled, only its executors can import or roll back its transports.

3. In this section

DevOps tutorials and samples: End-to-end development flows for PRO, CPI and Api Management, CTS+ and external transport management, plus batch parameters update, scheduled import, and transport of SAP standard (Discover) content.
DevOps UI overview: Every DevOps page and dialog: tickets, transports, transport configuration and releases.