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.
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.
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
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.
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.
Of course you can use your own git server but in this case we will be using github:
Ok, now your ready!
Now comes the easy part. Everytime you develop something in Cloud Application Studio make a git commit.
When you finished your work or want to synch developments make a push and all your commits will be transferred to github:
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).
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!
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:
- Create an account on github and create a repository
- Remember the git URL of your repository. You can see the URL here:
- Install the git client on your computer
- Create a ".gitignore" file in your Cloud Application Studio tenant folder (normally ~/Documents/CopernicusIsolatedShell/Projects/<YOUR_TENANT_NAME>)
Update: juergen.tessmann shared with me an extended ".gitignore" file which includes also some Visual studio interanl files:
## ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
## SAP Cloud Appplication Studio
.lock
*.session
*.xrep
## ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
## Ignore Visual Studio temporary files, build results, and
## files generated by popular Visual Studio add-ons.
## Version from 23.09.2019
## Get latest from https://github.com/github/gitignore/blob/master/VisualStudio.gitignore
# User-specific files
*.rsuser
*.suo
*.user
*.userosscache
*.sln.docstates
# Build results
[Dd]ebug/
[Dd]ebugPublic/
[Rr]elease/
[Rr]eleases/
x64/
x86/
[Aa][Rr][Mm]/
[Aa][Rr][Mm]64/
bld/
[Bb]in/
[Oo]bj/
[Ll]og/
[Ll]ogs/
# Files built by Visual Studio
*_i.c
*_p.c
*_h.h
*.ilk
*.meta
*.obj
*.iobj
*.pch
*.pdb
*.ipdb
*.pgc
*.pgd
*.rsp
*.sbr
*.tlb
*.tli
*.tlh
*.tmp
*.tmp_proj
*_wpftmp.csproj
*.log
*.vspscc
*.vssscc
.builds
*.pidb
*.svclog
*.scc
This tells git to ignore the lock and session files. Otherwise you might get an error when commiting. - Start git bash
- Execute git config
git config --global user.name "<YOUR_USERNAME>"
git config --global user.email "<YOUR_EMAIL>"
- Change to your C4C tenant folder
cd Documents/CopernicusIsolatedShell/Projects/<YOUR_TENANT_FOLDER>/
- Initialize the repository
git init
- 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 masterIn 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!
- SAP Managed Tags:
4 Comments
