In an age of agile software delivery, product companies are looking at accelerating their time to value. One way to go about it is to embrace feature-driven development (FDD). It is a lightweight agile software development process that is driven from a client-valued functionality perspective. To coordinate software development, engineering teams have adopted distributed version control systems like GitHub and BitBucket. They provide for Continuous Delivery and short-lived branching.

Feature branching allows developers to work in isolated collaboration; each developer functions independently without stepping on another’s code. This is owing to the two underlying aspects involving branching (isolation) and merging (collaboration). A chief shortcoming of feature branching is that feature release management is still linked to code deployments and forces engineers to remain within the confines of their version control system.

A key advantage of feature branching is the ability to stay isolated from the changes happening elsewhere and pulling in variances from the mainline at their convenience so that they don’t break the flow of their feature. In a traditional approach, release cycles are planned by the highest-priority feature. In feature branching, the team can decide when and what features they want to release. Cherry-picking can also be done so as to pick and choose what features they want to release to the market.

feature branching and release management

Feature branching with feature flags, also called feature flag driven development, enables Continuous Delivery whereby developers take full control of their feature lifecycles independent of code deployments. Merging the releases to incorporate changes from all the isolated changes can be challenging depending on the complexity and conflicts involved. Semantic conflicts can arise but GIT has the reputation to handle complicated merges. Merging a feature branch wrapped in a feature flag can help in deploying the feature for future roll-outs or even killing off the feature if it is not working well thus preventing redeployment.  Some of the benefits derived are:

  • Better collaboration among developers with coordinated efforts
  • Pragmatic deployments without long-lived branching; deploying yet flagging ‘off’ features that are not ready
  • Exposing dependencies easily with short-lived branching thus removing unnecessary features
  • Risk mitigation across different environments like local, QA, staging and production with flagging

Feature development makes it possible to leverage pull requests from developers that sign off on a request. This should eventually make way for a smoother release through Continuous Integration. Continuous Integration helps in reducing the complexities of big merges by committing to the mainline every day. This obviates the challenges of miscommunication that developers face on an ongoing basis.

“I see CI as primarily giving birth to a release candidate at each commit. The job of the CI system and deployment process is to disprove the production-readiness of a release candidate. This model relies on the need to have some mainline that represents the current shared, most up to date picture of complete.” — Dave Farley

Best Practices of Branching and Merging for Continuous Release Management

  • Branching and merging strategies should be clearly defined for continuous release management
  • Dependencies should be mapped and defined at an early stage so that individual features can be defined
  • The main branch should be kept stable with the latest code in production
  • Redundant branches that were a part of previous releases, without any bearing to the current release cycle, should be deleted
  • Continuous integration should be done to regularly commit to the mainline without delays
  • Reverse merge should be planned and executed at regular intervals

It is the job of the deployment process to disprove the production-readiness of a release feature but prove that small joys of isolated collaboration can result in the bigger joys of Continuous Delivery.

References:

  1. https://www.atlassian.com/git/tutorials/comparing-workflows
  2. https://www.linkedin.com/pulse/branching-merging-strategy-managing-releases-vijay-hajare
  3. https://martinfowler.com/bliki/FeatureBranch.html
  4. https://dzone.com/articles/feature-branching-using-feature-flags-1

Vishwas Anand

Head of Content & Thought Leadership at Aspire Systems
Vishwas is a Content Custodian, Digital Evangelist and Thought Leader involved in emerging digital technologies and trends in the IT space. Vishwas has been rated one of India's Top 100 Content & Brand Custodians by Adobe Content 100 powered by Paul Writer (August 2017) representing his team of research analysts. He is a speaker for webinars hosted on BrightTALK and has actively participated in IT summits like the Gartner Summit (2015) and the Futurist Business Conclave (2017). He's written whitepapers and articles for leading publications like Tech Republic, Tech in Asia, The Indian Retailer among others. Vishwas holds an MBA from IIM- Kozhikode.