Work-flow for Control-repo in Git

[Lupin Deterd]

Hi,

 What is the work-flow of you Control-repo? We are using single repo with multiple(DEV, QA, PROD) branches which r10k map to Puppet environment. Below is our workflow process:

1) A team member creates a feature branch from Prod.

2) After completing their changes they will then merge it into Dev branch.

3) Dev branch undergoes testing and then deployment.

4) After some time, changes in Dev eventually promoted to QA, PROD.

This works initially when it was only one team doing the work/changes but after opening the work to other teams (apps) it becomes unwieldy. The pain point happens in #2, #3  where some changes have to wait for a schedule before it's get promoted to PROD. Some people have urgent changes which mean there is a long list of changes in DEV which are not in PROD.

I really interested to learn your environment work and if there's a documentation you can point, it would be greatly appreciated.

Lupin

[Brice Bentler]

We use a similar workflow except that our stage and prod branches are separate branches, and are never merged into each other. We reduce the code duplication from this by using a separate puppet module repo where we store all puppet code not specific to a single environment.

[Lupin Deterd]

Thanks for the reply. I'm interested in what did you mean by "manage to create a separate module repo". Are you implying those component modules?

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/db662ea3-9864-4912-bf94-b16a2cb93324%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brice Bentler]

The module repo consists of a single puppet module containing the actual puppet code (.pp files). Anything that is not environment specific goes there.

On Sunday, December 24, 2017 at 12:03:00 PM UTC-8, Lupin Deterd wrote:

Thanks for the reply. I'm interested in what did you mean by "manage to create a separate module repo". Are you implying those component modules?

On Sun, Dec 24, 2017 at 3:07 PM, Brice Bentler <serve...@gmail.com> wrote:

We use a similar workflow except that our stage and prod branches are separate branches, and are never merged into each other. We reduce the code duplication from this by using a separate puppet module repo where we store all puppet code not specific to a single environment.

On Saturday, December 23, 2017 at 3:05:25 PM UTC-8, Lupin Deterd wrote:

Hi,

 What is the work-flow of you Control-repo? We are using single repo with multiple(DEV, QA, PROD) branches which r10k map to Puppet environment. Below is our workflow process:

1) A team member creates a feature branch from Prod.

2) After completing their changes they will then merge it into Dev branch.

3) Dev branch undergoes testing and then deployment.

4) After some time, changes in Dev eventually promoted to QA, PROD.

This works initially when it was only one team doing the work/changes but after opening the work to other teams (apps) it becomes unwieldy. The pain point happens in #2, #3  where some changes have to wait for a schedule before it's get promoted to PROD. Some people have urgent changes which mean there is a long list of changes in DEV which are not in PROD.

I really interested to learn your environment work and if there's a documentation you can point, it would be greatly appreciated.

Lupin

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.

[Andreas Zuber]

On 12/24/2017 12:05 AM, Lupin Deterd wrote:
> This works initially when it was only one team doing the work/changes
> but after opening the work to other teams (apps) it becomes unwieldy.
> The pain point happens in #2, #3 where some changes have to wait for a
> schedule before it's get promoted to PROD. Some people have urgent
> changes which mean there is a long list of changes in DEV which are not
> in PROD.
>
>
> I really interested to learn your environment work and if there's a
> documentation you can point, it would be greatly appreciated.

Hi

I recently ran into the same problem when working for a customer. So far
Puppet was only used in the platform team which delivered a base profile
and some basic roles.

The dev->nonprod->prod release life-cycle is guided by a weekly review
board in which ops has the final word on what merge requests get trough
and rolled out how fast to what environments. So this would be a huge
blocker for the applications guys if they had to go trough the same
procedure and would become a mess for ops as well.

To solve this we did something I call environment overlay. Each
application can onboard their own control repo (we obviously automated
this with Puppet ) and have their own release life-cycle.

The deploy script on the Puppet Master will then deploy them into
environments with the convention dev_<appid>, nonprod_<appid> and
prod_<appid>. The trick is then to also add the "base" environment
dev/nonprod/prod modules in the environment.conf to the modulepath which
then includes (for dev):

modulepath=/etc/puppetlabs/code/environments/dev/modules:/etc/puppetlabs/code/environments/dev_myapp/modules

Also the default manifest then makes sure the base profile is always
included.

Then there is a custom ENC indirector (although a normal script would
probably work as well) which checks for each node what original base
enviornment it has and which appid and then if there is a valid
enivironment for that combination it will overwrite the environment with
that appid-env.

Example:
The node has env "dev" and appid "myapp". If there is an environment
dev_myapp on the puppetmaster it will set the environment to dev_myapp,
if not to dev.

This also has the additional benefit that the stuff the "myapp" dudes
are rolling out to their environments have no impact on stuff the
"thatotherapp" dudes are doing, since their code is only used by their
nodes and not visible from other apps.

Maybe there are some other, better ways to do this. But so far I have
not seen anyone doing anything similar and write about it.

Regards
Andreas

[Barney Garrett]

I've too have been looking at workflow as part of a move to puppet 4 and I'm confused to hell and back ;) .

Currently we have a single CA Master and a number of production compilation masters and a production puppetdb, there are also a number of test compilation masters and a test puppetdb.  We run with essentially 2 branches, one for production and one for test each being deployed without r10k to their respective compilation servers.  The changes in the production and test branches are synchronized using meldmerge.  

Personally I'd like to get away from this model and actually introduce a more rigorous peer review process, our software development teams use Gerrit and our puppet code is actually in this server we just don't currently use the features.  The things I've been reading suggest that having long running branches for what people seem refer to as application tier (dev, prod, test etc) is bad practice and you should have a single main branch with possibly a 2nd one for integration testing.  Work is done in short lived branches that are merged into the main line when the work is complete.  Membership of dev, prod, test etc is determined by facts on the node.

There are still some issues I don't really understand though.  It would appear that puppetdb doesn't support environments all that well either so it would follow that assuming we want to maintain a production and test estate for the servers we are maintaining then from a puppet infrastructure perspective you'd still have a Puppet CA, a number of production compilation servers with a puppetdb, and a number of test compilation servers with its own puppetdb.  Either of these could have multiple temporary environments deployed on them (hotfix branches on the prod compilation servers and feature branches on the test compilation servers) but ultimately each main application tier (prod or test) is actually deployed from the same branch but from different points in time.  Unfortunately it would appear r10k doesn't support looking at a specific tag of the control repo so not sure how you'd work round that either.

Am I just being naive and foolish or is this kind of workflow possible or even desirable ?

[Lupin Deterd]

I was hoping someone from Puppetlabs with their wealth of customer experience will chime in. I'm surprised that the community doesn't have an endorse pattern for this, like what we have with "Roles and Profile".

--

You received this message because you are subscribed to the Google Groups "Puppet Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/b0ceac18-cc41-49b8-829a-c7a581f44ac6%40googlegroups.com.