The main reason why we are starting Git-based development at Basis Technologies right now is that we are about to embark on a long-lived project that will touch a lot of our codebase, and we can’t stop the world until that’s done. We anticipate hundreds of conflicting “files” (out of about 10k) and we’re expecting that Git will make this a manageable process, albeit not painless.
The key is: we want to clean up our codebase as much as possible before we start.
“No battle plan ever survives contact with the enemy”
Will likely change as we go, but for now roughly looks like this:
I’m a big fan of Pretty Print, almost always run it before saving. I find it tedious to manage indentation and capitalization manually. And when everybody uses the same settings it allows more uniformity in the code and smaller diffs. Sadly it’s not our starting point.
When formatting is uniform, a small change will look like this:
When it’s not it will look like this:
The sample pictures are JavaScript files, but apply as well to ABAP. Yes, in SAP GUI we can ignore case and spaces, but in our scenario merge will happen and most merging tools don’t understand ABAP syntax. While it might be possible to work around it I think standardising the code formatting is a good idea regardless.
I wrote a small command line utility to automate this task.
We plan to track in Git all development done, both with and without TMS. Changes done in the main dev system will go to a branch only used to keep track of changes made there, tested or not. This will only be used for auditing purposes.
Changes who make it to pre-production will be tracked on the master branch. We will use the ABAP Get background feature, and will probably create our own background mode to allow cross referencing commits with our issue tracking software (Jira).
For the Git-managed project branch, every developer will have its own repository and send pull requests to the central one
Merges will happen on user laptops and get on the main repo via pull requests until the end of the project. Then a transport with the delta between the merged project branch and the master branch will be generated and fed to the main dev.
Any conflict with changes imported in pre-prod will be ignored, as they’re already in master. For the others we don’t have a solution yet.
The most obvious options are:
Merge once the project is completed. This has one big advantage:
...and quite a few disadvantages:
Our favourite option is to merge small chunks frequently.
This way we will probably end up merging the same bit of code multiple times, but has lots of advantages:
Ideally one would like to avoid long lived branches altogether, but here is not an option. Keeping the project one in sync with main will mitigate the disruption caused by the final merge.
Some preparatory actions have already started, but most of the real work will begin in June. We will probably make some adjustments along the way, and I definitely plan to try this approach on a smaller scale before committing to it.
But that’s the plan for now. If things go well we might even end up making some version of this part of our regular process. Or perhaps we’ll regret we ever tried. I guess only time will tell.
Previous episodes: part 1 and part 2
The key is: we want to clean up our codebase as much as possible before we start.
The plan
“No battle plan ever survives contact with the enemy”
Will likely change as we go, but for now roughly looks like this:
- Clean-up the codebase:
- Complete as much WIP as possible
- Consolidate our codebase - we want to start as close as possible to production, but including a number of beta and unreleased additions
- Standardise the code formatting
- Align the main dev system with the resulting code
- Start developing two branches independently:
- 1. The long-lasting project using abapGit
- 2. All the rest with a traditional TMS workflow, but committing every change to Git once it gets past QA
- Merge the two
- Run an extensive regression test
Code formatting
I’m a big fan of Pretty Print, almost always run it before saving. I find it tedious to manage indentation and capitalization manually. And when everybody uses the same settings it allows more uniformity in the code and smaller diffs. Sadly it’s not our starting point.
When formatting is uniform, a small change will look like this:
When it’s not it will look like this:
The sample pictures are JavaScript files, but apply as well to ABAP. Yes, in SAP GUI we can ignore case and spaces, but in our scenario merge will happen and most merging tools don’t understand ABAP syntax. While it might be possible to work around it I think standardising the code formatting is a good idea regardless.
I wrote a small command line utility to automate this task.
TMS and Git integration
We plan to track in Git all development done, both with and without TMS. Changes done in the main dev system will go to a branch only used to keep track of changes made there, tested or not. This will only be used for auditing purposes.
Changes who make it to pre-production will be tracked on the master branch. We will use the ABAP Get background feature, and will probably create our own background mode to allow cross referencing commits with our issue tracking software (Jira).
For the Git-managed project branch, every developer will have its own repository and send pull requests to the central one
Merges will happen on user laptops and get on the main repo via pull requests until the end of the project. Then a transport with the delta between the merged project branch and the master branch will be generated and fed to the main dev.
Any conflict with changes imported in pre-prod will be ignored, as they’re already in master. For the others we don’t have a solution yet.
Merging strategy
The most obvious options are:
Merge once the project is completed. This has one big advantage:
- Merging is an expensive operation, and this allows you to only do it once
...and quite a few disadvantages:
- Will be a big, complex job difficult to split between developers
- Whatever goes wrong we will only know at the end of the project
- Not very agile or DevOps
Our favourite option is to merge small chunks frequently.
This way we will probably end up merging the same bit of code multiple times, but has lots of advantages:
- Individual merges are small, a single developer can handle it without a sweat
- If the workflow is problematic we will know it immediately
- It’s agile and DevOps
Ideally one would like to avoid long lived branches altogether, but here is not an option. Keeping the project one in sync with main will mitigate the disruption caused by the final merge.
Conclusions
Some preparatory actions have already started, but most of the real work will begin in June. We will probably make some adjustments along the way, and I definitely plan to try this approach on a smaller scale before committing to it.
But that’s the plan for now. If things go well we might even end up making some version of this part of our regular process. Or perhaps we’ll regret we ever tried. I guess only time will tell.
Previous episodes: part 1 and part 2
- SAP Managed Tags:
6 Comments
| User | Count |
|---|---|
| 6 | |
| 5 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 |
