Recently I created a new VM, which had a Puppet specification. 122 seconds after booting it had a custom MySQL installation, PHP5 and Apache2 configured and everything was up and running. This example illustrates very good, how disaster recovery works at it's finest.

Continuous Delivery

Puppet often used with the term Continuous Delivery. Puppets strength is the automated, templated and unattended setup. Puppet runs every 30mins. Puppet config data is stored in a local file system directory, which can be populated from SVN or Git. Usually I'd push a release to a certain stage, but Puppet is, due it's poller principle, a pull-mechanism. Puppet runs unsynchronized on multiple machines, the Puppet process has no relation of the execution time to other nodes.

From my point of view I would see Puppet in Continuous Delivery as infrastructure automation and configuration file supplier. The deployment scripts should not be a part of Puppet. Perhaps it's only a way of thinking-thing of me.