Re: [Puppet Users] Managing puppet code

[Jason Slagle]

Although it doesn't seem to do svn yet (You could extend it), I'm fairly
certain you could accomplish this with librarian-puppet.

It's on github.

Your Puppetfile would be in your main repo which could have
dev/stage/prod branches.

Jason

On 08/16/2012 07:22 AM, Benjamin Priestman wrote:
> I'm piloting a puppet deployment that may grow to a fair size (~100
> nodes, at least two distinct sites, dev/stage/prod environments). I'm
> struggling a bit with settling on a strategy and processes for
> managing and deploying puppet code.
>
> As seems to be generally accepted best practice and as required by the
> fact that there will be multiple teams likely to contribute modules
> for their applications, I'm managing the code for each
> internally-developed module in separate repositories - some SVN and
> some git-based, depending on the working practices of the different
> teams. I also want to make sure we have a way of pushing different
> modules through the different environments at their own pace
> (application a's module might be ready to move into production while
> application b's module should remain in UAT).
>
> My issues are around how to pull all these modules together, and how
> to move them through dev/stage/prod environments in sane a reasonably
> simple way. There are a number whitepapers and descriptions of process
> around which mainly seem to rely on having a single git repo with
> different branches representing the different environments. I've got a
> kind of process working which links together different internal
> modules, as well as the git-hub sources of modules that have been
> published to the forge, making use of azimux's externals project
> (https://github.com/azimux/externals). This works quite nicely for
> constructing an unstable trunk/master and could be used to push
> monolithic tags through uat and prod. My current system for deploying
> individual tags, though, relies on creating a library of tagged
> modules and a forest of symlinks under $environment/modules. It works,
> but it is so complex it confuses me, let alone anyone else.
>
> Using forge-style modules seems to be the way to go, but these will
> need management, too.
>
> Does anyone have any suggestions?
> --
> 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/-/rVjji3SQhC8J.
> 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.

[Dan White]

May I politely disagree ?

I feel that using subversion branches for the different environments is defeating the fact that Puppet separates the environments thru the use of the environment setting.

Does that make any sense to you all ?

“Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)

---

From: "Jason Slagle" <rais...@tacorp.net>
To: puppet...@googlegroups.com
Sent: Thursday, August 16, 2012 9:28:29 AM
Subject: Re: [Puppet Users] Managing puppet code

[Jason Slagle]

Below - didn't mean to toppost last time.

On 08/16/2012 10:46 AM, Dan White wrote:

May I politely disagree ?

I feel that using subversion branches for the different environments is defeating the fact that Puppet separates the environments thru the use of the environment setting.

Does that make any sense to you all ?

�Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.�

Bill Waterson (Calvin & Hobbes)

---

From: "Jason Slagle" <rais...@tacorp.net>
To: puppet...@googlegroups.com
Sent: Thursday, August 16, 2012 9:28:29 AM
Subject: Re: [Puppet Users] Managing puppet code

Although it doesn't seem to do svn yet (You could extend it), I'm fairly
certain you could accomplish this with librarian-puppet.

It's on github.

Your Puppetfile would be in your main repo which could have
dev/stage/prod branches.

I suppose it depends on your use case.� Some people use environments for testing puppet, some people run seperate puppetmasters etc to do so.

Having attempted to manage this with git submodules and environments in the past, it's a real pain to make sure things happen the way you want them to.� Throw subversion into the mix and this is a real issue.

Manually promoting code from the "dev" enivronment directory to the "production" directory is a non-starter for most people, so at best you're going to see people check out seperate branches for each environment, which is still a branch model.� I still believe you could manage this with librarian-puppet - just do a puppetfile in each of the enviornment dirs.

Jason

[Benjamin Priestman]

That's been my feeling as well. I want to make sure that the same code goes through each environment. While performing the same merge on different branches should give that result, it's still performing two different actions which - especially with svn in the mix - may give different results.

 

We use dev, systest, uat and prod environments.

 

I'm think I'm heading towards using CI-style checkouts of the main branch of code for systest, with a user-modifiable modules directory in the module path for dev, in addition. Both would exist only on our internal systems. Puppet-library looks like it would be good for this but extending it to use SVN will have to wait for another day.

 

To make it onto UAT, modules need to be packaged up forge-style. A local repo of these packages would get synced between puppetmasters in different environments. I'm hoping I can work past the current crop of bugs and install locally packaged modules with the puppet module tool. I'd install to different module directories for UAT and Prod.

 

This still leaves me with no entirely accurate record of what's on prod at any given time, but the dev trunk will be close enough to rebuild from in the case of total meltdown.