Agile + SAP® ... working together

Integrating true Agile processes with your SAP development efforts

Continuous Integration (CI) – is this ideal practice really possible with SAP?

6 Feb 16
Posted by curtis

I will admit I am at a loss to explain *how* we overcome the ingrained objections by SAP developers for delivering continuously. I can show them every which way to Sunday the value gained through flow, but the usual response is that it can’t be done. Then, I uncover an in-depth writeup about CI on the SAP Community Network offered up by the CTO of thought leader Basis Technologies recently posted just a couple of months ago.

 

A few snippets of interest…

Continuous Integration (CI) is a development methodology that requires developers to integrate their code changes into a central repository frequently. Each change is verified by an automated build and unit tests (possibly even automated integration and regression tests). […]

 

The goal of CI is to alert developers to breaking changes as early as possible. […]

 

I know that these things don’t exist in SAP, but we can achieve the same sort of results in a slightly different way. In fact in my humble opinion SAP offers a way to deliver software changes faster and safer than the non-SAP world.

And the post gets a bit more technical, but he mentions something pretty substantial…

One slightly distasteful side of effect of Dependency Injection [(i.e. pass a dependency in a parameter to a constructor)] is the effort required to instantiate objects with nested classes goes up. If you’re managing dependencies several layers deep they still need to be injected, so you may end up with several lines of object instantiation code before you can create the object you really want to use. Tedious is a word that springs to mind.

 

This problem has been solved and there are a tonne of open source container projects for a variety of languages, although none for ABAP. At my current organisation we rolled our own container, which we may well make open source if there’s enough interest.

 

A container is simply an object that knows how to instantiate and configure objects. And to be able to be successful it needs to knows about the constructor arguments and the relationships between the objects. Instead of creating objects yourself, you ask the container to create them for you.

Yes, Darren, there should be interest in your container in open source.. He continues…

The challenge for the off the shelf CI servers is that they don’t integrate with SAPs change mechanism elegantly or at all! The concept of a “Broken Build” doesn’t apply in quite the same way to SAP because we ship micro changes (i.e. small transports).

 

Micro changes are the reason why SAP can can deliver changes quickly in a way fully compatible with Agile.

 

In my organisation we have a created a tool that integrates into ABAP Unit for ensuring that unit tests are green before a transport is shipped. We can attach rules around code coverage to prevent code with limited test coverage being shipped automatically i.e. it can still be shipped but it has to be a conscious decision.

 

Provocative thoughts!

 

Read the full article here. (dated 9 Nov 2015)

 

 

Tags:

Leave a Reply

Your email address will not be published. Required fields are marked *

Comment moderation is enabled. Your comment may take some time to appear.

February 2016
S M T W T F S
« Jan   Mar »
 123456
78910111213
14151617181920
21222324252627
2829  
Share This