Technical Articles
So, what is CI?
Continuous Integration keeps popping up every now and then, and there are already some great blogs on the subject. SAP also provides a great overview in What Are Continuous Integration and Continuous Delivery?, it describes CI as:
Continuous integration (CI) describes a software development process, in which various team members integrate their contributions frequently into a single main line. Before each integration, the changes are verified through builds and automated testing. Thereby, you can detect errors as quickly as possible and prevent integration problems before completing the development.
Basically, CI helps the developer to verify the development before completing the development.
Landscape
In a typical SAP landscape, the developers perform changes in DEV, and after the development is done, the changes are moved to QAS for testing, and if successful the changes are moved to PRD.
Developers rely on having an operational DEV system for doing developments, and QAS must also work in order to be able to verify the development, which typically(?) involves manual steps.
At the recent TechEd, SAP recently suggested the following for a CI setup,
DEV208
Where the QA system is used to perform the CI tests, this corresponds to “Scenario 2” in Fully supporting CI in ABAP AS
Developers will Commit Early and Often, and each change will be built, triggering the CI, meaning:
- The QA system will continuously be changed, and objects possibly rolled back. In ABAP rollbacks are not 100% reliable, e.g. a unit test might have modified the system state, thus leaving the QA system in an unknown state.
- CI is triggered before the developments are done, possibly moving faulty code to QA, which has not been through any quality control steps.
- Manual testing in QA will be void, as the system state continuously changes. However, this could work in a waterfall process, if all testing is done after all development, but it goes in the opposite direction of Continuous Deployment
All-in-all this ends up with a harmful automated process for breaking the QAS system, instead of avoiding errors via automation and helping developers.
Having void test results might be the right compromise for some organizations, but there are also multiple alternatives, like adding an extra system to handle CI.
Personally, I am moving towards a setup(Scenario 9), where the static analysis and unit tests are run outside of the ABAP stack, with the compromise of possibly giving false positives to the developer.
Many people have tried to explain to me what "CI" means in an ABAP context. Every time I ask the question I get an utterly different answer.
I have come to the conclusion the term as defined above only makes sense in an environment like ABAP in the Cloud where you do your changes in a standalone system and then merge them into the real central development system, just like non-ABAP programmers do.
Thereafter only when the development code has passed all the tests does it go into development, and thus when the transport is released to QA it should be as Uncle Bob says i.e. "QA should find nothing"
As an aside if an automated unit test modifies the system state then it is not a proper unit test in my mind. Such tests should never read from or write to the database.
Cheersy Cheers
Paul
Yea, the problem with CI is the consistency, ie spawning new systems/containers running the right ABAP. How to do this properly is the real question/problem to be solved, moving development objects can be done with even old-style CTS.
Hey, Lars,
While I completely agree with you that the setup you describe in Scenario 9 is by far the best option, I think it is not a complete doom and gloom with the new software lifecycle process from SAP.
Even if a unit test indeed modifies the system state (which probably isn't good in the first place, as Paul Hardy mentioned), I was left with the impression from DEV208 that the whole system state is restored in case of a failed unit test? I.e., not just the code, but also the created data. And this is why they very clearly warned against using this for productive systems.
Best,
Stoyko
I don’t trust developers, like myself, to do things the right way
If the full system state, including data, is rolled back, then it will be totally impossible to use the QA for manual testing? All manual steps might be rolled back at any time, as developers (should) commit often, and each change is built/triggers CI.
I'm pretty sure that application data is not kept in git in the example, so if everything is rolled back, then something is missing in the slides IMHO
Hey, Lars,
Here's a transcript of the relevant section from DEV208:
"But if the unit test fails, then you could do a rollback. The idea behind this is that the test system where you most probably deployed the new commit to is always in an up and running state. So this means all other developers can always deploy their stuff to this system and test it. The developer who provided the commit with the error can make sure or can fix his error with the time he needs and then try again to deploy his stuff. This rollback is only intended for this use case. So it's not made for rolling back a production system, for example, to a coding stay that is several weeks old. Because we really roll back everything to the state of the commit that you chose for the rollback. We do not save any data. So if you used the coding already in the target system, created new stuff, maybe for example you changed the database table and the table became bigger, so more I characters allowed or whatever, and you roll that back, then the table will be rolled back to the old state. And the data that you created based on the new coding will be lost."
(official transcript from subtitles. I think there are 1-2 innaccuracies, probably because it was originally created from text-to-speech, but it was definitely proof-read by a human, given that it was largely accurate)
Indeed this is a bit ambiguous. On the one hand, it may mean if you changed a database field, also this is the given example (more characters allowed). But on the other, "we really roll back everything" and "the data that you created based on the new coding will be lost" do lead me to think that the full system state is restored.
Stoyko
Btw, Martin Fowler also has a good description, https://www.martinfowler.com/articles/continuousIntegration.html
Some organizations also use "transport of copies" to transfer developments to the QA system, but consider the differences, using transport of copies does not get the "Continuous Integration" stamp. Plus developments are moved after the developer thinks the development is in a good state, CI starts before this.
Another example, https://blog.sap-press.com/abap-and-continuous-integration-the-abap-test-cockpit-and-the-abap-unit-runner
Again, this is okay, if it's done after development is somewhat completed, but CI by the SAP definition happens before the development is completed
Let me step in to give some ideas that we as SAP have in here:
With gCTS we aim at supporting a decentralized development scenario with ABAP. You can find the details described in our statement of direction (starting page 9). So the classical three system landscape might not be a suitable set up for ABAP landscapes in the future any more.
In addition, we also plan to support new ways of doing maintenance and new development in parallel with gCTS.
It all depends for sure also a bit on how your development organization is set up – and also it depends on some additional functionality that has to be added to gCTS.
We will keep you posted on new things that we offer with the latest release as soon as they are available.
But let me also add some things that can be done differently with gCTS already today:
You can extend functionality for gCTS by the help of BAdI to allow creating commits whenever you release a task. This allows testing new development early and often for each developer without having to wait until the complete transport request can be released and then having to sort out what of the issues that the testing brought up had been caused by whom.
The rollback-option can help to always provide a working test system. With this, each developer can easily test his development together with what has been done by others, but the system is again ready for others if something went wrong with one developer’s change
Thanks
Karin
Well, the slides clearly show a classic three system landscape, https://youtu.be/IU7XJXJGbmE?t=340 as what is needed, and continues to describe what is needed for installation, since this is described, this is also what SAP recommends?
In my opinion, no customers should do Continuous Integration in the setup described in the slides, as CI happens “before completing the development”(as by the SAP definition linked), and this runs on the QA system, according to the slides?
Also, see the question from Stoyko Stoev above, does gCTS roll back the entire system state, including transparent table contents? Ie. if it does not, the system state must be validated manually after each rollback?
And if the developers do the developer test/unit test in the QA system, there are no systems in the landscape, except for production, which has a somewhat steady-state?