In the last couple of months, I was looking into the merits and demerits of using CI & CD in SAP.
From my experience, CI & CD beyond certain limits is hard in SAP. SAP will soon introduce the branching and merging to GIT which will certainly allow parallel developments, but unlike dot net or java projects, does that really help real-time ABAP projects or how frequently you require a parallel development to be done in SAP landscape ?.
What is missing ?.
My answer would be “Unit Testing”. Organizations should urge developers to use TDD approaches for all the developments which would ease the testing in subsequent systems as most of the functionality/technical bugs will get fixed with unit testing. A properly implemented unit testing can save more than 50% of QA testing efforts.
So what is TDD and how is it relevant ?
Test-Driven Developments (aka TDD) is an approach/method to writing code in smaller testable units.
What are the pre-requisites ?
You need to have a valid design (functionality & technical) and to have a valid design, teams need to communicate and collaborate efficiently along with stakeholder participation and this forms the base for agility.
Is it so simple ?
Not. It would require a lot of effort and collaboration initially to get going and once the team matures, this will be one of the most efficient approaches to follow. If not properly planned and executed, the use of TDD can be a nightmare as well :).
Is that all required for CI & CD ?
Unit test automation is the first step and should be followed by automated releases. To automate the SAP TR releases, there are multiple approaches that can be invoked. This will avoid any dependency with SAP Basis Teams to manually transport the TR’s. Tools like “Jenkins” will help to co-ordinate the automated tests and releases by communicating with relevant systems/transactions. There are AI-based test suites that perform integration testing which can be triggered by Jenkins in QA systems.
Can we have automated deployment to Production ?
To have the production releases automated, below steps should be considered:-
- Improved team collaboration & communication
- Team’s maturity in designing the product as per business needs
- The efficiency of the Unit Test approaches
- The capability of Test Suites to generate scenario-based test results
- Stakeholders believe in the project teams and test results
Teams should have periodic assessments and once the maturity is attained, then yes production releases can be automated.
So what do you think should be the very first step ?
I would say, Mindset.
1. Accept the change
2. Improve collaboration and communication
3. Understand what was done yesterday and what is planned for today (timeboxed 15 mins standup team call).
4. Practice TDD and Unit Test approaches
5. Try different automated test suites
6. Share and coach teams
Above all, “Business Vision” should be made clear to all.
I would like to know your thoughts/experiences on this.