We needed a way to describe our pipeline deployment approach. How and when are things released. In what order do we modify the code and the database when it is not possible to do them all instantly.
And so we came up with this silly acronym. We know there are probably better approaches, but this has worked very well for us. To the point that our continuous integration and deployment pipelines can run all of these unattended, allowing our developers to develop and our reviewers to review and the poor release monkey can retire from running all those releases by hand.
Pro - Protect migrations
As migrations are developed and versioned using the current timestamp, and prior to Phinx 0.8, we needed to make sure that if we needed to rollback, we wanted the migrations to rollback in reverse execution order, not reverse creation order (which is a totally meaningless order when you have multiple developers/branches and the code is merged at different times). So we can reversion our migrations based upon the current maximum version in the production phinxlog. We also have a corresponding githook that re-syncs the developers migrations for those that have been "protected" (not a great term but it made sense to us and that's what our team understands). If there are any reversioned migrations, then they are committed to the repo and trigger a new pipeline, aborting the current one. So all tests and analysis have a clean run.
Mi - Migrations
Once all the migrations that are required have had their version numbers restamped, we are ready to run them against the database.
Re - Repeatables
Phinx does not support repeatables, so we have our own system which can then deal with views, stored procedures, triggers, and functions. These run after migrations. We get the devs to think of repeatables as code. You use source control to "version" them, just like you do with the application code.
D - Deploy
Having got the database ready, we can now deploy the code.
From this, we have a few "rules" that we want our devs to stick to. We enforce what we can in our pipelines, so a dev breaking something we have enforced will not even be able to make a pull request and so no review takes place, nothing is merged to master, the world doesn't come to an end. That sort of thing.
-
ALL migrations must be compatible with currently running code. So dropping a table before the code that uses that table is released is a no-no. Adding a new column must have a default value (the default can be changed in a future migration once the code that populates the column is live and all preexisting rows have been populated).
-
ALL repeatables must be compatible with currently running code. Like the dropping of a table in a migration, it may be necessary to adjust views several times before the code is finalised.
-
Only 1 of these are really expected to be in a branch. Though our reviewers can make that decision, it is sometimes simpler to enforce this in the pipeline (cannot have changes to migrations, or repeatables, with and any other changes). Using your project management tool to link/block branches so that they can be developed in tandem or out of order, but the release is always in a controlled order that honours ProMiReD.