1

We use puppet to distribute our own software (i.e., the stuff we write, which we want running on our own servers). So somewhere we have to compile this software.

It makes sense to me that I might git pull and compile it on the puppet master. Compile once, distribute, our machines are homogeneous and the binaries run on their anointed hosts.

But when we upgrade hosts, various libraries will change, and we can find ourselves needing to recompile for the new library set.

It seems the right thing to do is to package our software, serve these debs to ourself, and then just use package directives in puppet.

Q1: Does this sound right / Did I miss something important here?

Q2: Then how do the deb's get packaged and uploaded? Is this a manual release process? Meaning we upgrade a test server to the new OS and library versions in order to compile and package.

Q2B: Now suppose I install that CI server I keep telling my team I'll get around to installing. The CI server knows nothing about dist-upgrades, as far as I can tell. So does this part have to remain manual?

jma
  • 415
  • 5
  • 15

1 Answers1

5

Your build procedure can be either manual or automated via CI, via a number of triggers. For example (and this is only one example), you can tag a new release in Git, or move an existing tag and your CI application watches that repository or that tag, and builds/uploads your package.

Your release procedure can also be either manual or automated.

  • Use ensure => latest on your Puppet package resources so that as soon as you publish packages to your repository, they are picked up and installed by your nodes.
  • Use ensure => 'x.y.z' to pin a package to a specific version. With this approach, you can manually bump the versions on specific nodes/roles/environments.
  • You can take a hybrid approach combining the two above by using hiera and parametising your modules - you can ensure latest on your dev/build environments, and x.y.z on your production environment for example.

  • You can remove Puppet from the equation entirely and do manual releases using a tool such as Capistrano.

A separate solution entirely is to utilise Continuous Delivery and treat your servers at cattle, and completely reprovision them with every release - see Martin Fowler's blog for more information on this.

Important Note: The build and release procedures should ideally be completely independent and should not interact, though a successful build could trigger an automated release to a UAT environment for example, and then use a manual/different release procedure for production.

Craig Watson
  • 9,370
  • 3
  • 30
  • 46