Unable to understand the benefits of r10k dynamic environments..
We use Puppet, hiera, r10k with a number of forge modules, roles and profiles patterns to perform an automated deployment of a Java/NodeJS Application.
I find r10k to be very useful in fetching all dependent modules from a Puppetfile. However I am confused with the benefits of the r10k dynamic environments. We have 8 environments, so we have created 8 branches in Git. The important feature is that all these 8 environments are identical except for heira properties.
Whenever we make a change in one of the puppet manifests(roles or profiles), we manually have to merge(sometimes cherry-pick) these changes from 1 branch to the other, when we are ready to do a new deployment in another environment.
Managing code in 8 branches is appearing to be a time-consuming and an error-prone process to me. I am thinking of moving away from r10k dynamic environments usage and have only 1 branch (master). Whenever we deploy anything to Production env, we just tag the appropriate commit with a Git Tag.
When the business application code that the development team are writing does not have a Git branch for every environment, why should R10K mandate that we create a branch for each environment containing the same puppet code?
I was wondering if any body has benefited from using R10k dynamic environments for automated deployment of an Application and can share their experience.
I second that. In addition, I would be interested whether I can use `r10k` just for installing and uninstalling modules listed in my `Puppetfile` (as a drop-in replacement for `librarian-puppet`, if you want so), without the "side-effect" of maintaining environments for feature branches.
I believe what we see is a concept implementation that has gotten out of control. Using branches for configuration management is an anti-pattern. Git isn't meant to be used as conf mgmt tool. There should be a single branch for all environments.