Git workflow using Puppet & Hiera

3
votes

We're a 2 man team using puppet/Hiera to manage 20 servers. Up until now we have not used any VCS whilst developing the manifests.

I've configured a remote Git repo on the puppetmaster and pushed our manifests and module folders to the master branch (used for development) and pushed an identical production branch. The remote repo has a post-release hook which configures a new environment based on the branch name (or updates if exists) and the puppetmaster has dynamic environments configured to enable this to work. This configuration is discussed in detail on the puppet blog.

Our workflow is for each of us to develop on our local master branch and when we are ready to test, we commit, then push, and the post-release hook updates the development environment. We can then test (we don't feel that we need a separate staging environment) the changes on test clients by using puppetd --test --environment development. If everything works as expected then either of us can merge the development branch into production and push which again updates the production environment.

Questions

  1. Is this an optimal workflow for using Git and Puppet?
  2. How do we actually test the development environment. We have spare servers which we can use but do we configure them with the same hostnames as the production servers specified in the node declarations? If we do this then some node specific data from Hiera such as IP addresses will be wrong. Or do we test on the production servers with the --environment development switch and use --noop?

Any advice would be greatly appreciated.

2
gitpuppet

2 Answers

1
votes

One thing you may want to do is use a staging VM. Before pushing the changes you test them on your VMs if everything works fine then push the changes.

Use of a VCS for puppet is kind of different than that with code. Sometimes your pushes "may break the build", so to speak. So use Git tags to describe commits where everything worked fine, which will help you make sure you don't revert to one of the 'bad' commits.

1
votes

I will assume you have a jenkins server configure to poll your git repository

My ideal workflow looks like this :

  • locally
    • create feature branch feature/add-nfs-mount
    • add modifications to modules/hiera/puppet labs
    • add rspec test associated to modification (ideally use your production hiera data and verify the the config/files actually contains the expected value)
    • run rspec-puppet
    • test via vagrant provisioning
    • push the feature branch
  • jenkins
    • the ci detect the push, launch my test, lint,...
    • ask your coworker to review your changes via a pull request
  • once merged the ci start a build pipeline
    • launch again the test
    • the promote to staging (merge feature branch in develop)
    • let puppet provision staging
    • check manually/automatically the desired state of your staging platform
    • we have a manual step to promote to production (merge develop in master)

hope this help

Stéphan