Features Branching Strategy using Git and Azure DevOps
Let’s talk about features branching strategy that can be used with Git and Azure DevOps. Before we dive in, let’s assume that you’re working on a paid project that’s based heavily on client needs. In this case more than ever, you’re going to need to be able to provide a specific list of features. From there, each client can decide what feature they actually wants to buy and use. All right, now let’s get into it!
Azure DevOps | Features Branching Strategy Overview
First off, make sure to host the code inside Azure DevOps, where you have a private Git repository. Design the solution in such a way so that you have a core layer, one that it is common for all features. Given the project complexity and the way it’s designed, don’t expect to just isolate each feature in a separate location. Instead, make sure that the implementation of each feature is found across the different projects, in about 2-3 different locations.
A solid approach for this is to create a branch for your core layer. First you need to make sure that this layer is stable for each feature, then you’ll be able to create a new branch from this core layer. The most significant advantage of this approach is the ability to merge different features immediately when you need to build a specific solution for one of your clients. Through this method, you’ll be able to quickly and easily decide what features to include for a given solution.
Additional Benefits of Features Branching Strategy
Another benefit of this method is the ability to work on each feature branch without affecting other features. Fixing bugs and enhancing features are done in an isolated environment, which is dedicated to that specific feature. The complexity of this solution remains low by using a decomposition approach on top of your Git branches.
The above approach is smart in that it keeps things simple, especially at a technical level. There’s no need to mix features between each other, and you can have a clean solution at any time, including only the things that you need. However, there is a moment in time when this approach can involve extra complexity and effort from a technical perspective. This is when the core is changed.
Changing the Core in Features Branching Strategy
Any activity that changes the core, from refactoring to a small change in design, will be require the change to be pushed through each feature branch. For example, when you do refactoring, you might also need to integrate the change to each feature. This is accomplished by updating how each feature is implemented and works.
Even if you have all features in one branch, you would still need to do this fix. The nice thing about this approach is that you can still use the previous version of the core. Namely, you can combine it with the old versions of select features until the changes are integrated in all features. This is standard for other approaches too, since you can create a branch each time you have a stable version.
However, be wary, as an interesting problem appears when you need to do a refactoring, particularly at the core. Since you have multiple branches, the technical team will have a hard time estimating the difficulty of the refactoring, as well as the complexity level. For this reason, it’s absolutely necessary to take each feature branch and analyze the effort separately.
Note that this extra level of complexity and planning is most useful when there are a smaller number of features of variants that you want to separate. So, if you know from the very beginning that you’re going to end up with 20-25 features, this approach might not be the best one. So what solution is the best for you?
Features Branching Strategy Best Practices
Simply put, there is no one solution that fits all cases perfectly. However, here are some things that I would to take into account when determining the ideal solution:
- Understand the feature complexity and number of features.
- Analyze the current approach and identify if each feature can be extracted in an isolated location (i.e. a dedicated project)
- Use a dependency injection mechanism, allowing you to add at runtime features.
- Build out each feature separately, isolated from the core.
- Decide if you want to deploy all features at the client and control them from the license once features are active OR deploy only the features included in the license.
- Consider using a package repository like Nexus and clearly define what a given package contains, as well as a packaging strategy.
- Analyze the solution’s complexity throughout the full life cycle of the application. Take this into consideration when you decide your feature strategy.
Remember that there is no one-size-fits-all. Try to keep things as simple as possible for your current needs, while also choosing a solution that offers enough flexibility for the future.
Learn more about Azure with Luminos Labs
Did you find this post helpful in exploring Azure DevOps? We’re happy to provide you the answers you’re looking for in this exploratory article, as we’re highly passionate about all things cloud.
The Episerver platform also leverages the cloud, and it’s one most cloud-capable options on the market. Our teams across the world are experts at helping companies implement the platform efficiently and effectively. We also consult with the client to integrate valuable 3rd party systems – like OrderDynamics and Tealium – seamlessly into the platform.
Find out what Luminos can do for your business. We work with clients of varying sizes and industries, so we’ve got the experience to find the solutions you need. All initial consultations are free of charge. And if now just isn’t the right time, then please feel free to subscribe to our weekly newsletter for more e-commerce updates, trends, and announcements.