anchor.diff:  
   ##Summary
   
  -This is the part 5 of our CD for Microservices blog series. We have talked about configuration strategy for your CD pipeline. In the next post, we will talk about the last consideration: remediation strategies for when something goes wrong. 
  +This is the part 5 of our [CD for Microservices blog series](https://www.gocd.org/tags/cd-for-microservices.html). We have talked about configuration strategy for your CD pipeline. In the next post, we will talk about the last consideration: remediation strategies for when something goes wrong. 
   
   
  
positive.code: title: Configuration Strategy for Continuous Delivery of Microservices
  type: post
  author: Sheroy Marker
  excerpt: "In this post, we'll look at environment strategy including artifact promotion and leveraging modern infrastructure for dynamic environments."
  summary_image: "/assets/images/blog/cd-considerations/configuration-strategy.jpg"
  title_tag_of_header: "Continuous Delivery of Microservices - Configuration Strategy | GoCD Blog"
  meta_description: "You can start with thinking about what environments need to be created upfront and talking about the intended use cases for these environments. Different groups in your organization will have different competing needs. Your environment plan should accommodate the needs from different parties."
  meta_keywords: "Microservices, continuous delivery, microservice environment, environment strategy, artifacts, provision environment"
  tags: CD for Microservices
  draft: true
  ---
  <% content_for :banner do %>
    <figure>
      <img src="/assets/images/blog/cd-considerations/configuration-strategy.jpg" alt="Continuous Delivery of Microservices"/>
    </figure>
  <% end %>
  
  
  This is the fifth post in the series - Continuous Delivery of Microservices. In the previous post, we talked about environment strategy -  including artifact promotion and ways to leverage modern infrastructure for dynamic environments. In this post, we will discuss configuration strategy. 
  
  ##Introduction
  
  An application’s configuration is everything that is variable across deployment environments such as development, test, and production. If you can deploy the same code but switch out certain aspects (like URLs to backing services, database connection information, credentials to third-party services, etc.) these are what I mean by variables. Such configuration should be stored separately from the application code. 
  
  In a system based on a microservices architecture, configuration also needs to be distributed across multiple services. There are a couple of ways to manage configurations in a distributed way: 
  *make configuration available in environment variables at deploy time, 
  
negative.code: 
  This central store gives you traceability on how and when policies were changed. That traceability goes a long way in setting up a governance process.
  
  A tool we recommend to store secrets is the [Vault](https://www.vaultproject.io/) by Hashicorp. 
  
  **Example:**
  
  