Puppet/Hiera and Git workflow

[Andy Taylor]

I'm currently trying to work out the best way structure my Puppet
environments and VCS structure. At the moment I'mk working on
something like this:

Three Git repositories (one for modules, one for Hiera, one for node
manifests)
Multiple branches (each branch representing an environment, e.g.
production, dev, testing etc.)

When changes to modules/Hiera are made, the changes will be made to a
testing branch, and then merged up the branches until it hits
production (with the appropriate testing of course). So something like
this:

unstable > dev > testing > production

What system do you guys use? Any suggestions about the above workflow?

Thanks!

Andy

[Jos Houtman]

I am setting up a new workflow myself, it will be as follows:

One git repo for modules and manifests, a second for hiera. Branches are for features and personal development branches.

I might install forge repositories in a different modulepath to force working with the community.

The git repository goes through gerrit and all commits are automatically check checked for syntax or lint errors by jenkins before they are merged.

All modules updates might also require a visual code-review, don't know yet.

Different environments (development, staging, etc) are represented using an extra hiera lookup level and are also reflected in the node to modules mapping thats in place.

This is what works for us.

Jos

[Carlos Rico]

We work only with one Git repository for Puppet, and it contains:

- 1 directory for hiera-data -> structured environments. For instance: 

hiera-data

   |--common

   |      |- us

   |--master

   |      |- us

   |--production

(etc)

- 1 directory for all nodes, and 1 manifests file (xx.pp) for each node type

- And the rest of Puppet modules

Carlos.

[Andy Taylor]

Thanks guys, very interesting. I guess the main thing I'm concerned
about with my workflow is that I'll be doing a lot of merging, and I'm
not sure how sustainable that is. For example:

1. Add new feature to unstable
2. Merge to dev
3. Merge to testing
4. Merge to production

The idea being that once I've done step 4, all four branches will be
identical. Between each step I'll be doing extensive testing. I'm also
a bit worried about how I'm sacrificing agility with this workflow,
unless I'm confident enough with a change that I'll merge dev/testing/
production with unstable in one go.

[Nigel Kersten]

On Mon, May 28, 2012 at 6:14 AM, Andy Taylor <andyta...@gmail.com> wrote:

I'm currently trying to work out the best way structure my Puppet
environments and VCS structure. At the moment I'mk working on
something like this:

Three Git repositories (one for modules, one for Hiera, one for node
manifests)
Multiple branches (each branch representing an environment, e.g.
production, dev, testing etc.)

When changes to modules/Hiera are made, the changes will be made to a
testing branch, and then merged up the branches until it hits
production (with the appropriate testing of course). So something like
this:

unstable > dev > testing > production

Do you need a distinction between "unstable" and "dev" ? I've often found that I don't need those to be separate stages.

 

What system do you guys use? Any suggestions about the above workflow?

Thanks!

Andy

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

--
Nigel Kersten | http://puppetlabs.com | @nigelkersten

Schedule Meetings at: http://tungle.me/nigelkersten

[Andy Taylor]

The git branches/Puppet environments actually mirror the
infrastructure. So we have groups of servers. Unstable is just for
nodes which I test new functionality on, dev is for web developers. So
it seemed to make sense to mirror the environments in the git
repository with branches.

On May 29, 9:28 pm, Nigel Kersten <ni...@puppetlabs.com> wrote:

[Jos Houtman]

As said we handle this a little different.
One branch for development, staging and live.

Development of the puppet code base is done using in puppet
environments, which can be used to test a change across systems in any
of the environments.
Once people consider the change working it is committed and pushed. At
which point we check for lint or syntax errors as a precaution.

Bigger changes are ussually hidden in if/else constructs that allows
us to roll them out gradually.

this works for us, because:
- The development/staging and live environment have a big overlap.
- We accept that there might be a few mistakes.

It is a tradeoff between rigorous testing and development speed.

Jos