Skip to Content
Technical Articles

Using Git “one-way” with SAP Cloud Application Studio (C4C)

How you organize your coding as a team is one of the most important things to consider before you start developing. Most programming environments support you with a powerful built-in repository or you can use integrations with third party repositories to synch and modify code (e.g. git).

The feature set of such tools includes functions like checking out code, clone developments to work in parallel, merge coding, and so on. You can track changes, make code reviews and set-up a continous integration pipeline to deploy your coding in a standardized and automated way.

Unfortunately SAP Cloud Application Studio comes with a very poor version control system (gently speaking). In this blog post I will describe how we achieved a one-way integration (no pull) with git and why this is still very beneficial and helps us a lot to get cleaner code in our solution.

Version control in SAP Cloud Application Studio

The repository of the SAP Cloud Application Studio supports checking out and checking in of objects like ABSL methods. This is to prevent parallel development on the same object. There is no way to see what changes were made after checking in and no overview about new created objects. If you work in a group (that means more than one developer) it becomes quite hard to track what happens in your solution.

Furthermore if you’re crazy enough (we are!) to work in a 3 system landscape and try to establish some kind of “agile development” or “continous integration” (I put these terms in quotation marks since real CI seems impossible) you will face the problem that once something was assembled it will rest in your solution forever and ever. There is no way of renaming, moving or removing of objects after that (that’s said maybe someday SAP will enable deletion of objects).

With this known restrictions it becomes crucial to have some kind of code control if you start to develop a serious C4C solution because otherwise you have a high chance of messing up your solution with no way back (we did). This is where git comes in.

What is git?

Git is the heaven on earth for developers. It is used to track changes in files (e.g. coding), you can work on different branches of the same coding (e.g. one branch for a bug fix and another one for a certain feature) and assists in merging these branches again. There is even an ABAP integration with the popular ABAPGit framework of Lars Hvam. The principal operations are

  • pull: Download a version of the repository into your local repository
  • commit: Save changes in your local repository
  • push: Upload your local repository

A normal git-workflow is a pull, then many commits and finally a push to synch back your files. For more information just look it up on wikipedia.

The one-way integration in SAP Cloud Application Studio

First things first: Since Cloud Application Studio is always fetching the solution from its own repository it is impossible to do a pull to get your code from git. However the thing you can do is to commit and push your code back into your own repository. This is why we call it the “one-way-integration”.

For normal developers this might be already a no-go and nightmare but with the C4C restrictions mentioned above this actually enables the team to get back control over their code. Before assembling a solution we use git to do code reviews and in particular we’re checking all new objects which were created because this is the last chance to rename or (re)move them.

How-To

Set-up (with github)

Of course you can use your own git server but in this case we will be using github:

  1. Create an account on github and create a repository
  2. Remember the git URL of your repository. You can see the URL here:
  3. Install the git client on your computer
  4. Create a “.gitignore” file in your Cloud Application Studio tenant folder (normally ~/Documents/CopernicusIsolatedShell/Projects/<YOUR_TENANT_NAME>)
    .lock
    *.session​

    This tells git to ignore the lock and session files. Otherwise you might get an error when commiting.

  5. Start git bash
  6. Execute git config
    git config --global user.name "<YOUR_USERNAME>"
    git config --global user.email "<YOUR_EMAIL>"​
  7. Change to your C4C tenant folder
    cd Documents/CopernicusIsolatedShell/Projects/<YOUR_TENANT_FOLDER>/​
  8. Initialize the repository
    git init​
  9. Set your git URL for synch
    git remote add origin https://github.com/<YOUR_REPOSITORY>.git​

Ok, now your ready!

Daily Doing

Now comes the easy part. Everytime you develop something in Cloud Application Studio make a git commit.

git commit -a -m "<SOME_DESCRIPTION>"

When you finished your work or want to synch developments make a push and all your commits will be transferred to github:

git push origin master

In Github you can see the code changes and e.g. create issues when you see something which needs to be adressed with the developer (check the github Tutorials for all available features).

Conclusion

This integration is far from being called a good solution but still it enables us to keep our developments as clean as it is possible within the restrichtions of SAP Cloud Application Studio. Of course we all are dreaming of refactoring capabilities like renaming, moving or deletion but a small step is better than no step.

If you are really thinking about making bigger developments in C4C in a 3 system landscape I really recommend at least considering this method of seperate version control because I assure you that sooner or later you will run into problems of code governance otherwise.

I’m looking forward for comments how you try to keep your ABSL code in shape!

2 Comments
You must be Logged on to comment or reply to a post.
  • This is fine as long as you only have one solution with one tenant. But once you have

    • Multiple solutions in one tenant
    • Multiple customers in one tenant (when you have a real development tenant whose version moves along with PRD)

    You have multiple solutions in the same folder. And a solution is only updated if you open it. Then run into the problem that, if developer 1 changes something in Solution A and commits/pushes this and developer 2 changes something in Solution B and commits and pushes this, the solution A folder in developer 2’s push will be the old version without developer 1’s change. This creates merge conflicts.

    Each developer then needs to take care to only stage changes to the solution they actually changed.

    We’re working on a system to copy the files to a separate folder and have the git repository there.