[chef] Re: Re: Triggering chef runs/deploys:

["Leinartas, Michael" < >]

Title: Re: [chef] Re: Triggering chef runs/deploys:

Branching makes sense to me and I can live with it, but I come from an ops background managing java apps where we have discrete build, packaging, installation, and deploy steps so it's unfamiliar - I dont know where the traps lay and honestly, I haven't sat down and thought long and hard about our deployment cases yet.  In any case, the guy's I'm working with (who have final say)  want the deployment trigger to be separate, even if there is a production branch.  I mean if this is the standard way of approaching the problem and I can't find any reason not to, I'll try and convince them to go this route. 

Mostly though at this point I'm trying to survey what options are feasible and in current use by others in the community.

michael


On 8/26/10 4:52 AM, "Jon Wood" <
 
 ">
 > wrote:

> On 26 August 2010 06:25, Leinartas, Michael
> <
>  
>  ">
>  > wrote:
> > So I'm at the point in my chef buildout that I need to start working on
> > application deploys.  The deploy resource is clear enough to work with.  My
> > question is, how do I trigger a deployment?
> >
> One option would be to create a data bag for applications, and trigger
> deployments based on changes to those (possibly put the revision you
> want deployed into the data bag so that the right version hits the
> production servers). Alternatively, you might be better off using a
> different tool for application deployments if continuous deployment
> isn't something you want to do.
>
> I'm curious as to what the problem you see with branching is though.
> As well as providing an easy place for Chef to hook into, it provides
> you with one place that everybody knows is the production code, so
> there's never any doubt as to which version is on the production
> servers.
>
> Jon