The deployment-sized hole between Continuous Integration, Continuous Delivery and Provisioning tools

June 27, 2014

Andrew Phillips

As a developer and a build engineer, I was always dissatisfied with the amount of glue I had to apply to stick popular CI or CD tools, whether JenkinsBamboo or Go to popular provisioning tools (Puppet,Chef or the like), which we also used for the application tier.

There was simply a fundamental impedance mismatch between the two types of tools:

  1. We needed an application-oriented model for our services, which consisted of multiple components ("traditional" or micro-service style) spread across various machines. The provisioning tools' domain models all felt too machine-centric.

  1. We were looking for clean and easy integrations with our build, packaging and CI/CD tool of choice. Since often times none existed, we ended up with a bunch of custom tasks and script steps.

  1. Our pipelines were -- and still are -- based on "directive automation."That is, we invoked whatever tool(s) were needed for a step, kept track of the process and the status and continued (or not) once it had completed. This did not match the "eventually consistent" style of the server mode of tools like Puppet or Chef at all too well.

That mode was great from an operational perspective ("Make sure all my x-thousand machines have the right configuration - I don't need to watch it happen, just get it done!"), but not really compatible with our delivery pipeline. We sometimes....

© HAKIN9 MEDIA SP. Z O.O. SP. K. 2023
What certifications or qualifications do you hold?
Max. file size: 150 MB.

What level of experience should the ideal candidate have?
What certifications or qualifications are preferred?

Download Free eBook

Step 1 of 4


We’re committed to your privacy. Hakin9 uses the information you provide to us to contact you about our relevant content, products, and services. You may unsubscribe from these communications at any time. For more information, check out our Privacy Policy.