Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2018-04-23T19:17:20.160Z
Answers: 2018-04-23T19:17:20.160Z
Answers: AnoE
Body: <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>
  
Comments: CC BY-SA 3.0
Comments: 2018-04-23T18:45:18.080Z
Comments: Could you add at least three examples that are bad according to you?
Comments: 030
Comments: CC BY-SA 4.0
Comments: 2018-05-28T06:20:35.300Z
Comments: 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
Comments: Tensibai
Tags: <configuration-management><infrastructure-as-code>
Title: Do you use existing automation code (cookbooks/playbooks/dockerfiles/etc) or you write your own from scratch?
UserDisplayName: ilya-lesikov
ThreadText: # 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...
  
  
  ---
  
  