Fattening the workflow, part 3: GitLab and similar

In the previous posts of this series I discussed the control repository and r10k. The last component in fattening the workflow is Git provider such as GitLab, GitHub or Bitbucket. Nowadays all of them are reasonable choices for storing private Git modules, which Puppet control repositories and site-specific modules tend to be. One of the biggest advantages of GitLab over its competition is that it is open source and can be installed locally.

The preparations are essentially the same for GitLab and the other Git providers:

  • Create user accounts in GitLab

  • Each user creates an SSH key and connects it to their GitLab user

  • Create organisation to GitLab

  • Join GitLab users to the organisation

  • Allow GitLab users push to Git repos of the organisation

  • Create a so called deployment key (SSH key)

  • Create control repo project in GitLab (usually called “control-repo”)

  • Rename default branch in control repo to “production” (see documentation)

  • Assign “read only” rights to control repo in GitLab for the deployment key

  • Each user clones the control repo to their own computer with Git

In the previous article I described how to configure r10k to use the correct deployment (SSH) key with GitLab. Once you’ve done all the preparations, you can move on the actual workflow which is as follows:

First update the production branch of your local control repo clone:

$ git branch 
* production 
$ git pull

Create a new branch (so called “feature branch”) in your control repo clone:

$ git branch feature_a 
$ git checkout feature_a

Then make necessary edits and commit changes:

$ git add file 
$ git commit -m "Add feature a"

Push the changes in GitLab:

$ git push origin feature_a

You’ll changes are now in the GitLab repository branch feature_a.

Then, create a merge request in the GitLab UI. Usually GitLab chooses the right source branch automatically but if not you can also select it manually. The target of the merge request is usually the production branch but you can also use a separate testing or staging branch before moving to the production branch.

I suggest that another user reviews the changes involved in the merge request to verify their quality. At this stage it is strongly recommended to test the feature branch. First deploy the branch withr10k on Puppet master to create Puppet environment feature_a:

$ r10k deploy environment feature_a -vp

Now you can test the new feature with real machines connected to the Puppet master like this:

$ puppet agent -tv --environment feature_a --noop

The --noop switch ensures that Puppet will not make any changes, only show what would change. If the –noop run looks reasonable you can remove –noop and apply the changes. Depending on what changed the next Puppet run launched by the Puppet agent service may or may not overwrite those changes. But you generally have enough time to verify the correctness of the changes before that happens.

If the changes look good and work as expected, the reviewer can merge them to the control repo so they’ll end up in the production branch as well.

The next and the last step is to deploy the new production branch to production with r10k on the Puppetserver:

$ r10k deploy environment production -vp

Fattening the workflow series:

Read more on Puppet in our article What is Puppet and how does it work