As we see more and more customers adopting the cloud based development methodologies in SAP especially with customers adopting XS Advanced and SAP HANA Cloud as their data warehousing or data mart solution, there was need to lay down some best practices for source code management and version control. This blog post talks about some of the best practices to be followed while working in a parallel development environment especially while working with multiple features development.
This blog provides best practices for sequencing using git based tools and addresses the following pain points:
- How to build/deploy different features in different systems in the landscape and not have a deployment conflict ?
- What to do in case a feature is not ready, and there’s a Priority 1 bug is to be fixed ?
- How to select or drop a feature/commit in case of an erroneous situation ?
Why is branching strategy important:
Branches are primarily used as a means for teams to develop features giving them a separate workspace for their code. These branches are usually merged back to a master/main branch upon completion of work. In this way, features (and any bug and bug fixes) are kept apart from each other allowing you to fix mistakes more easily.
Herewith a sample branching model:
This branching strategy consists of the following branches:
Master: main branch
Develop: where the developers merge their changes.
Feature(s): to develop new features that branches off the develop branch
Hotfix: also helps prepare for a release but unlike release branches, hotfix branches arise from a bug that has been discovered and must be resolved; it enables developers to keep working on their own changes on the develop branch while the bug is being fixed.
The main and develop branches are considered the main branches, with an infinite lifetime, while the rest are supporting branches that are meant to aid parallel development among developers, usually short-lived.
How would the flow work:
Let’s start from a state where all the systems in the landscape have the same code running. For building new independent features, multiple feature branches are created by multiple developers:
Now, let’s say, each of the feature branch, the code was tested by individual developers and let’s assume, the unit testing succeeded on built containers.
Note: Practice to follow keep committing the code as and when ready and keep fetching the changes often made by other developers so that each developer always has the latest code and better coverage on unit testing. For example: daily
If in case, the unit testing on either of the feature branches, fails, then that feature branch would not be merged further.
Once, the unit testing is completed successfully, the code from each of these feature branches is merged into a new branch called D-CONS (consolidated branch in development environment)
In D-CONS branch, let’s assume after completing Functional/Integration testing, it was identified that that the code from Feature 2 brought an issue.
Usually, in such cases, we have two options:
– Fix the issue if the fix is known
– Revert the change made which caused the issue
Merge takes care of combining the changes not having to do selective deployment.
Since, the code in feature 2 branch must be re-worked, it cannot be moved further. Handling another corner case here, where we carry out additional test cycles after merging F1 and F3 to D-CONS-2 to see if F1 and F3 work fine or not without F2.
It was identified that F1 and F3 work fine together but F2 needs more time to get a fix, so, F1 and F3 after testing were merged with the main code-line of DEV and a new version was created as V2. This is needed so that if a developer now must fetch the code, will fetch the latest from V2. It’s important to note here, is D-CONS schema is different from original DEV container.
Differentiating container can be created with the help of .mtaext
Once the code is merged with V2, we could do a XS deploy in DEV depending on if such a deployed version of the master development branch is needed in the development landscape. In some cases, it may be needed, so yes, following the merging of the successfully tested feature branches into the main development branch the new version of this branch should be deployed to the (existing) HDI container. MTA version number can also be increases.
With that, we’d proceed to the next environment: Quality
F1 and F2 are merged in QA CONS branch and tested for non-functional requirements like memory, CPU, and execution time. The QA-CONS branch must be deployed for testing. Logically it would be deployed into a corresponding “QA-CONS” HDI container to separate it from the main QA HDI container. That means the applications used for testing must take a potentially different schema name into account (if a dedicated QA-CONS HDI container is used). To test in QA and UAT landscape, pointing the reporting tools to this new container can be a big task, in that case: Have only one version of the report but make it point to the _CONS container.
Let’s proceed to the testing cycle in QA and it was found that F1 failed but F3 succeeded. Please Note: The testing takes place using the reporting tools and testing is carried on the respective deployed container. Since, only F3 succeeded in non-functional tests in QA, the code from F3 will be merged with V2 in QA and with the branch in PROD
The branches, QCONS, QCONS-2 could be deleted once the code is merged with V2 or QA and PROD.
Branching mechanism for Hotfix or Priority1 bug:
In case, there’s a fix that’s urgently needed in Production, create a new branch from the code deployed on production landscape and fix the bug. You may test it in the same system and deploy the code to production landscape. We could either test the fix in hotfix container in PROD environment or take the same code and merge it with Q-CONS-hotfix and deploy it in QA environment for testing.
