Work with different branching strategies
When you work in a team and you want to implement branches, you need to agree on a strategy how to use branches within a project. Projects can be different, so you need to implement different strategies.
A customer customization using a PTE (per-tenant extension) requires another branching strategy than an add-on extension.
In this unit, we discuss three branching strategies you can use in your AL projects:
Feature branching
Gitflow branching
Release branching
Feature branching
Feature branching is the easiest branching strategy, and is ideal on per-tenant extensions. You develop this extension for one specific tenant. Not all your customers install this same extension. Because there's only one version of that extension installed in production, you can keep the strategy simple.
The main branch is the branch that contains the code to build the extension to install in the customer's tenant. This always contains the production live version. Developers create a new feature branch each time they start developing a feature or solve a bug. This branch is then merged into the main branch and ready to be released.
You don't need to keep the feature branches alive after merging. Typically, users start a remote feature branch based on the main branch, and then clone this branch locally. Once all changes are developed, all commits are pushed back into the remote repository, and a pull request is used to merge into the main branch. You don't want to allow developers to merge, or even commit directly on the main branch. So you need to set the correct branching policies.
Gitflow branching
The Gitflow workflow was published by Vincent Driessen in 2010. Vincent continued to build on the basic feature branching strategy by adding extra branches, and set up a complete flow between the different branches. So an extra set of commands has been released that you can use to work with Gitflow.
For example, you can start a new feature branch by using the git flow feature start command. This creates a new branch that automatically is based on a development branch. It creates the branch and executes a checkout.
git flow feature start feature-23
Later you can use the git flow feature finish command to merge your branch into the development branch. You can also create release branches. They're automatically based on the development branch. During a test on the release branch, you can find some problems and solve them directly on that release branch. After that, you can finish your release branch, and this will automatically merge your changes into the main branch and into the development branch.
So, it's basically a set of commands that perform multiple steps at once with one command. In Visual Studio Code, there are multiple extensions available that enable Gitflow within Visual Studio Code. Use the extensions option (Ctrl+Shift+X) and search for Git flow. Once installed, you can easily create new features, work on a bug fix, or start a release.
Before you can start with Gitflow, you first need to initialize your repository to work with Gitflow. You can choose to continue with the default Gitflow settings or provide your own settings.
By default, Gitflow uses a main and develop branch. All features branches are stored in a feature group, hotfixes in a hotfix group, and releases in a release group.
In the next graphic, you can see how Gitflow branches are linked. Everything starts on a main branch that contains the code that is released to the customer. The last commit on the main branch is the version that is in production.
During the initialization, a develop branch is created that is based on the main branch. All your development should happen on the develop branch. But instead of directly working on the develop branch, you can start and stop features. This action creates feature branches. Once finished, they're automatically merged into the develop branch.
Then you can start a release, which creates a branch based on the develop branch. This branch includes the latest commits that now can be tested. If a bug is found, this can be resolved on the develop branch. Once the release is finished, it automatically merges everything in the main branch to deploy into production, but also merges into the develop branch.
If a serious bug is found, then you can create a hotfix branch. This branch is based on the main branch. You can fix the bug in the hotfix branch, and finish the branch. This merges your hotfix into the main branch, but also into your development branch. This makes sure that your bug is also fixed in the develop branch.
Optionally, you can assign tags to certain commits in the main branch. That way you always have a reference to the different released versions. If you ever need to fix a bug in a specific version, you can create a branch based on a tag, and solve that bug. The best approach would be to fix the bug in the latest version, and upgrade your customer to the latest version, instead of keeping different versions alive.
Gitflow is a nice workflow to incorporate in your projects, but it has some disadvantages. The complete Gitflow process is working on your local branches. Finishing a feature would merge into the local develop branch. But many companies want to implement and work with pull requests. A pull request is handled on the remote branch. In most situations, the main branch has branch policy that requires pull requests, but the development branch often uses pull requests as well.
Gitflow allows you to locally merge into the develop branch, but you can't push this change to the remote develop branch, because you need to use a pull request to add something to the develop branch.
In that case, you still have to manually push your feature branch into the remote repository, and create a pull request to merge your feature branch into the develop branch. So, the complete Gitflow command automation isn't used anymore. The structure used in Gitflow can still be interesting to use, without the command automation. This approach can be used for add-on and per-tenant extensions.
Release branching
The release branching workflow is ideal for add-on extensions. In this workflow, you create a branch for every release, and you keep that branch alive. Whenever you need to fix a bug in a specific release, you can create a hotfix branch on that release branch. The downside is that you need to redo the same bug fix on your development branch. You can use cherry-picking, which allows you to reapply the commit(s) from a merge onto other branches. A better approach would be to create a new feature in Azure Boards, and use that feature to create a new feature branch. A bug fix on a release branch is probably a quick fix. So, it's better to create a decent solution for this fix on your development branch, so this bug is fixed in future releases.
You're still free to decide on which release you're applying a bug fix. If a customer mentions that there's a bug in version 2.0, and you have five other release branches, you actually need to redo that bug fix on all five of the release branches. You can also decide that this bug will be fixed in a new release, and that customers need to upgrade to the latest release to have this bug fixed. But, at least you have different options available.
In the next graphic, you can see that a bug fix is applied on the release 1.0 branch. The same bug is fixed in the correct way on the development branch, by creating a new feature branch that is later merged into the development branch. Main, develop, and release branches are kept alive and aren't deleted.
