<p>My limited experience is indeed that often, you can get a first solution very quickly with pre-made automation code; unfortunately, often there either appear unexpected problems during "first contact", or later during use, especially when you wish to expand the configuration for unusual cases.</p>

<p>So, indeed, I do tend to approach this with an open mind. I will certainly start out with something pre-made, but sometimes my gut feeling tells me to take a look under the hood, and then I'll decide rather spontaneously if I better do it myself, or whether it is a good idea to roll with it...</p>

CC BY-SA 3.0
2018-04-23T19:17:20.160Z
2018-04-23T19:17:20.160Z
AnoE
<p>I noticed that many cookbooks/playbooks/... are not of particularly high quality, and even if they are they rarely cover all cases. So it should be expanded with my custom logic everytime, while 90% of the *book remains unused (+ adds complexity/reduces ease of modification/lacks unification between *books/...).</p>

<p>In particular, configuration management most of the time is "high-level enough"  to not write too many boilerplate even if you implement something from scratch. The only exception might be additional "pure modules" for specific use cases if DSL does not provide enough functionality.</p>

<p>I understand this is pretty subjective, but I'm truly surprised I can't find anything related to this (pretty basic) topic. What is your experience, can we say there is a best practice for when to implement your solution from "scratch" or use the existing infrastructure/deployment automation code?</p>

CC BY-SA 3.0
2018-04-23T18:45:18.080Z
Could you add at least three examples that are bad according to you?
030
CC BY-SA 4.0
2018-05-28T06:20:35.300Z
That's super broad and asking about very different things, for chef cookbook there's official guidance and labels for well maintained cookbooks and quality metrics, but I can't extend that to playbooks by lack of knowledge about them nor to dockefiles as they are very different beasts
Tensibai
<configuration-management><infrastructure-as-code>
Do you use existing automation code (cookbooks/playbooks/dockerfiles/etc) or you write your own from scratch?
ilya-lesikov
# Do you use existing automation code (cookbooks/playbooks/dockerfiles/etc) or you write your own from scratch?

(Asked by: username_0 on 2018-04-23)

I noticed that many cookbooks/playbooks/... are not of particularly high quality, and even if they are they rarely cover all cases. So it should be expanded with my custom logic everytime, while 90% of the \*book remains unused (+ adds complexity/reduces ease of modification/lacks unification between \*books/...).

In particular, configuration management most of the time is "high-level enough" to not write too many boilerplate even if you implement something from scratch. The only exception might be additional "pure modules" for specific use cases if DSL does not provide enough functionality.

I understand this is pretty subjective, but I'm truly surprised I can't find anything related to this (pretty basic) topic. What is your experience, can we say there is a best practice for when to implement your solution from "scratch" or use the existing infrastructure/deployment automation code?

**Tags:** configuration-management, infrastructure-as-code

> **Comments:**
> **username_1**: Could you add at least three examples that are bad according to you?  
> **username_2**: That's super broad and asking about very different things, for chef cookbook there's official guidance and labels for well maintained cookbooks and quality metrics, but I can't extend that to playbooks by lack of knowledge about them nor to dockefiles as they are very different beasts  

---

## 1 answers

### Answer by username_3 on 2018-04-23. Score: 2

My limited experience is indeed that often, you can get a first solution very quickly with pre-made automation code; unfortunately, often there either appear unexpected problems during "first contact", or later during use, especially when you wish to expand the configuration for unusual cases.

So, indeed, I do tend to approach this with an open mind. I will certainly start out with something pre-made, but sometimes my gut feeling tells me to take a look under the hood, and then I'll decide rather spontaneously if I better do it myself, or whether it is a good idea to roll with it...


---

