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
Archive powered by MHonArc 2.6.16.