In order for Phabricator to be sanely deployed using scap, a few things need to change, either in rMSCA Scap or in operations/puppet/modules/phabricator.

Problems with the current situation

After a scap deployment, we have to run puppet to get the deployed code in shape because puppet enforces a lot of permissions, creates config files, etc. So a newly deployed tag will be missing a bunch of things.

A second problem is that phabricator upgrades involve database migrations which must be coordinated with the code upgrade - once the migration is applied the old code is no longer valid and the migrations cannot be easily rolled back.

So the procedure looks like this:

1. Stop phd
2. Deploy new code version
3. run puppet manually
4. apply db migrations
5. immediately reload apache to pick up the new code
6. start phd

Proposed solution 1: replace manual steps with scap checks

I've attempted to break this up into 3 scripts which can be called from scap "checks"

Roughly divided as follows:

• Promote
  1. Stop phd
  2. Deploy new code version
• Finalize
  1. run puppet manually
  2. apply db migrations
  3. immediately reload apache to pick up the new code
  4. start phd
• Rollback
  1. reload apache
  2. start phd
  3. hope that there weren't partially applied migrations which cause the old phabricator revision to be broken.

This far from ideal, it's essentially how things have been since day one with phabricator only a bit more automated.

Proposed solution 2: change scap

This one is covered in T172486: scap should provide a way to skip symlink-swapping in promote

Proposed solution 3: change rOPUP Wikimedia Puppet/modules/phabricator

After discussing this with @thcipriani, we decided that the best approach would be to change puppet instead of adding a new feature to scap to keep untracked files. I still think that would be nice to have in scap, however, it's not trivial given that scap does a fresh clone of the repo for every deployment.

I've submitted a first draft of solution #3 here