We have reviewed the tools than can accompany our code from creation to production.
Whatever happens after we commit and eventually approve our code can be automated.
It is basically a matter of executing commands on local or remote systems that use tools like the ones we have seen in this chapter for the various stages of a deployment workflow.
Once we have these single bricks that fulfill a specific function, we can automate the whole workflow with a Continuous Integration (CI) tool that can run each step in an unattended way and proceed to the following if there are no errors.
There are various CI tools and services available; we will concentrate on a pair of them, particularly popular in the Puppet community:
- Travis: An online CI as a service tool
- Jenkins: The well known and widely used Hudson fork
Travis (https://travis-ci.org) is an online Continuous Integration service that perfectly integrates with GitHub.
It can be used to run tests of any kind, in Puppet world, it is generally used to validate the module's code with rspec-puppet. Refer to online documentation on how to enable the Travis hooks on GitHub (http://docs.travis-ci.com/user/getting-started/); on our repo we manage what to test it with a .travis.yml file:
language: ruby
rvm:
- 1.8.7
- 1.9.3
script:
- "rake spec SPEC_OPTS='--format documentation'"
env:
- PUPPET_VERSION="~> 2.6.0"
- PUPPET_VERSION="~> 2.7.0"
- PUPPET_VERSION="~> 3.1.0"
matrix:
exclude:
- rvm: 1.9.3
env: PUPPET_VERSION="~> 2.6.0"
gemfile: .gemfile.travis
gemfile: .gemfile.travis
notifications:
email:
- HYPERLINK "mailto:[email protected]"[email protected]As we can see from the preceding lines, it is possible to test our code on different Ruby versions (managed via Ruby Version Manager (RVM) https://rvm.io) and different Puppet versions.
It's also possible to exclude some entries from the full matrix of the various combinations (for example, the preceding example executes the rake spec command to run puppet-rspec tests in five different environments: 2 Ruby versions * 3 Puppet versions - 1 matrix exclusion).
If we publish our shared Puppet modules on GitHub, Travis is particularly useful to automatically test the contributions we receive, as it is directly integrated on GitHub's pull requests workflow, which is commonly used to submit author fixes or enhancements on the code to a repository (check out https://help.github.com/categories/63/articles for details).
Jenkins is by far the most popular open source Continuous Integration tool. We are not going to describe how to install and use it and will just point out useful plugins for our purposes.
A Puppet-related code workflow can follow common patterns; when a change is committed and accepted, Jenkins can trigger the execution of tests of different kinds and, if they pass, can automatically (or after human confirmation) manage the deployment of the Puppet code on production (typically, by updating the directories on the Puppet Master that are used by the production environment).
Among the multitude of Jenkins plugins (https://wiki.jenkins-ci.org/display/JENKINS/Plugins) the ones that are most useful for our purposes are:
- ssh: This allows execution of a command on a remote server. This can be used to manage deployments with librarian-puppet or r10k or execute specific tests.
- RVM / rbenv: This integrates with RVM or Rbenv to manage execution of tests in a controlled Ruby environment. They can be used for rspec-puppet and puppet-lint checks.
- GitHub / Gerrit: This integrates with GitHub and Gerrit to manage code workflow.
- Vagrant: This integrates with Vagrant for tests based on real running machines.
Testing can be done locally on the Jenkins server (using the rvm/rbenv plugins) or on any remote host (via the SSH plugin or similar tool); deployment of the code can be done in different ways, which will probably result in the execution of a remote command on the Puppet Master.