Fotolia
Implementing modern practices in an ABAP development shop
You don't have to wait for SAP to provide modern tools for automated testing, continuous integration and other key processes. Try these five steps first.
In my last piece, I outlined one of the ways the out-of-date tooling in the ABAP development environment reduces...
Continue Reading This Article
Enjoy this article as well as all of our content, including E-Guides, news, tips and more.
development velocity and can cause management headaches. I specifically focused on the lack of modern version control, but other areas of developer tooling like continuous integration, testing frameworks and package management lag behind as well. If SAP doesn't fix these problems, what can an ABAP development organization do to pull itself into the 21st century? Some options are available.
Step 1: Automate the system-build process
The process of building a development, sandbox or quality assurance system should be able to run as a single command. Technically, this level of automation is possible with an ABAP development system, but it is rare. SAP automates the process in this way for its Cloud Appliance Library systems, and, indeed, users could employ these systems as the foundation of an automated build process targeting a cloud provider. Or they can task their Basis teams with fully automating the build process.
The benefits in cost savings and agility alone may make such an ABAP development process worthwhile. But an automated build process can also be a key enabler of several steps mentioned below.
Step 2: Work on automated test coverage
Now that your build process is automated, what about technical and functional tests? Automated software testing lets you test upgrades and support package applications with less effort, allowing for more regular, quicker and safer deployment of standard support packs as well as high-priority security updates or bug fixes. Further, comprehensive tests will allow you to make technical and configuration changes faster and more confidently and provide assurance that the business will continue running. In the long run, automating tests saves developer time, and, if functional test cases are automated as well, saves business-process expert time that can be put to use in process improvement.
Step 3: Move all workbench development objects to Git using ABAPGit
Moving all of your ABAP workbench development to an external version-control system (VCS) such as Git will allow you to start taking advantage of some of the capabilities of modern VCSs. Until you move to fully distributed development, you'll still be somewhat limited, but moving ABAP development to Git and being disciplined about pushing commits whenever a development object changes will allow quick and painless recovery from mistakes, or "rolling back the clock" when necessary. Using the ABAPGit package, published by Lars Hvam, is currently the best way to do this.
Step 4: Give developers personal development systems
Now that you can quickly and easily provision development systems, give each of your ABAP developers a system. Yes, it will require investing in hardware -- either centrally hosted virtual machines or beefy personal systems -- but the investment will help developers be much more productive.
Developers won't have to worry about security because each one can have SAP_ALL authorization in their own system. With all of the development objects in a VCS, developers will easily be able to import relevant objects into their personal systems. They'll be able to try out different approaches to problems without fear of breaking the development system or stepping on other developers' toes. Did you accidentally break something that's hard to repair? Don't spend a day trying to back out changes. Just provision another system and get back to work in an hour.
Step 5: Have the development system track a Git branch
Once all of the development objects are in a Git repository -- or other VCS -- and the developers have their own development systems, you can remove developer change authorization from the central development system. Instead, the central system can track a branch in the Git repository. Developers can make changes in their own systems and push proposed changes to a feature or bug-fix branch in Git. Once those changes pass code review and testing, they can be merged into the main branch and automatically deployed to the central development system, then transported through the system landscape as normal.
At this point the ABAP development workflow finally aligns with the standard VCS-based development workflow in use in most other environments. ABAP developers can now work in parallel instead of serially, it is straightforward to implement other common development practices like continuous integration or issue-management integration via your VCS, and most organizations should start to see a large increase in developer productivity and development quality.
The unpleasant reality of most ABAP development
If these are the steps, and the benefits are potentially so great, why isn't this standard practice? It's common in the SAP world to have 10 or more ABAP developers working on a large implementation. In most other environments today, having such a big team of developers working on a software implementation without even rudimentary source control would be seen as professional malpractice, but in the SAP world it is the norm.
SAP has not shown the way here, nor provided many of the tools, but with the development of supporting tools like ABAPGit, the SAP community is taking matters into its own hands. Steps 1-3 above are possible right now for the first time, and you can accomplish steps 4 and 5 with some creativity and collaboration with the ABAP development community. If you are a large SAP customer or run a moderate-size development shop, I urge you to get started down this path. If you've already begun the journey, please share your story to help others along.
