Skip to main content

Version Your Database

There are numerous benefits of having a standardized local development environment for your entire team to work on and share. This arrangement is essential for reducing bugs and interchanging team members amongst projects – a topic discussed at length in Vagrant Up Can Make Development Easier.

One of the major milestones to achieve in your team’s workflow is assuring everyone is working on the same version of your back-end. This is most often a database of some kind. Whether NoSQL, relational (MySQL, SQL Server), or serverless, we recommend standardizing and versioning your data to ensure the greatest efficiency.

Typical best practices require that each developer has his/her own copy of the database to work. This avoids imposing bugs or changes on other developers which causes unnecessary work, and removes unnecessary roadblocks and conflicts. It’s generally the best overall approach to an Agile workflow.


Nowadays most development frameworks and platforms have some form of migrations. WordPress is a notable exception, although some hybrid solutions do exist via plugins like WP DB Migrate.

Wikipedia defines a migration as “the management of incremental, reversible changes to relational database schemas.”

In practice this means that regardless of which branch of code the developer is working on, a single command can be executed to create, build, and/or update the database so that work can begin immediately. This almost completely alleviates the need for copying/importing databases, fixing conflicts, or dealing with connecting to remote databases and the inevitable connectivity issues that arise.

For example, using Laravel the process would be one or two simple commands:


At this point, every branch of code you go to work on will have a fresh database. Any schema changes necessary to complete your work could be built into a fresh migration script. This can be executed on top of your existing schema.

When merged into your primary release branch, any future development will have your migration(s). As a result, the workflow continues uninterrupted.

Example Migration

Below is an example migration to set up a simple table using Eloquent (Laravel):


Seeding is the process of populating data into a database. This can be “dummy” data or enum data (or both), and is very useful for testing and tuning your models; particularly, in object oriented frameworks.

A simple example that generates a single article:

For further reading on other Development Principles and Best Practices, check out Dev Principle #1: Choose Appropriate Variable Names and Dev Principle #2: Coding Layout and Style Matter.


This was originally posted at Fresh Consulting.


Rebase your database migrations to a single class file quickly

While developing, Doctrine Migrations can quickly become obsolete as you adjust your schema in the early stages of development. Nevertheless, Migrations are still a vital part of properly building compatibility for deployments. However, to consolidate and avoid having several (or in my case dozens) Migration Versions before you’ve got a stable schema, I’ve found it very useful to “rebase” my migrations to a single file.

I also try to keep my non entity driven schemas in a separate file, typically Version0.php. All of my recent development work has been on Symfony 2.7 so I have a modified sessions table I use for PDO session management (that’s a separate debate we can have later). This particular file I want to ignore when running this script so I’m left with two consolidated files for my entire schema:

And last but not least, this simply bash script calls upon a file config in the same source directory that has simple configuration values:


Simply run the bash script above and your Migrations files will be cleaned up entirely. You’ll of course want to rebuild your database as well so everything is in sync.

Symfony Tools

This is one script available in a collection of simple scripts I’ve written to help my development