- From: KC Braunschweig <
>
- To:
- Subject: [chef] Re: Re: Re: application deployments
- Date: Thu, 12 Jul 2012 23:18:11 -0700
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.