One of the fastest ways to develop a new wrapper cookbook that assembles together a bunch of community cookbooks and custom glue is to rapidly iterate from within a machine.
You may want to stop me and say "but what about test kitchen?" - and yeah, it's very useful, but there are a lot of things that are more difficult or time consuming to mock out in kitchen than one might like, e.g. interfacing with services like certificate and credential repositories, registering with other network services, etc. that you sometimes need to turn around in short order.
So, bang out a cookbook with the basics and get it onto the chef server, run the initial version on a host, and then edit the cached version on a host using the --skip-cookbook-sync parameter to the chef client to run the local copy. Doing this in why-run mode gives you the fastest iteration times possible in a production-like environment. For small changes needed ASAP to production, it's similarly the quickest path to something that will converge. Especially since you're generally going to be running your test machine on real hardware, instead of your over-taxed workstation...
Of course, when this is all done with, you need to sync your work back to your cookbook repository and let it run through the proper CI/CD workflows, update compliance tests if you have them, etc. but the time-to-deploy on production is lower than any other way I've tried.
Dirty practice? Sure, maybe, but honestly there's so much posting on HN about overly-idealized practices that sound great on paper but just aren't the kind of thing overworked DevOps people have time for. Figuring out how to use shortcuts is often the name of the game.
One of the fastest ways to develop a new wrapper cookbook that assembles together a bunch of community cookbooks and custom glue is to rapidly iterate from within a machine.
You may want to stop me and say "but what about test kitchen?" - and yeah, it's very useful, but there are a lot of things that are more difficult or time consuming to mock out in kitchen than one might like, e.g. interfacing with services like certificate and credential repositories, registering with other network services, etc. that you sometimes need to turn around in short order.
So, bang out a cookbook with the basics and get it onto the chef server, run the initial version on a host, and then edit the cached version on a host using the --skip-cookbook-sync parameter to the chef client to run the local copy. Doing this in why-run mode gives you the fastest iteration times possible in a production-like environment. For small changes needed ASAP to production, it's similarly the quickest path to something that will converge. Especially since you're generally going to be running your test machine on real hardware, instead of your over-taxed workstation...
Of course, when this is all done with, you need to sync your work back to your cookbook repository and let it run through the proper CI/CD workflows, update compliance tests if you have them, etc. but the time-to-deploy on production is lower than any other way I've tried.
Dirty practice? Sure, maybe, but honestly there's so much posting on HN about overly-idealized practices that sound great on paper but just aren't the kind of thing overworked DevOps people have time for. Figuring out how to use shortcuts is often the name of the game.