Testing cookbooks before release


#1

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


#2

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 jens.skott@schibsted.se

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
http://perfect-memory.com

https://twitter.com/semanticbushttp://www.facebook.com/pages/Perfect-Memory/155555567821817


#3

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 <
dorian.jaminais@perfect-memory.com> 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 jens.skott@schibsted.se

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
http://perfect-memory.com

https://twitter.com/semanticbushttp://www.facebook.com/pages/Perfect-Memory/155555567821817