This was a good article and I know the topic well, having made the same mistakes myself. Database changes can be tricky, particularly if you don't have the right testing strategy and assets in place. It sounds like this mistake will be a good opportunity for you to propose some changes to mitigate this risk in the future. This is the process I always push for when the database has matured:
You NEED a dedicated DEV/TEST/QA environment (at least one, preferably all 3).
The DEV/TEST/QA environments are not on your desktop and are built entirely from your CI/build automation tool(s).
The DB for those environments is also refreshed from PROD (or a backup at the right version). This can get a little tricky since PROD may be some revisions behind your DEV/TEST/QA. Your build utility will apply the change scripts associated to your revisions to get the environment up to date when a refresh is performed (e.g. PROD is at 100, refresh script applies changes for 101, 102, 103 post refresh and now you have a DEV database with PROD data at version 103).
If privacy/size constraints exist, your refresh script should handle purging that data and/or creating test data. Your goal is to have an environment matching production as closely as legally/realistically possible.
Your deployment includes a code change AND a db change script. These two are tightly coupled and must always be deployed together.
I'm assuming you always have a rollback strategy for code changes (if not, you need one) built into the deployment. Your database deploy script should also include a rollback strategy. In this example, that means you would be removing the column you just added and putting things back to where they were. Deployments should also have a pre-deployment backup performed as part of the script. This is your rollback of last resort should things go terribly wrong.
Deployments are done by a tool/automation or handed off to a third party with the right production access. No developer should be directly changing PROD. It sounds like you have this already.
With the above in place, your change would have been committed to source control, picked up in the DEV build and applied to the DEV database then tested by you. After that, it would move to QA (depending on that schedule, sometimes these would be a selection of revisions merged into QA from DEV targeted at the next release to PROD) and be tested there. Finally, it would be put into the PROD release and at that point, it would be fully vetted and tested from both the build automation perspective and functionality perspective. Can there still be issues? Of course. But from my experience, a setup like this will catch all but the most obscure and unpredictable bugs. It's a stricter schedule and some might argue it's not CI but it's still possible to do CI with this. Emergency changes may take a different route and be manually done but would still be tested in a dedicated environment.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This was a good article and I know the topic well, having made the same mistakes myself. Database changes can be tricky, particularly if you don't have the right testing strategy and assets in place. It sounds like this mistake will be a good opportunity for you to propose some changes to mitigate this risk in the future. This is the process I always push for when the database has matured:
With the above in place, your change would have been committed to source control, picked up in the DEV build and applied to the DEV database then tested by you. After that, it would move to QA (depending on that schedule, sometimes these would be a selection of revisions merged into QA from DEV targeted at the next release to PROD) and be tested there. Finally, it would be put into the PROD release and at that point, it would be fully vetted and tested from both the build automation perspective and functionality perspective. Can there still be issues? Of course. But from my experience, a setup like this will catch all but the most obscure and unpredictable bugs. It's a stricter schedule and some might argue it's not CI but it's still possible to do CI with this. Emergency changes may take a different route and be manually done but would still be tested in a dedicated environment.