Last weekend I got the change to present the Open Source tool “ABAP Continuous Integration Plugin” at the SAP Inside Track in Vienna. Thanks to the two organizers cadaxo and ecosio for making this event possible.
This Community-driven event was a perfect opportunity to learn about Custom Code Migration to S/4HANA, SAP HANA Advanced Analytics, Elastic Search, Cloud Programming, Pretotyping and a surprising insight into OOP. Not to forget: about one session I have simply “no comment? (see comments of this blog)”
Beside that I really liked the discussing opportunities about the different styles of developing ABAP and getting home with a lot of new ideas. Of course also because the main target of the above mentioned Eclipse plugin is to improve and speed up my, but hopefully also the ABAP development flow of other ABAP software engineers.
In this blog I do not want to give an introduction about this ABAP Continuous Integration Plugin. For that I would like to point you to the presentation slides, the documentation or maybe the Source Code which of course is publicly available. The aim of this blog is to share some questions and valuable feedback I got at the SAP Inside Track in Vienna and maybe encourage you also to share your thoughts and inputs about the plugin as response to this blog.
Current status of source code state visualisation with a status bar widget
“Interesting tool, but I do no write Unit tests”
The trigger to write this plugin was to automatically run Unit tests after each activation of an ABAP development object. But in the last weeks and months I extended it also to run ATC checks too. The Unit test run and the ATC run can be both independently activated or deactivated in the Eclipse preference section – thus the plugin can also be used with ATC runs exclusively if unit testing is not used.
And by the way there is also the option to automatically format your ABAP source code or color your ABAP projects (DEV, QAS, PRD) with different colors, so hopefully some time saving functionality is included for everybody.
“Unit tests are part of the ATC run, why they are run separately”
Well the main reason to keep this two runs separately is that I think Unit tests should be fixed in any case immediately if they broke. I think there is a lot of benefits in caring about ATC findings directly in the moment when they pop up, but as they mostly do not broke the implemented features they have not always priority one.
Another reason is that the default configuration of the plugin is different for Unit tests and ATC checks. On each activation the plugin runs Unit tests for the whole package but the ATC checks only for the changed ABAP development object and thus two separate ADT calls to enable this option, which I think is the most used.
One thing I took with me is that there should be a sorting and filtering in the shown failed ATC tests (ie. in the mouse over in the status widget). Will be included in the next version.
“I activated the automated ATC checks and they took too long (because of using a detailed ATC check variant)”
Well thats a point. If you use an ATC variant with a lot of activated checks (ie. SAP S/4HANA ATC checks for custom code migration or the Open Checks initiated by Lars Hvam) then the automated checks can take some time.
It should be improved a lot in the last weeks as since recently the ATC checks are only run for the changed activated ABAP development objects but not for the entire package as before. And of course the plugin can be configured to only check the most important checks. The comprehensive check with all checks included can be done then before releasing the ABAP transport or also once daily by Jenkins or another central tool.
In any case performance is of course a point to stay focused in future, because the plugin should not be a beetle with welds but a cool sportscar to take an analogy of the automotive area 😉
“Can it be ensured that every developer in the company uses this plugin (in the same way)”
Well I would be delighted if the plugin is used extensively and I thought a bit about that option. Finally I think the plugin should remain something which belongs to the developer and is part of his/her working place. Therefore I am not in favor to add a functionality which forces the usage of something.
To ensure a common strategy on Quality or Continuous Integration tools there are also better standard centralized products like the Solution Manager or Jenkins for example.
There are some ideas already, but nothing planned in detail. Therefore I would like to close this blog by encouraging you to install the plugin or update it to the latest version and I want point out onces again that
Questions, feedback, issues but also feature and pull requests are always welcome.
Installation with the Eclipse Marketplace directly within Eclipse