Ask Your Question
2

What is your workflow to merge puppet control repo (environment) branches?

asked 2015-06-01 22:39:01 -0600

kaizenCoder gravatar image

We use control-repos (Puppetfile, hieradata, roles & profiles) and r10k to manage environment branches.

Our modules are stored independently of the control-repo and is included via the r10k Puppetfile.

When a new module developed and is pushed to its respective repo, the following occurs:

  1. Create a feature branch off control-repo environment branch i.e: model
  2. Update hieradata key/values
  3. Update profiles
  4. Update roles
  5. Update Puppetfile to require the module
  6. Test feature branch
  7. On success, merge to environment branch i.e: model

At this point, I'm interested to know how I can ensure the remaining environment branches are updated?

I seem to have hit a few issues in figuring out the best way to do this, so I'm keen to know how others approach introducing changes in to their environments?

Thanks.

edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted
1

answered 2018-02-16 18:17:31 -0600

bentlema gravatar image

updated 2018-02-16 18:22:10 -0600

Hi kaizenCoder,

You've stumbled upon why having unique long-lived branches/environments (other than production) doesn't work well. Peterino's comment from your StackOverflow question is exactly right (In my opinion).

According to my research the r10k developers want us to use simple feature branching (aka GitHub Flow), using production as your main branch. Hence, rename master to production to start with, then always branch off feature branches from production, test them, and merge or rebase the changes into production again. -- Avoid several long-living branches, stick to a single production branch and use short-lived feature branches. – Peterino Aug 4 '17 at 10:20

Rather than keeping different (unique-to-an-environment) versions of Hiera data, or different versions of the Puppetfile, or different versions of your Roles/Profiles, try writing them so that they work across all "App Tiers" or "Server Tiers" (dev, integration, qa, test, staging, production). You can structure your Hiera Hierarchy (in your hiera.yaml) such that you can still provide different data for differing Tiers. In your puppet code, you can use conditionals or case statements when necessary, but if you design your Hiera Hierarchy correctly, you may not even need to, you'll be able to accomplish the same thing you're now, and wont have to duplicate your changes across multiple environments, and cherry pick commits all over the place.

Doing the above can get you around most of the problems, but if you really need to run different versions of modules for an extended period of time in another environment/branch, your Puppetfile will be different (as you've noticed) and you'll still need to deal with that from time to time. One way I've delt with it in the past was to do my merge (say from feature to model) using the --no-commit option, and then manually removing the Puppetfile from the merge before I commit.

I hope that helps!

edit flag offensive delete link more

Comments

I would echo the above, structure your heira data so it contains a level/file for your ‘environment’, that way you have a single trunk that contains prod, qa, test, and dev values, with an ‘environment’ fact that is used to choose the right data. That alows a single path/flow without maintaining ..

DarylW gravatar imageDarylW ( 2018-02-17 21:25:54 -0600 )edit

... long lived independent branches with independent merged required into each long lived branch. Unless there is some security reason that the dev environment can’t know the prod passwords or something, that is your best bet.

DarylW gravatar imageDarylW ( 2018-02-17 21:27:36 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

4 followers

Stats

Asked: 2015-06-01 22:39:01 -0600

Seen: 831 times

Last updated: Feb 16