[chef] Re: Re: Re: Re: application deployments

[Jason Perry < >]

One more question :)

How is using a databag give you more control over staged deployments.  Could 
you provide and example of a databag for an application?

Thanks,
  -- Jay

On Jul 13, 2012, at 2:18 AM, KC Braunschweig 
<
 >
 wrote:

> On Thu, Jul 12, 2012 at 6:43 PM, Jay Perry 
> <
 >
>  wrote:
>> Thanks KC, any reason you chose a data bag over using a role to store the
>> version info?  Did you check in the data bag you kept bumping the version 
>> on
>> or it was just pushed to the chef server each time and it was a databag 
>> that
>> wasn't stored in source control?  I just don't like that our CI server will
>> need to check in the data bag or role so I think we'll just keep a copy of
>> the databag in our CI server.
> 
> Mapping versions onto environments is totally arbitrary data from the
> node's perspective so a data bag made more sense. If your version is
> in the role, your role goes to all environments when you upload a
> change so you lose your staged rollouts. You could have different
> attributes per environment in the role but that seems hacky,
> repetitive and prone to error. You could have different roles for
> different environments, but then you're not deploying exactly the same
> thing in prod as dev and test which is a CD antipattern.
> 
> We made our source repo the source of truth. You can have the chef
> server be the source of truth for your data bag if you want. Either
> way works as long as you pick one and only one. However, I recommend
> the source tree because it is truth for everything else, why split?
> There are tools out there to have jenkins or whatever you use push
> stuff to the chef server in relatively sane ways.
> 
> That being said, we didn't stick with databags for long. Pretty
> quickly became apparent that we wanted custom logic to manage multiple
> CI/CD pipelines for different products so data bags got replaced by a
> service fairly quickly. I'll hit them up again about talking about it.
> 
> KC