Mark researches Puppet as a new format of distribution for release work.
Hi Gwicke :)
I'm guessing the original intention for this was distribution of software internally via puppet for home grown stuffs. So in ignorance and/or omniscience I am doing something atypical for Phabricator itself which I think is the most relevant example. See: https://phabricator.wikimedia.org/diffusion/OPUP/browse/production/modules/git/manifests/install.pp. In essence I track repo's for Phab with a tag in Git, that tag is managed and enforced via Puppet. It is basically this https://github.com/wikimedia/operations-puppet/blob/production/manifests/role/phabricator.pp#L64. There is a lock file on the box itself that will have Puppet warn in the console if the local state is a mismatch but will not actually change anything.
So to update Phabricator repos (multiple repo's that need to be tracked together):
- Change the tag in Puppet
- Log on to Iridium and run Puppet to see the new tag waiting
- remove lock file and run Puppet
A few neat things about git checkout tags/mytag is that is works even if the tag isn't in the master branch and it generally plays nicely with git remote update so there isn't as much worry about what state the repo is in to begin with.
In practice there is phab_upgrade_tag script that stops some things and does a bit of sanity checking and schema updating post repo update but this is the general idea and probably the closest thing to coupling Puppet state with code in prod.