anchor.diff:  
   ## Build as code
   
  -The first CI server, [CruiseControl]("https://en.wikipedia.org/wiki/CruiseControl") appeared around 2000/01. Interestingly, CruiseControl fully supported build as code. CruiseControl ran a build by simply calling a specified target in a specified ant file that lived in the project’s source repository. The build was defined in code, an ant build file, and stored in the team’s source repository.
  +The first CI server, [CruiseControl](https://en.wikipedia.org/wiki/CruiseControl) appeared around 2000/01. Interestingly, CruiseControl fully supported build as code. CruiseControl ran a build by simply calling a specified target in a specified ant file that lived in the project’s source repository. The build was defined in code, an ant build file, and stored in the team’s source repository.
   
   The next generation of CI servers, mostly notably Hudson/Jenkins (pre 2.0), quickly moved away from that style of build definition. They fully owned the build configuration, often allowed editing only via a GUI, and stored it outside the team’s source code.  This caused a number of problems:
   
  
positive.code: 
  No! Absolutely not. We just don’t want it to be the starting point. It brings more complexity. More complexity brings more errors. And in the same way that complex Chef repositories need test-kitchen based unit tests to make sure that they are doing the right thing, a complex and programmed build configuration needs tests itself. Quis custodiet ipsos custodes?
  
  GoCD tries very hard to support deployment pipelines in such a way that you only need to declare definitions to define your pipelines. But there are scenarios where GoCD’s limits are hit and then something like [Gomatic]("https://github.com/SpringerSBM/gomatic"), allowing configuration of pipelines via Python scripts, is useful. As with everything in software, you need to understand the trade-offs and choose the right tools.
  
  ## Storing build and pipeline config in the main project repository
  
  
negative.code: 
  As infrastructure as code is the “as code” movement the majority of us are most familiar with, let’s take a quick look.
  
  [Martin Fowler’s bliki](https://martinfowler.com/bliki/InfrastructureAsCode.html) tells us that “Infrastructure as code is the approach to defining computing and network infrastructure through source code that can then be treated just like any software system.”  We can keep the code in version control for audit and reproducible builds. As it’s code, we can also test it. Two of the bigger benefits are less stress when rolling out changes as well as reduced mean time to recovery when disaster strikes.
  
  Infrastructure as code is enabled by countless libraries, scripts, and definition files. Configuration is typically via a declarative syntax such as YAML or JSON, a DSL, or a full-fledged programming language such as Ruby. Pick the right tool for the job.
  
  