<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>

CC BY-SA 4.0
2019-06-25T07:42:10.690Z
2019-06-25T07:42:10.690Z
Tensibai
<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>

CC BY-SA 4.0
2019-06-25T05:14:56.940Z
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?
Bruce Becker
<configuration-management><configuration>
Build one time, deploy multiple times. How does this apply to configuration?
rush
# 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.


---

