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" <[email protected]> > >>>>> To: [email protected] > >>>>> 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. _______________________________________________ Infra mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/infra
