Grokbase › Groups › Puppet › puppet-users › May 2012
FAQ
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

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

Search Discussions

  • Jos Houtman at May 29, 2012 at 11:44 am ⇧
    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




    On Monday, May 28, 2012 3:14:54 PM UTC+2, Andy Taylor 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

    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 view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/03LLU2p-mvMJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Carlos Rico at May 29, 2012 at 11:54 am ⇧
    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.

    El lunes, 28 de mayo de 2012 15:14:54 UTC+2, Andy Taylor escribió:
    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

    El lunes, 28 de mayo de 2012 15:14:54 UTC+2, Andy Taylor escribió:
    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
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/CGaw2HKh4hMJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Andy Taylor at May 29, 2012 at 7:33 pm ⇧
    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.
    On May 29, 12:48 pm, Carlos Rico wrote:
    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.

    El lunes, 28 de mayo de 2012 15:14:54 UTC+2, Andy Taylor escribió:








    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
    El lunes, 28 de mayo de 2012 15:14:54 UTC+2, Andy Taylor escribió:








    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
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Nigel Kersten at May 29, 2012 at 8:28 pm ⇧

    On Mon, May 28, 2012 at 6:14 AM, Andy Taylor 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-users@googlegroups.com.
    To unsubscribe from this group, send email to
    puppet-users+unsubscribe@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

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Andy Taylor at May 29, 2012 at 8:34 pm ⇧
    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 wrote:
    On Mon, May 28, 2012 at 6:14 AM, Andy Taylor 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-users@googlegroups.com.
    To unsubscribe from this group, send email to
    puppet-users+unsubscribe@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
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Jos Houtman at May 30, 2012 at 7:14 am ⇧
    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
    On Tue, May 29, 2012 at 10:34 PM, Andy Taylor wrote:
    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 wrote:
    On Mon, May 28, 2012 at 6:14 AM, Andy Taylor 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-users@googlegroups.com.
    To unsubscribe from this group, send email to
    puppet-users+unsubscribe@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
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedMay 28, '12 at 1:14p
activeMay 30, '12 at 7:14a
posts7
users4
websitepuppetlabs.com

4 users in discussion

Andy Taylor: 3 posts Jos Houtman: 2 posts Nigel Kersten: 1 post Carlos Rico: 1 post

Content

People

Support

Translate

site design / logo © 2022 Grokbase