On Thu, Nov 21, 2013 at 04:27:47PM +0100, David Caro wrote:
On Thu 21 Nov 2013 03:57:27 PM CET, Itamar Heim wrote:
On 11/21/2013 04:46 PM, David Caro wrote:
On Thu 21 Nov 2013 03:03:00 PM CET, Itamar Heim wrote:
On 11/21/2013 03:29 PM, Ohad Basan wrote:
+1
----- Original Message -----
From: "Ewoud Kohl van Wijngaarden" <ewoud+ovirt@kohlvanwijngaarden.nl> To: infra@ovirt.org Sent: Wednesday, November 20, 2013 8:27:39 PM Subject: Puppet environment name / branch name
Hello,
I just deployed r10k to be the deployment method and it works generally well. One problem is that it maps branches one to one. Currently I worked around this by making a symlink, but I think we should rename our master branch to production. Opinions?
is that common? usually master is named master.
Maybe it's better to change puppet config to use master as the 'production' environment source of manifests. I say that because it's usually a mess to have a branch that it's not the master as master... (@work we use development as master in one of the repos, and I always submit a patch or two a month to master instead xd)
well, one other though is that if you ever intend to have more than a single branch, master is usually not the stable production one...
I suppose that it depends on the flow the company/project uses, in my last job we used master as the stable branch, and we had devel as the non-stable branch and one branch for each major version we supported, but master was always the latest major version production-ready code. Then on master we had tags for each release and so on. I suppose they get the idea from gitflow http://nvie.com/posts/a-successful-git-branching-model/
But yes, bad habits are hard to get rid of. Any way is fine for me, but if no one has any reason for the other way, I vote for using master instead of production.
I think r10k doesn't care about branches, it just maps them 1-to-1 to puppet environments. That means we can also move all our puppet clients to master if you think that's better. We could also add a testing branch to create a testing environment for example. My suggestion to make it production is that even when you're writing patches, you know it's for production. My experience with working on non-master is that it's trivial for new clones (assuming you change HEAD on the remote server) and some effort for every existing clone.