There are few things in software where I’d advocate a ‘one true way,’ but the closest I come is probably migrations. There’s a playbook that we follow to give us the best odds of a smooth switchover:
-
Make the new data models.
-
Write to both the old and the new model.
-
Start reading from the new model.
-
Drop the old data model.
A Worked Example
status which, for each incident, contained one of those four strings. We wanted to move to a world where customers could choose their own statuses, both renaming them and choosing how many they wanted. So how did we do this?
1. Make the New Data Models
We’ve got to agree on the target data model: what the new world will look like. We need a new table to represent the statuses configured against each organization: incident_statuses, and a column on our incidents table to store which status it’s currently in: incident_status_id.
How To Build a Strong Incident Response Process
When building an incident response process, it’s easy to get overwhelmed by all the moving parts. Less is more: focus first on building solid foundations that you can develop over time. Here are three things we think form a key part of a strong process.
I’d recommend taking these one at a time, introducing incident response throughout your organization.