To the existing SAP development audience – git and abapGit can be curious things. Why did SAP ABAP need to have git when CTS has reliably moved and tracked changes across SAP environments for years? Obviously it’s useful for open source ABAP – but really what else?
In case you missed it: abapGit can be adopted even if you’re not intending to open-source your development on GitHub. And I firmly believe its advantages to your development process are significant enough to consider using abapGit for your company’s internal ABAP development efforts. And while GitHub remains the defacto king of git repositories – know also that abapGit can be used upon other git offerings like Azure DevOps, Bitbucket, Gitlab and others.
Here are a few of the ways that abapGit transformed my development approach I’d like to share.
1. Improved metrics on development productivity
If you’re managing a team of ABAP developers – it can be challenging to figure out what exactly they are working on each day. The solutions being worked on by each team member can be very complex and the requirements are often time-critical.
How then do you best monitor developer activities without intruding on their time? Agile stand-ups in theory are meant to capture this – but can frequently instead go off topic or extend far beyond an intended 15 minute limit.
Also at an individual level – how do you as an ABAP developer self-report and self-evaluate your progress? Given the swiftly changing priorities SAP developers must often pursue, it can be hard to really speak to what you worked on even earlier last week.
In git – the task of writing a commit and pushing to a branch is often a non-invasive task to do. It takes only a moment of your time as a dev, but it accrues value over time having an on-going log of your work.
I generally encourage developers of all kinds to try out doing at least 1 code commit pushed to a repo per day. After doing this for a period of time, you have a stronger sense of self-accountability in your development goals. For development managers, I think the code commit history is a great way to get unbiased observation of your team member’s development task progress. Sometimes for what you may lack in desired customer results – you can make up for in demonstrated consistency towards a goal.
If you take nothing else from this blog: try doing one abapGit (or general git) commit each day, pushed to the remote repo. Start with yourself, but also have other team members participate as well.
Sometimes when I feel bogged down in other non-development work – I stare down my own git commit history in the recent months of building proUBC. It’s a great way to get a birds eye view of what your day to day tends to be like – especially if you’re trying to juggle development and non-development workloads personally.
2. Urgent fixes, rework, code analysis, and other dev quality are handled in more nimble and transparent way
One of the most frustrating tasks ABAP developers can frequently encounter is object contention and collisions or similar tasks of rework for bugfixes. And here’s a few of the ways many ABAP developers deal with this frustrating occurrence: a lot commented out code, entirely newly-named object copies, monolithic N+1 environments to handle parallel versioning, lengthy cross-team bargaining, experimental sequencing of change imports, or total change blackouts. These solutions can sometimes actually contribute to the object collision or rework problem rather than resolve it when they increase the amount of manual effort required to resolve object contentions.
If you have an object contention – frequently your basic need is get a set of code and objects from specific state and specific point in time and decide how to best proceed. This can difficult to do manually if you’ve had several conflicted CTS tasks incubate for a long period of time. However git branching and commits are that anchoring piece of data that allow you take yourself easily to that desired snapshot of code and object state. Have an issue? Restore the code from a specific commit and branch. This can be far less risky than peering at ABAP objects line-by-line to determine what changes to keep or remove.
Even without object contentions or rework – the code quality practices you commonly see in SAP projects can seem nightmarish and monolithic. Not at all because of the coding guidelines used, but because of the extensive documentation and review of the code change that’s often demanded in dozens of pages excel sheets and word docs. Every time I’ve used excel to review code quality on my projects or my colleagues – it always felt like I was being pulled out of the element. To do the code quality review work well – I really wanted to comment and annotate in the same place where the code and development lived and could be addressed if needing a fix. Too often – I’ve had the feeling with word/excel based code reviews that the changes asked for simply really wouldn’t be attended to.
In contrast – git does a great job co-locating these review and quality practices with the code – but without forcing too many comments. You can quickly suggest a code edit in a separate branch that coworkers can incorporate to a merge to their dev branch. Before merging all changes to the main branch (think releasing a TR if you’re an ABAPer still not familiar with git), git repos allow for commentary and review to take place upon the pull request.
Overall – git does a phenomenal job of capturing developer’s thought process while making and reviewing changes. That’s rather useful in ABAP both in the moments of production go-live and ongoing long term platform sustainment. All too frequently – its challenging for project teams to successfully extricate themselves and hand off to production support because of the reoccuring questions. “What was this developer thinking?” is common question ABAP developers face day to day.
3. Development can become more organized and portable
Do you have a ZSD or ZMM package in your SAP ABAP environment that seems to attract every new object like a magnet and creates dependencies? If you do – you probably have a goal of doing more consistent modularization of your ABAP developments into separate packages. As hard as we try to document cross-WRICEF dependency graphs, the effort is long and major dependencies can be easily overlooked.
What you’d probably like to do is to splice some code out of one environment, and put it into another clean environment to see what works and what doesn’t. With git, satisfying this need is putting together a repository in one environment – then pulling that repository in a new, clean environment.
Without git, you may attempt to import/export code manually or do a transport – but those approaches have drawbacks for this kind of development activity. You want to generally keep the activity quick, simple and not force any probability of an object lock.
4. Archiving legacy code becomes more simple and cost effective
The nice thing about abapGit is that it can version and host ABAP code without requiring an ABAP server. This is an excellent feature for archival of code as well as development.
The task of retiring old ABAP systems can be a tricky one – if you lose access to a SAP system because it gets shut down, what do you do if you’re asked to investigate or revive some custom business functionality? Many times in preparation of such a thing to occur, I’ve witnessed ABAP developers scrape code line by line into text files or word docs. Other times, the legacy system gets shut down and the custom functionality that the customer wants back 6 months later is seemingly lost forever.
If you’ve worked in Basis administration before – I have a hunch you’ve begged a development team to let go of an underutilized ABAP server that had some pre-release/pre-upgrade code. Being able to confidently and quickly follow through on retiring unused systems can be a big money saver.
Many other times without abapGit – custom code lives and dies in the development system and production environment it began its life on. When S/4 HANA implementations occur, off-ramping legacy programs while retaining understanding is a challenge that undoubtedly keeps team leads, CIO, and business users up at night. Having your legacy code tucked away offline in abapGit can be a way to give teams peace of mind in moving forward with various object retirement plans.
5. Cloning repos > Copy / paste from website
Just because you’re not writing open source code, doesn’t mean you can’t use it! There are many great open source ABAP projects with generous open source license terms that empower you to use the open source solution freely for use at your company (Yours truly works on one that brings blockchain integrations to SAP).
The trouble is – that in the year 2023 – there are too many ABAP developers haven’t touched an git repository. There’s this ongoing meme that every month someone creates a ‘how to generate an excel file in ABAP’ blog that doesn’t use the abap2xlsx library. I don’t think the issue isn’t abap2xlsx itself. More broadly, I think its that culture shift to open source hasn’t permeated ABAP developers nearly in the way it has everywhere else. By ABAP’s nature and context – a lot will be understandably closed off to the world – but this shouldn’t eliminate some of the fastest ways.
There’s likely an abapGit open source project out there that makes developing one of your upcoming projects faster. A good example of this may be abap-openapi in which HTTP proxy classes are automatically written for you in ABAP from an OpenAPI definition. In personal experience – using abap-openapi was faster and more simple than trying to use SPROXY/CPI/PI/PO to orchestrate API calls. It wasn’t perfect – but it removed a lot of menial coding.
6. Global code reuse across internal systems becomes more achievable
If you have some common utility classes and other programs used across a multitude of SAP systems, you’ve probably scratched your head how to easily get them all versioned the same.
Defining a transport route that propagates code across multiple SAP systems for this one off purpose is sort of risky. And manually applying the change in each system is too time intensive to be feasible long term.
Why not have it as an abapGit repo? Syncing the changes can just be a pull away! If there’s any system-specific deviations – you could always have that in a specific branch that doesn’t merge to the others.
7. You will be better positioned to apply CI/CD and Agile processes to SAP development
The concept of branched, parallelized development can be a foreign one to an ABAPer who has only ever known SAP systems that have one active version of code at a time. In some ways, the way in which ABAP development-production environments are typically deployed doesn’t cater to parallelized development very well. But nonetheless, there’s yet a desire to achieve CI/CD in ABAP development environment in interest to servicing your business users better.
In ABAP – our primary control tower for managing changes in the environment is CTS and Charm. In reality though, other systems like Jira or ServiceNow cast a big influence in how CI/CD and Agile are to be implemented in a corporate environment.
If you’re using abapGit in your company’s internal git host like Bitbucket or Azure DevOps, chances are good you could leverage CI/CD resources already implemented by your company. For example – your corporate Bitbucket may be implemented in such a way that a Jira issue of a particular status must be included in the git commit message. This can be used to facilitate better agile development practices in SAP development teams. Something like this is possible in Solution manager too – but if it was already implemented across the rest of the IT org, why reinvent the wheel?
No comments:
Post a Comment