Continuous Integration as a practice is ensuring that each time code is committed, it is built and tested the same way consistently. We use Continuous Integration systems to automate this practice, making it practical for use on every commit. Some Continuous Integration pipelines eventually evolve into Continuous Delivery or Continuous Deployment pipelines. The key difference between Continuous Integration and delivery is that delivery ensures that every time code is committed, it is also wrapped up (or packaged) and delivered to the doorstep of the server it needs to run on. Continuous Delivery requires the ability to deploy your entire infrastructure and application consistently with a single orchestration command. Continuous Deployment requires an end-to-end suite of tests for every component in your infrastructure, but is the simple task of automating that single orchestration command when every test passes.

How these systems become useful to the individual application and infrastructure is unique to every company and organization, much like any other business rule. There are some common use cases and business rules that are nearly universal in everyone's Continuous Integration pipelines, and some that teams strive for. 

In this chapter, we will do the following:

• Set up a Continuous Integration system (Jenkins) using Puppet
• Create a job for a profile module
• Set up our first test
• Integrate the Puppet Development Kit (PDK) test suite
• Write RSPec unit tests
• Set up Puppet integration tests with Test Kitchen