In the book Team Topologies written by Manuel Pais and Matthew Skelton they state “Limit the size of software services/products to the cognitive load that the team can handle”.
Meaning — software that fits in your head, — as we see in the above picture, if not this can lead to several problems, keep it simple, “Software that is too big for our heads” works against organizational agility.
If you have ever worked with SAP you already know it´s a complex monster, no one fully understands it.
Cognitive Load is the total amount of mental effort being used in the working memory. John Seller
So how DevOps fit (or not) in SAP development?
There are some components in SAP that have existed since the early days of SAP R/3. One of these components is the SAP Change and Transport System (CTS).
While there were no significant changes to this important core component for a decade, it has been extended during the last 13 years to support the transport of non-ABAP objects (Enhanced CTS or CTS+) as well as the synchronization of dependent changes across different SAP landscapes (Central CTS or cCTS).
Now SAP is introducing gCTS, the Git Enabled Change and Transport System in SAP S/4HANA 2020.
Git Enabled Change and Transport System (gCTS).
As you can see, now we can use a Git repository, but still, a transport request in the background is needed but we don't need a complete setup of the landscape anymore to be able to move stuff between systems, and of course, the ABAP runtime is still mandatory.
As a connection to these systems, we have the Git repository, which's the DevOps approach but we still have the classical CTS in the background.
The development process
ABAP developers start working as they are used to, either using ADT (ABAP Development Tools), the transaction SE80(Object Navigator), SPRO (Customizing), depends on the SAP release, and finally, the SE09 (Transport Organizer).
In SAP environments the developer first starts creating a transport request, after that he can start developing when done he will release the transport request, so the process for the developer at a first glance doesn’t change too much. Only when the transport request is released things change.
A push will be done in the transport target, this commit will be done in the repository and then you can execute some build, unit test, etc, and follow a complete pipeline as shown in the following image.
We can choose of course from different tools to make continuous integration happen like Jenkins, GitLab, IKAN ALM, etc.
gCTS for Fiori UI
So the front-end is a separate code built on Eclipse and the back end is an ABAP package, both connected to a Git repository.
We can add Selenium in our pipeline to automate testing on the front side or we can use Uiveri5, apparently not another cumbersome tool from SAP.
UIVeri5 is an E2E testing framework for UI5-based applications. It uses WebDriverJS to drive a real browser and interacts with your application as a real user would. UIVeri5 is heavily inspired by Protractor and brings most (and more) of its benefits to UI5 applications.
Behind the scenes, it uses Webdriver which is the same as used in Selenium and Jasmine to establish the test suite and write the tests.
Page objects are design patterns that represent a significant part of an app, grouping, actions, or assertions. Through locators, they allow test runners to see and do anything a real user would.
Testing must be present in all phases but most testing should happen during unit testing, the aim is to resolve problems as early as possible by shifting quality controls to the left.
The goal of shift-left is not to accumulate technical debt.
Unit tests focus on a single unit of source code. Everything around that unit is replaced by test doubles (dependency isolation).
There are 2 central components of ABAP development tools (ADT) for ensuring quality.
1. ABAP Unit Framework
Verifies the functional correctness and intended program behavior at runtime.
2. ABAP Test Cockpit (ATC)
Execute ABAP Unit test together with other tests like functionality, security, accessibility, or usability checks.
ABAP CI/CD Pipeline Using gCTS
Take a look at the following image (disclaimer, the image was taken from the openSAP training platform) and of course Banana Corp is a fictitious company.
So we have 3 different systems, development N20, testing is T20, and production Y20. A branch for development called Feature and the Master branch that executes the deployment into production.
How could dual landscape (retrofit) synchronization with Git-Enabled Change and Transport System (gCTS) take place?
At branch level within the repository or at branch level within the source repository and with SAP Solution Manager Retrofit (mixed mode).
In my humble opinion is still not that easy to implement an agile development project in SAP systems but is too way easier than before. There is maybe no reason to use gCTS in a pure ABAP environment. Classical CTS is available, and it will stay available. If you are happy with the process and flows that you use in CTS, continue using them!
gCTS is made for cases, where CI / CD processes in a DevOps-minded environment are needed for ABAP as well. gCTS is somehow the door opener for ABAP development into this world. With gCTS, it is e.g. possible to set up pipelines for ABAP development.
SAP has different solutions for CI/CD.
- As shown in the above image, the first option is Continuous Integration and Delivery is a cloud service that lets you configure and run predefined CI/CD pipelines. You don’t need to set up your own CI/CD infrastructure and more important you don’t need any in-depth knowledge about CI/CD to use it.
- The second option is SAP tooling for continuous delivery in project “Piper”, which is more flexible and not too difficult to implement. The goal of project “Piper” is to substantially ease setting up continuous delivery in your project using SAP technologies.
- A guide that helps you find the SAP solution for Continuous Integration (CI)/Continuous Delivery (CD) that best fits your specific scenario.
Thanks for reading,
A clap is always appreciated, :-)