What exactly is continuous delivery? Continuous Delivery is a software engineering approach that allows for quick updates to be propagated through the development lifecycle in short increments. Rather than having a large release that takes several months to complete the development lifecycle, continuous delivery makes use of small changes that are release in short intervals.
Continuous delivery consists of several phases: build, deploy, test, and release. In the build phase you write the code for your project. Upon completion of the build phase your code changes are deployed to an environment. This environment typically starts with your testing environment. Environments are discussed in more detail below. After your code changes are deployed to an environment some form of testing is performed to ensure that the code won’t break your environment. While it is hard to test this to 100% certainty, we can test to our best effort.
Typically, in any mature IT infrastructure there will exist several environments. The reason is simple in that we don’t want to deploy untested changes to production. Therefore, several environments are created to allow for testing in a minimal risk setting and an environment that is used to mimic production as closely as possible. The environment levels can and usually are split into several environments. For example, the lower level testing environment can be split into one unit testing environment and one acceptance testing environment.
Why do I care for puppet development?
Continuous delivery offers the puppet engineer a nice method to update their puppet environments in a quick, tested and repeatable manner. Updates to puppet modules can be propagated to specific environments and through automation promoted to higher lifecycles eventually ending in your production environment.
Configuration management not only happens in your company’s production environment but will more than likely be required in the lower lifecycle environments. It is worth noting here that there is a difference in puppet environments and your IT infrastructure environments. Don’t confuse the two when designing your puppet infrastructure. Puppet dynamic environments should not mimic your infrastructure environments and in all actuality it might be more helpful to use a different term to describe the puppet environments. There are a few blog posts out there that discuss this topic and they make recommendations like calling the puppet environments tiers or lifecycles. However, you name your puppet environments, just make sure that you disambiguate them from your infrastructure environments.
Continuous Selivery = Competitive Advantage
Everyone wants to ship new features and updates to customers more frequently, and more reliably. Continuous delivery not only lets you get code shipped more quickly — it also reduces costs and risk, because you’re shipping smaller batches.
To do it right, you need automation. Puppet Enterprise is the ideal IT automation solution for continuous delivery because it treats infrastructure as code, enabling continuous delivery practices and making it easy for dev, ops, QA and other teams to collaborate.
Continuous Delivery with Puppet
Jez Miller, the infrastructure architect at Heartland Payment Systems, talks about how Puppet Enterprise’s treatment of infrastructure as code turned deployment duration from about 10 hours to 10 minutes.
Cut Deployment Times — And Errors
No more costly, avoidable human errors. Puppet Enterprise lets you manage your infrastructure as code, enabling you to use the same tools software developers use. You can code, test, integrate, review and repeat infrastructure configurations just like any other code, giving you faster and more dependable deployments.
Increase the quality of releases
Know that changes can be shipped to your customers with a push of a button. Puppet Enterprise provides Beaker, an acceptance testing framework for infrastructure deployments, giving you confidence that deployments will go as expected every time.
Achieve rolling updates
Want to update your software quickly and easily, so customers won’t notice? Rolling out smaller, less complex changes will help you do that. Puppet Enterprise extends the proven benefits of continuous integration, deploying resulting CI artifacts to a production-like environment. Changes are deployable at any time, based on business need, not IT limitations.
Puppet Development Pipeline
Our ultimate goal is to configure a system that allows a puppet developer to make changes to code and those changes tested and deployed to our environments. To do this we need to develop a pipeline that will show what steps need to happen in order for this to work. The diagram below is the pipeline we will be using in this tutorial.
In essence, the puppet developer makes some changes to the puppet code on their local development system. Once the changes are complete the developer then commits their changes to the central git repository where a web hook will get called that will do our puppet unit testing. Once the unit testing passes we will then run automated acceptance testing using Beaker which will spin up a Docker container and install the module with our updates to insure that the module will compile and run using puppet. Once the automated acceptance testing passes we then automatically deploy the module to a nonproduction environment where our users will perform acceptance testing. After user acceptance testing passes the module is deployed and used in our production environment.
Get Updates on Tech posts, Interview & Certification questions and training schedules