<commit_before>---
layout: post
title: Continuous Delivery of Microservices - Trunk Based Development and Feature Toggles
type: post
author: <NAME>
excerpt: "In the first of this blog series, we will share the considerations to keep in mind in architecture design and application development."
summary_image: "/assets/images/blog/cd-considerations/5-consideration-microservices-gocd.jpg"
title_tag_of_header: "Five Considerations for Continuous Delivery of Microservices | GoCD Blog"
meta_description: "GoCD is excited to announce the release of our Kubernetes Helm Chart that will allow our users to run GoCD natively on Kubernetes."
meta_keywords: "microservices, continuous delivery, microservices architecture, continuous integration, hotfixes, test pyramid"
tags: CD for Microservices
draft: true
---
<% content_for :banner do %>
  <figure>
    <img src="/assets/images/blog/cd-considerations/5-consideration-microservices-gocd.jpg" alt="Continuous Delivery of Microservices"/>
  </figure>
<% end %>

This is the third post in the series - [CD of Microservices](https://www.gocd.org/tags/cd-for-microservices.html). In the [previous post](https://www.gocd.org/2018/05/08/continuous-delivery-microservices-test-strategy/), we talked about testing strategy for building CD pipelines on microservices architecture. In this post, we’ll get deep into CI practices.

##Continuous integration

Continuous integration is a key practice in a successful continuous delivery strategy. Simply defined, it’s a practice that requires developers to integrate their code into a shared repository several times a day. Every checkin is verified by an automated build, allowing teams to detect problems early. 

We’ll focus on two key practices, trunk based development and feature toggles. These two go a long way in implementing a simple and robust CI process. 


##Trunk Based Development

In trunk based development (TBD), developers collaborate on code in a single branch called “trunk”. The key benefit is to avoid drift in development branches and the resulting merge hell. 

<img src="/assets/images/blog/cd-considerations/trunk-based-development.png" alt="Trunk Based Development - TBD"/>

This is contrary to the practice of maintaining long-lived feature and release branches. In a branching model, though you may be running builds on individual branches, arguably [you aren’t doing continuous integration](https://www.gocd.org/2017/05/16/its-not-CI-its-CI-theatre/). In trunk based development, you should never find your trunk in a state where your CD process is unable to deploy. All code should be checked into trunk, built and tested constantly, and the codebase deployable on demand: all of this make CD a reality.

TBD results in much simpler CD workflows: you don’t have to build multiple branches in parallel, map branches to environments and re-test when the same features get merged to trunk. Simplifying workflows is very important in the context of microservices, as the complexity is exasperated as the number of microservices grows. 

[Feature toggles](https://martinfowler.com/articles/feature-toggles.html) is an important technique for TBD. 


##Feature Toggles

Feature toggles enable commits of a combination of work-in-progress and completed features. With these toggles, you can turn off the manifestation of incomplete features in production, until the features are dev complete and tested sufficiently in pre-production environments. 

Here is a very simple example. The team are working on four features for the same application: search, menu, sign-in and in-app chat. The in-app chat feature is incomplete (but you still check into trunk in TBD) or you find issues with the in-app chat in pre-production testing. With feature toggles, you can simply turn in-app chat off, even at run time. 

<img src="/assets/images/blog/cd-considerations/feature-toggles.png" alt="Feature Toggles"/>

Feature toggles are usually stored in a specification or configuration file close to the codebase and used by automation in the CD pipeline to turn toggles on in specific environments. They are just conditions in your code base.You should separate setting these toggles from the actual release process so that you can control it in run time. 

~~~~
feature_a:
    state: in_dev
    description: This turns on feature a
  feature_b:
    state: ready_for_acceptance<commit_msg>added sample toggle headline<commit_after>---
layout: post
title: Continuous Delivery of Microservices - Trunk Based Development and Feature Toggles
type: post
author: <NAME>
excerpt: "In the first of this blog series, we will share the considerations to keep in mind in architecture design and application development."
summary_image: "/assets/images/blog/cd-considerations/5-consideration-microservices-gocd.jpg"
title_tag_of_header: "Five Considerations for Continuous Delivery of Microservices | GoCD Blog"
meta_description: "GoCD is excited to announce the release of our Kubernetes Helm Chart that will allow our users to run GoCD natively on Kubernetes."
meta_keywords: "microservices, continuous delivery, microservices architecture, continuous integration, hotfixes, test pyramid"
tags: CD for Microservices
draft: true
---
<% content_for :banner do %>
  <figure>
    <img src="/assets/images/blog/cd-considerations/5-consideration-microservices-gocd.jpg" alt="Continuous Delivery of Microservices"/>
  </figure>
<% end %>

This is the third post in the series - [CD of Microservices](https://www.gocd.org/tags/cd-for-microservices.html). In the [previous post](https://www.gocd.org/2018/05/08/continuous-delivery-microservices-test-strategy/), we talked about testing strategy for building CD pipelines on microservices architecture. In this post, we’ll get deep into CI practices.

##Continuous integration

Continuous integration is a key practice in a successful continuous delivery strategy. Simply defined, it’s a practice that requires developers to integrate their code into a shared repository several times a day. Every checkin is verified by an automated build, allowing teams to detect problems early. 

We’ll focus on two key practices, trunk based development and feature toggles. These two go a long way in implementing a simple and robust CI process. 


##Trunk Based Development

In trunk based development (TBD), developers collaborate on code in a single branch called “trunk”. The key benefit is to avoid drift in development branches and the resulting merge hell. 

<img src="/assets/images/blog/cd-considerations/trunk-based-development.png" alt="Trunk Based Development - TBD"/>

This is contrary to the practice of maintaining long-lived feature and release branches. In a branching model, though you may be running builds on individual branches, arguably [you aren’t doing continuous integration](https://www.gocd.org/2017/05/16/its-not-CI-its-CI-theatre/). In trunk based development, you should never find your trunk in a state where your CD process is unable to deploy. All code should be checked into trunk, built and tested constantly, and the codebase deployable on demand: all of this make CD a reality.

TBD results in much simpler CD workflows: you don’t have to build multiple branches in parallel, map branches to environments and re-test when the same features get merged to trunk. Simplifying workflows is very important in the context of microservices, as the complexity is exasperated as the number of microservices grows. 

[Feature toggles](https://martinfowler.com/articles/feature-toggles.html) is an important technique for TBD. 


##Feature Toggles

Feature toggles enable commits of a combination of work-in-progress and completed features. With these toggles, you can turn off the manifestation of incomplete features in production, until the features are dev complete and tested sufficiently in pre-production environments. 

Here is a very simple example. The team are working on four features for the same application: search, menu, sign-in and in-app chat. The in-app chat feature is incomplete (but you still check into trunk in TBD) or you find issues with the in-app chat in pre-production testing. With feature toggles, you can simply turn in-app chat off, even at run time. 

<img src="/assets/images/blog/cd-considerations/feature-toggles.png" alt="Feature Toggles"/>

Feature toggles are usually stored in a specification or configuration file close to the codebase and used by automation in the CD pipeline to turn toggles on in specific environments. They are just conditions in your code base.You should separate setting these toggles from the actual release process so that you can control it in run time. 

***Sample toggle specification:***
~~~~
feature_a:
    state: in_dev
    description: This turns on feature a
  feature_b:
    state: ready_for_acceptance
{'fraction_non_alphanumeric': 0.062032206849625765, 'fraction_numerical': 0.0040825584032660464, 'mean_word_length': 4.813447593935399, 'pattern_counts': {'":': 0, '<': 19, '<?xml version=': 0, '>': 19, 'https://': 8, 'lorem ipsum': 0, 'www.': 6, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 6, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2775436', 'n_tokens_mistral': 2267, 'n_tokens_neox': 2144, 'n_words': 1137}