anchor.diff:    feature_c:
       state: ready_for_release
       description: This turns on feature c
  -    ```
  +~~~~
  +
   
   **Some things you should consider when implementing feature toggles:**
   
  
positive.code: 
  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. 
  
  TRUNK BASED DEV IMAGE HERE
  
  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. 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 is an important technique for TBD. 
  
  
  ##Feature Toggles
  
negative.code:   </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
  
  