lately I’ve been trying to update some of my development processes and I came around one problem. I am trying to keep different Git branches in my local environment, especially for some experiments and updates, that can potentially break main version of my OctoberCMS website. I included in Git also vendor files and composer.lock to easily revert broken updates when needed.
The only thing, that remains to be solved is DB. My idea is that if I update OctoberCMS and some plugins, it also run some migrations in DB. But now if I switch back to main branch, there is still this updated database. I was wondering if I can somehow easily rollback it to version it has before. Basically every time I change branch.
I know I can drop it through php artisan october:migrate --rollback and then build it again, but I will lose my data this way. Which is actually another of my requirements. I would like to keep them. At least those not directly affected with migration.
Another idea that I came up with is to create new DB for every branch. I would add it to my .env file and set it up in config. This way it would automatically change when I am switching branches. And if merge something to main branch, I would only run php artisan october:migrate.
This works for me so far, but my question is if this is good approach. Does anybody have some best practices or advices in this area?
A backup of the database paired with the version is a good idea. MySQL has some useful commands that could automate this process (mysqlimport & mysqldump) using bash scripts.
These commands output the database as a cleartext .sql file and could be stored in the repo along with the project. Keeping this up to date would allow you to inspect the changes made across versions to see if they need to be rolled back.
It is helpful to have this information because, in most cases, database migrations will introduce columns and not destroy data. This is an unofficial policy we have with the October core to avoid data destruction, but other plugins may be different.
With this in mind, in most cases rolling back the code will be enough without needing to roll back the database schema.
Thank you for your answer. Perfect then. I will use this approach and I will maybe try some automation with MySQL commands you recommended in the future.
With this in mind, in most cases rolling back the code will be enough without needing to roll back the database schema.
This actually had worked for me so far, I was just not sure if it will be functional in more complicated scenarios. Like when some plugin destroy some columns in DB. But it’s good to know that you keep policy of not doing it in OctoberCMS core. It’s giving me more ease of mind in this topic.
