Answers: <p>Mostly because getting from an unknown state to a desired state is not a build step, at build you start from a known state, which is nil or blank, and create something.</p>
  
  <p>But what you're missing, I think, is that with configuration as code you build the desired state once and deploy the resulting artifact multiple times.</p>
  
  <p>For a Chef Cookbook as example, you would:</p>
  
  <ul>
  <li>code it </li>
  <li>unit test it with ChefSpec</li>
  <li>functionally test it with Kitchen </li>
  <li>and finally release it as an artifact to chef-server if all tests pass</li>
  <li>promote it environment by environment</li>
  </ul>
  
  <p>With that in mind, all tools built on the promise theory (ansible, chef, puppet, salt,...) do fulfill this pattern of build once and deploy multiple times.</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-06-25T07:42:10.690Z
Answers: 2019-06-25T07:42:10.690Z
Answers: Tensibai
Body: <p>I've heard about deployment pattern which sounds like "build one time, deploy multiple times".</p>
  
  <p>If I manage the configuration via e.g. ansible templates or chef or any other CM tools, I don't have any pre-generated configuration. I have it generated on every deployment.</p>
  
  <p>Why no tool follows this (logical) pattern for configuration?
  Does it worth at all?</p>
  
Comments: CC BY-SA 4.0
Comments: 2019-06-25T05:14:56.940Z
Comments: Hi there! Your statement "Why no tool follows this (logical) pattern for configuration?" is quite a strong opinion. Could you please back this up with some evidence to support your point of view?
Comments: Bruce Becker
Tags: <configuration-management><configuration>
Title: Build one time, deploy multiple times. How does this apply to configuration?
UserDisplayName: rush
ThreadText: # Build one time, deploy multiple times. How does this apply to configuration?
  
  (Asked by: username_0 on 2019-06-24)
  
  I've heard about deployment pattern which sounds like "build one time, deploy multiple times".
  
  If I manage the configuration via e.g. ansible templates or chef or any other CM tools, I don't have any pre-generated configuration. I have it generated on every deployment.
  
  Why no tool follows this (logical) pattern for configuration?
  Does it worth at all?
  
  **Tags:** configuration-management, configuration
  
  > **Comments:**
  > **username_1**: Hi there! Your statement "Why no tool follows this (logical) pattern for configuration?" is quite a strong opinion. Could you please back this up with some evidence to support your point of view?  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2019-06-25. Score: 1 | Accepted answer
  
  Mostly because getting from an unknown state to a desired state is not a build step, at build you start from a known state, which is nil or blank, and create something.
  
  But what you're missing, I think, is that with configuration as code you build the desired state once and deploy the resulting artifact multiple times.
  
  For a Chef Cookbook as example, you would:
  
  * code it
  * unit test it with ChefSpec
  * functionally test it with Kitchen
  * and finally release it as an artifact to chef-server if all tests pass
  * promote it environment by environment
  
  With that in mind, all tools built on the promise theory (ansible, chef, puppet, salt,...) do fulfill this pattern of build once and deploy multiple times.
  
  
  ---
  
  