Skip to Content

Continuous integration (CI) in software development as part of quality control is a hot topic. The idea is to ensure that the time needed to get a functionality working is decreased while at the same time improves the quality. This is done by giving instant feedback of how new code affects the overall solution. This behavior makes CI preferred for in agile projects, but is not limited to.

While the concept of CI isa convincing – or should be – to everyone that ever has coded a piece of software that does more than hello world, the implementation of CI is a complex task. Just using a CI system does not mean that you use CI. You have to provide test cases (a lot!), metrics about performance and code quality, collaboration tools, and so on. While a CI system can be used standalone, it should be part of several quality control solutions that work together.

How does CI work?

A CI system watches a code repository for changes. As soon as a change to the code base is committed, the CI system starts building the code and runs the quality tests. These can consists of unit tests, deploy, performance / functional / integration / etc tests and creates a report. Important here is that in case a job reports an error the developer that committed the new code gets informed that his/her code broke the build. The final result of the job is made public to all involved participants so everybody get an actual view on the state of the solution.

An important aspect of CI is that the whole process gets triggered when code gets committed. CI is not a nightly build. A best practice is to encourage developers to commit their code at least once a day. This does not mean that they only commit before leaving the office, all day code commit occur and throughout the day a new version of the software gets build and tested by the CI system.

Continuous Integration == Hard Work

As you can see in the above description, it’s not enough to simply have a CI system. You need to have a build system that works with the CI system. And only having a build that compiles is not enough: you have to provide test cases. You need unit tests that really test the code; functional tests like browsers; performance tests to know if the new functionality executes in the established time limits. Your CI system has to be able to automatically deploy the code to a system and to invoke other quality systems.


Before you can start using CI, you have to analyze your development infrastructure and ask some simple questions:

  • Does your development infrastructure provide the basics for CI?
  • Can you modularize your build?
  • Can you provide meaningful tests?
  • Do you have KPIs?
  • Do you know what other solutions are using the functionality of the application or may be affected by changing it (performance impact when running on the same server)
  • Many more

Why do all the hard work?

Looking at all the points and issues raised above, a simple question comes to mind: Why do all the work for my applications? The biggest issue with CI: you do not get immediate results. Contrary: you will slow down your development and add a lot of work load to everybody: not only the developers, but also to the people responsible for tests, the quality, the help desk and end users. The most important and critical part of CI are the tests. If you test too little or wrong, errors may slip through and manifest in production. On the other side, you cannot test too much J Creating tests needs time, more time than you think or the project manager is willing to spent and will never come to an end.

To start gathering tests it’s a good idea to look at the end users error reports already raised (and solved). These errors already occurred once and should never occur again. Once you have some useful tests you will see getting the first results: broken builds not because of compilation errors but because of errors found in the test cases. And the best thing is: automatically. Instead of letting the developer code his application and test it in DEV, later transport it to QA and run there some (manual) tests – too often this is done close the deadline of the project – the application is tested already in DEV. The QA team can focus on load testing and how the application performance with a realistic set of data. Short: errors like a not working submit button won’t be found in QA. A modular build process is only the first step: for an effective CI you’ll get a landscape that is fully modularized and automated. No need any more to do or wait for a manual transport, to start the tests, to wait for the test results: you get everything automatically.


Continuous integration and SAP

Looking at CI solutions available at the market and developer conference sessions it is clear that CI is no longer a niche idea. For several programming languages CI systems are available that integrate nicely with code revision systems and quality tools. Exception of the rule: SAP.


Automated builds, transports, deploys, tests, immediate feedback and transparency. Sounds convincing, still hard to achieve in an SAP centric landscape. Even when you solve the basic CI integration problems you still have to deal with how SAP is run. Ask yourself: an automated deploy to your QA system because a developer committed some source code: Is this possible? Does the governance of the system or transport management allow this? Can you run tests in the QA system on your own or only the QA team is allowed to do that (and has the tools). Another problem are the test cases.  You don’t get a set of tests from SAP nor test examples. You have to create your own set of tests. The CI system has to be able to trigger the tests: your QA software has to offer a remote start/control functionality.


What makes it hard to use CI together with SAP?

For most, SAP equals ABAP, but it’s more complex. There is NetWeaver ABAP, Java, on top of it specific solutions like CRM, SRM, BS, than the integration part, a lot of different technologies and so on. It is hard to predict what is effected when a function module is altered. What frontends are effected directly and what about the other transactions that use the FM? Or when the Java application writes slightly different data into the table? And will you mobile app developed with SUP still show the data correctly in the list?

