Ohai Chefs!
At my org we still have a monolithic chef-repo, with very little testing…
lets say the old way, being said that
I’m looking for advice/comments on how to rebuild this. Things that I think
are no brainer:
- Have a chef server per environment: hosted chef for prod, ideally will be
good to have for the others env too, but monay is the constrain here so OS
for non prod env
- Use a git repo per cookbook
- use berkshelf
- test all the things (foodcritic, test-kitchen, chef-spec, mini-test)
Still I can’t decide what to do with environment regarding cookbooks, have
a branch per environment, like master(prod), test, dev or use
another method
Any other comments, ideas, recommendations are welcome
Thanks for being an awesome community 
–
Jorge Espada
This is what i'd do:
- integrate berkshelf
- Wont split t e cookbooks into separate repos
- Move the cookbook that's takes from community to a separate dir from
org specific cookbooks
4)chances are high the community cookbooks are modified, identify them,
port them to separate wrapper cookbooks or something else (and write
chefspec tests against them)
- Once step 4 is done get rid the community cookbook dir completely
- Setup test-kitchen/minitest against the org specific staff
On Mon, May 6, 2013 at 9:38 AM, Jorge Espada espada.jorge@gmail.com wrote:
Ohai Chefs!
At my org we still have a monolithic chef-repo, with very little testing..
lets say the old way, being said that
I'm looking for advice/comments on how to rebuild this. Things that I
think are no brainer:
- Have a chef server per environment: hosted chef for prod, ideally will
be good to have for the others env too, but monay is the constrain here so
OS for non prod env
- Use a git repo per cookbook
- use berkshelf
- test all the things (foodcritic, test-kitchen, chef-spec, mini-test)
Still I can't decide what to do with environment regarding cookbooks, have
a branch per environment, like master(prod), test, dev or use
another method
Any other comments, ideas, recommendations are welcome
Thanks for being an awesome community 
--
Jorge Espada
Having undertaken a similar endeavor, I'll share one trick that worked for
me:
If you're not already using a site-cookbooks directory, create one and move
all of your existing cookbooks into it. (You may need to reconfigure your
knife.rb.) Now, you can split each cookbook into its own repo and manage it
with Berkshelf.
On Mon, May 6, 2013 at 9:38 AM, Jorge Espada espada.jorge@gmail.com wrote:
Ohai Chefs!
At my org we still have a monolithic chef-repo, with very little testing..
lets say the old way, being said that
I'm looking for advice/comments on how to rebuild this. Things that I
think are no brainer:
- Have a chef server per environment: hosted chef for prod, ideally will
be good to have for the others env too, but monay is the constrain here so
OS for non prod env
- Use a git repo per cookbook
- use berkshelf
- test all the things (foodcritic, test-kitchen, chef-spec, mini-test)
Still I can't decide what to do with environment regarding cookbooks, have
a branch per environment, like master(prod), test, dev or use
another method
Any other comments, ideas, recommendations are welcome
Thanks for being an awesome community
--
Jorge Espada
--
Jeremy Voorhis
Regarding how to manage cookbooks in environments.
- I would NOT use a different branch for staging vs prod chef
environments.
It is too easy to push the wrong one to the wrong place. Our solution is
to just use master branch for a cookbook and upload versions to
prod/staging as needed. All cookbook versions are locked in environments
with --freeze so that we are forced to use good versioning practices when
uploading.
Write a simple wrapper script to upload a cookbook to staging or prod.
Also, check out knife-spork for workflow help.
On Mon, May 6, 2013 at 1:00 PM, Jeremy Voorhis jvoorhis@gmail.com wrote:
Having undertaken a similar endeavor, I'll share one trick that worked for
me:
If you're not already using a site-cookbooks directory, create one and
move all of your existing cookbooks into it. (You may need to reconfigure
your knife.rb.) Now, you can split each cookbook into its own repo and
manage it with Berkshelf.
On Mon, May 6, 2013 at 9:38 AM, Jorge Espada espada.jorge@gmail.comwrote:
Ohai Chefs!
At my org we still have a monolithic chef-repo, with very little
testing.. lets say the old way, being said that
I'm looking for advice/comments on how to rebuild this. Things that I
think are no brainer:
- Have a chef server per environment: hosted chef for prod, ideally will
be good to have for the others env too, but monay is the constrain here so
OS for non prod env
- Use a git repo per cookbook
- use berkshelf
- test all the things (foodcritic, test-kitchen, chef-spec, mini-test)
Still I can't decide what to do with environment regarding cookbooks,
have a branch per environment, like master(prod), test, dev or use
another method
Any other comments, ideas, recommendations are welcome
Thanks for being an awesome community
--
Jorge Espada
--
Jeremy Voorhis
We plan to completely separate prod environment from the other environments
using a separate chef server. This is because we want a full automated sync
between git and chef, and we update roles/nodes regularly (difficult to
version). I'd love to find a better/proper way to enforce this but this
solution works quite well: you develop in a regular git workflow and when
you decide to "release" some automated bot will synchronize the new
prod/master/release branch with Chef.
In addition, as our teams working with chef get bigger we will also "split"
chef servers into multiple organizations (multiple chef servers since there
is no permission system). We have talks about having a central reporting
database probably a bunch of scripts will suffice for now to query all chef
instances.
On May 6, 2013 7:09 PM, "Andrew Gross" andrew@yipit.com wrote:
Regarding how to manage cookbooks in environments.
- I would NOT use a different branch for staging vs prod chef
environments.
It is too easy to push the wrong one to the wrong place. Our solution is
to just use master branch for a cookbook and upload versions to
prod/staging as needed. All cookbook versions are locked in environments
with --freeze so that we are forced to use good versioning practices when
uploading.
Write a simple wrapper script to upload a cookbook to staging or prod.
Also, check out knife-spork for workflow help.
On Mon, May 6, 2013 at 1:00 PM, Jeremy Voorhis jvoorhis@gmail.com wrote:
Having undertaken a similar endeavor, I'll share one trick that worked
for me:
If you're not already using a site-cookbooks directory, create one and
move all of your existing cookbooks into it. (You may need to reconfigure
your knife.rb.) Now, you can split each cookbook into its own repo and
manage it with Berkshelf.
On Mon, May 6, 2013 at 9:38 AM, Jorge Espada espada.jorge@gmail.comwrote:
Ohai Chefs!
At my org we still have a monolithic chef-repo, with very little
testing.. lets say the old way, being said that
I'm looking for advice/comments on how to rebuild this. Things that I
think are no brainer:
- Have a chef server per environment: hosted chef for prod, ideally will
be good to have for the others env too, but monay is the constrain here so
OS for non prod env
- Use a git repo per cookbook
- use berkshelf
- test all the things (foodcritic, test-kitchen, chef-spec, mini-test)
Still I can't decide what to do with environment regarding cookbooks,
have a branch per environment, like master(prod), test, dev or use
another method
Any other comments, ideas, recommendations are welcome
Thanks for being an awesome community
--
Jorge Espada
--
Jeremy Voorhis
We follow semver and tag each version. dev/prod/etc are done using wrapper
cookbooks with versions specified in metadata.rb (you could do same with
environments, but you can’t version environments…) If we need to do a fix
to an older version, then we can check out the tag, make a feature branch,
pull request, etc and then release a bug fixed cookbook.
Note: I whitewashed a lot, but the above is our ideal - treat a cookbook
like a normal “library”