Add post-mortem september 2023

[saraycp]

No description provided.

[netlify]

✅ Deploy Preview for openbuildservice ready!

Name	Link
🔨 Latest commit	ec1d0aa
🔍 Latest deploy log	https://app.netlify.com/sites/openbuildservice/deploys/6525334c06de62000812ddc3
😎 Deploy Preview	https://deploy-preview-429--openbuildservice.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[saraycp]

@hennevogel I already pushed all the changes you suggested. Despite the fact that there were errors about conde_of_conduct as well.

The errors with conde_of_conduct happened in less than one minute, not so relevant...
First Notice: Sep 19 08:27:58 Last Notice: Sep 19 08:28:31

[ncounter]

@saraycp what is the state of this PR?

[saraycp]

@saraycp what is the state of this PR?

The blog post missed the Action Items section. I needed time to do some research and testing in order to provide possible solutions. As it is not straightforward, I've decided to add a generic text and go on working on it after this post-mortem is published:

"Plan a strategy to deploy migrations. It might include separating migration deployment from the code changes deployment or splitting the migration into different steps"

[bmwiedemann]

"Plan a strategy to deploy migrations. It might include separating migration deployment from the code changes deployment or splitting the migration into different steps"

That is a sensible approach. First we do the required changes to the database, ensure everything keeps working as before and in a 2nd deployment we add code to use the new DB parts. Would that split happen on the git level, where the PR to use the new parts would wait longer for merge?

[saraycp]

"Plan a strategy to deploy migrations. It might include separating migration deployment from the code changes deployment or splitting the migration into different steps"

That is a sensible approach. First we do the required changes to the database, ensure everything keeps working as before and in a 2nd deployment we add code to use the new DB parts. Would that split happen on the git level, where the PR to use the new parts would wait longer for merge?

The order migration deployment + changes deployment works for the addition of columns/tables.
For removals, the order should be changes deployment + migration deployment, as we need the code to stop using those columns/tables before we remove them.

So far, we have relied on labels like "Reference Server" or "Do Not Merge" to avoid merging and deploying PRs that require special attention. We can use them for the cases we mentioned before until we find a better way to do that.