ABAP development is a little bit different compared to what a CI normally expects. An ABAP developer works in the system, while a CI system needs to interact with the system from the outside: get the code, transport, deploy, run the tests. In ABAP there is not really a commit, and while recent versions of NetWeaver ABAP offers unit tests and eCATT, it’s not like you can do this with every version or get an external tool that triggers the tests. If you check the plugin list of Jenkins (https://wiki.jenkins-ci.org/display/JENKINS/Plugins), you can see that there are not SAP/ABAP specific plugins listed, making it hard to implement a useful CI solution in an ABAP landscape. Even when you use CI for your non-ABAP applications that use some ABAP functionality, a change to the ABAP code line won’t trigger the CI system.

For Java and SAP the situation might look better as Java is natively supported by CI systems like Jenkins. In reality it’s not much different than with ABAP. The developer uses SAP’s own Java SDK (NWDS) that comes with build in wizards for code generation and deploy. Additionally you get an external code revision system (NWDI), but working with it remotely is only doable – note: not easy – with tools from SAP. A big issue is to modularize the build, make the CI aware of NWDI and in case of WDJ: to write unit tests. WDJ applications are written in a mixture of XML and Java syntax that has the name Java in it, but at the same time is not Java. Then you have the DC and public part concept that creates more trouble and headaches than helps developers solving dependencies. Things get better for J2EE or SAP Portal developments as there you are actually developing in Java (constructors, method overloading, inheritance, polymorphism is available). Writing unit tests is like for every other J2EE application. You can use your own RCS, you can create your own maven of ant script for building the jar / war / ear files. It would be way easier to get started with CI for a SAP Java project if SAP provided maven/ant scripts and repositories for dependency management.


No continuous integration for SAP?

CI is not easy to implement, and even when a SAP wide implementation of CI is unlikely you should at least try it for your projects and applications. Start small. Get started with your infrastructure, select some tools, find out how to automate tasks and create test cases. Write unit tests for your code. Gather KPIs. The easiest start should be from the Java side and for J2EE projects as these come pretty close to non-SAP Java developments. CI scenarios and setup guides for these kinds of applications are easy to find.

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Adam Krawczyk

    Hi Tobias,

    I must admit it is exception blog and great content, thank you for posting it! I agree with your point of view.

    I would like to underline importance of Unit Tests. When developer is creating program, he should know domain exactly so he is able to prepare input and output parameters for tests methods that are real, expected later in production system. We can test a lot with Unit Tests and support end user testing much. Good modularization is the key. It is difficult to write unit test for method which performs 10 steps in row but we can try to write tests for these 10 separated steps actions and assume that main method will still work correctly. I am not saying that we need to test full program flow – functional and user tests are used for that.

    I always repeat that each single Unit Test case matters. If we start to create unit tests in place where they are not present, we create small islands of tested code which after time can join into wider areas of good quality, well tested code.

    I agree that there are not much tools that supports Continuous Integration in SAP. If you are still interested in the topic, please refer to my document where I have shown example of ABAP Unit Tests integration with Hudson server:

    http://scn.sap.com/docs/DOC-41868

    In context of it, some comments to your text:

    • In ABAP check in, compilation and build of commonly available source code is actually solved by activation – there is central repository and we have always active version of executable code.
    • “Check out” corresponding ABAP option is edit/lock mode or saving object without activation.
    • As good Unit Tests are database and resources independent, they rely on memory data and values defined in tests. That is why it is not important if we run them in development or quality system – no difference in case of data availability.

    And of course – idea of Continuous Integration is great but works only if people are aware and involved into it. Even best available framework will not help if there is no users engagement and not much tests created.

    Kind regards!

    Adam

    (0) 
    1. Swapnil Shelke

      Hi Adam,

      Can you give details of how you configured Hudson with ABAP repository?

      I am trying to configure with Java- DTR /NWDI but no success yet.

      If you provide steps in detail then I will try to configure with Java NWDI.

      Thank you.

      Regards,

      Swapnil S. Shelke

      (0) 
      1. Adam Krawczyk

        Hi Swapnil,

        Hudson integration that I described is custom development: Z* report is running unit tests using SAP standard reports. Tests results are collected with code coverage values and written to XML file which is then uploaded to Hudson server for visualization. Details are described in my link. I think there is no standard integration between Hudson and ABAP world yet.

        Regards,

        Adam

        (0) 

Leave a Reply