Ibexa DXP Discussions

Community discussion forum for developers working with Ibexa DXP

Database Strategy and Tools

It’s been almost a year since my team started our ezplatform project. We are using ezlaunchpad which is an amazing tool for developing our site locally. We have connected our BitBucket repository to Platform.sh for deploying our site to an enterprise production and staging server. We have adopted using Kaliop Migrations for making changes to our Production & Staging eZ Platform schema. With the multitude of environments we need the best tools available to be efficient in our day to day programming tasks.

Our current database workflow allows our developers to use a “shared” or “local” database through our parameters.yml configuration file. We have decided that there are scenarios where having a shared database is helpful when working on front-end templates or using “dummy content objects or content classes” that another developer has already created. The shared database does expose the possibility for corrupting data by stepping on one another’s changes. This means there are times that the shared database needs to be overwritten with production data from Platform.sh so any “in progress” schema changes made to the shared database would be lost. Our development strategy is that any “in progress” changes should be first tested locally on each developers local machine before being migrated to the shared database. The recommended approach is to capture these changes in a Kaliop Migration file OR make these changes through the Admin UI and then run a Kaliop migration export of those changes so they can be rebuilt at a moments notice. So overall what I’m talking about is database state for development.

Another caveat of using Kaliop Migrations is that if you make a mistake in your migration file, the migration fails and you then have to manually delete the migration in order to “restart” the migration. The alternative is to reset your database from an export to essentially start fresh. This is an extra step that can be very frustrating especially if you cannot find your error right away. I also prefer to start with a clean import of the production database so I know for sure that running this migration would work when it’s deployed to Platform.sh.

So the current workaround is to execute the following ezlaunchpad commands to “reset” the database when a migration fails. That would look like this: ~/ez importdata then ~/ez sfrun cache:pool:clear cache.redis and ~/ez sfrun ezplatform:reindex. I have also created a bash script for importing and exporting a database from within the docker engine container. I prefer to work inside the container anyway and use the composer and console CLI tools natively. So instead of having to write a really long command every time I need to reset the database, I built a bundle for importing and exporting the database as well as appending the cache clear and ezplatform reindex commands right after.

The bundle can be found here: https://github.com/Restek/ez-dev-tools.

This bundle uses another bundle called backup-manager/backup-manager which handles the database import and export functions. My bundle command combines three commands into one command.