An Inside Look at Chef's New Automated Delivery Tool
DZone takes a look at Chef's new continuous delivery tool for deploying application and infrastructure changes.
Join the DZone community and get the full member experience.Join For Free
The DevOps Zone is brought to you in partnership with Sonatype Nexus. The Nexus Suite helps scale your DevOps delivery with continuous component intelligence integrated into development tools, including Eclipse, IntelliJ, Jenkins, Bamboo, SonarQube and more. Schedule a demo today.
Last week I spoke with Seth Falcon, Engineering General Manager for Chef’s new Delivery product, which is their play in the continuous delivery space. Seth was kind enough to explain the product and show me a quick demo of the product, which is a new way to look at the old continuous delivery process that also aims to automate infrastructure changes by leveraging Chef and Chef cookbooks.
There were two major goals when creating Chef Delivery: delivering software quickly, reliably, and safely; and finding a workflow that was proven to work. Chef Delivery was born out the company’s experience working with their customers and figuring out that workflow, building the tool around it, and reinforcing behaviors that make the team effective at continuous delivery. They call this workflow a “shared workflow,” described in the below diagram:
As you can see, each change to Chef cookbooks, applications, or infrastructure has the same basic steps, individual of the shared pipeline. Once the changes are accepted, you have the ability to ship the code, which moves it to the shared pipeline.
As individual changes are pushed, they go to a shared staging environment, called “Union.” From there, the changes move through the “Rehearsal,” or pre-production environment before ultimately being deployed to the “Delivered” production environment. As the code moves from each stage, it is subjected to a barrage of automated quality and compliance testing. Everything committed to the Union, Rehearsal, or Delivered stages is applied to any code changes that are currently underway earlier in the process.
Part of Chef’s hope with their unique names of the different environments is to reinforce the culture necessary for both DevOps and their specific workflow model to thrive. As part of their commitment to the shared workflow, the main steps above cannot actually be changed, as the common shape between all projects means that pipelines are far easier to debug because you know exactly where to look. However, the phases in each stage can be changed to match your company’s natural processes and habits.
After the presentation and introduction, I got to see a really cool demo where Chef uses Delivery to deploy Delivery (a.k.a. Continuous Inception). I saw how changes are committed; all the testing and security tests that move the change into production are automated. It was pretty cool to see all of this in real time.
The product is still young, and Chef are working on integrations with Slack, Hipchat, and Email to supplement GitHub notifications. While the product may seem rigid at first glance, Chef has released a very cool tool that I think will help organizations make the move to continuous delivery for apps and infrastructure with their unique pipeline, and whose rigidity will keep teams on track.
Opinions expressed by DZone contributors are their own.