Monday, December 30, 2013

Taking Control of Chef-Client in Continuous Delivery

One of the cornerstones of CD (Continuous Delivery) is to never release anything to an environment before you test it.  It - being your application, the dependencies it owns such as database and caching, interface/integration testing with external services, and your system configuration.

Chef-client's execution on a regular schedule does not fit into CD.  One wrong change to a cookbook by you, or someone else if it is shared, and all your servers are at risk.

I look at chef-client as just another step to releasing code.  It should occur as part of your value stream, in a controlled manner, and tests should execute afterwards to verify that everything is good.  The value stream should control everything - so everything is known.

We need a testing framework for server configuration.  Something that we can execute on a remote server to validate that the configuration is correct.  I bet it could be auto-generated using the cookbooks that are executed against it.  Have a system to expand the tests to include some of our own.

For now, testing our application against the system is good enough for us, but it does make me wonder.

For Windows, you can use Powershell's invoke-command that uses WinRM to execute chef-client.  For Linux, you can ssh into the machine and run it.