[chef] Re: Re: Testing cookbooks before release


Chronological Thread 
  • From: "steve ." < >
  • To: " " < >
  • Subject: [chef] Re: Re: Testing cookbooks before release
  • Date: Wed, 26 Jun 2013 17:12:14 -0700

We have one (...sadly, since we need to replicate this about 30-40 times) Jenkins-based CI framework that tests all permutations of role / Chef client version / environment / platform for a Chef repository.  It triggers on pushes to one of two branches (master / testing), but then I got the GitHub Pull Request Builder plugin working and things got really exciting -- people would send in their changes as PRs and we'd know within about 20 minutes if they were going to end up breaking the world.  All the roles include the minitest handler and we have people writing minitests in their cookbooks, so theoretically we catch subtly-broken cookbooks this way ("Template deployed, httpd started, 404 on the site" should result in a test failure, for example).

Of course, we're maintaining a number of weird/proprietary cookbooks and repo maintenance is starting to become a thing.  Over the next couple months I'll be refactoring all this to support other provisioners and Berkshelf/Librarian.  (As, presently, it doesn't.)

I'd also like to add in a performance testing stage of some kind, but basically the idea is that if a change survives all these steps it is theoretically releasable to pre-production.  Assuming you have a separate pre-production Chef endpoint, you could add a final step in CI that updates pre-production automatically.

(For great excitement, how about a handler in pre-production that checks in with a separate promotion service -- once your deploys and tests come back OK across all of your pre-production nodes, the big "Deploy this repo state to production" button turns from grey to black.)


On Wed, Jun 19, 2013 at 1:42 AM, Dorian Jaminais < " target="_blank"> > wrote:
What I do is hat production environment contains version restriction.
That way when I push a new version of a cookbook, the staging environment start to use it. When I a sure it won't break anything, I update the production environment to the new version.

Not sure if this is the best way, it is fairly simple yet totally manual.

I'd be happy to hear from other chef on how they handle this.


2013/6/19 Jens Skott < " target="_blank"> >
Heyas, we have a setup where we develop cookbooks in a branch in git, test them in a local vagrant box. After that we push them to staging branch in git and then to prod and release it. Then its released to staging and prod at the same time, i want an additional testingstep on the staging branch before the pull request to prod.

Any tips how to start? 

Have tought about using chef_solo on all staging machines and have them pull from development branch when run, but i want chef solo to run every 30 mins like the chef client.

Or does anyone have any better suggestions?
We dont want to use environments since we havnt found a good way to automate the process of bumping versions in the prod environment when releasing cookbooks to prod.


Jens Skott 
Tel: +46-8-5142 4396
Schibsted Centralen IT




--
Dorian JAMINAIS
System Administrator
+33 6 95 10 95 37







Archive powered by MHonArc 2.6.16.

§