Continuous integration

[hofmann]

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.