Dev Principles

Web Development

Dev Principle #3: Version Your Database

July 27, 2016

Jake Litwicki

By Jake Litwicki

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. Versioning your database requires treating it like code.

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.

Migrations

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:

Copy

# Create the articles table
php artisan make:migration create_articles_table --create=articles
Copy

# Add to the existing articles table
php artisan make:migration add_votes_to_articles_table --table=articles

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):

Copy

<?php

use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;

class CreateArticlesTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('articles', function (Blueprint $table) {
            $table->increments('id');
            $table->string('title');
            $table->string('body');
            $table->timestamps();
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::drop('articles');
    }
}

Seeding

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:

Copy

<?php

use Illuminate\Database\Seeder;
use Illuminate\Database\Eloquent\Model;

class DatabaseSeeder extends Seeder
{
    /**
     * Run the database seeds.
     *
     * @return void
     */
    public function run()
    {
        DB::table('articles')->insert([
            'title' => str_random(10),
            'body' => str_random(1000)
        ]);
    }
}

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.

Jake Litwicki

Jake Litwicki

Software Development Director

Jake is a software engineer and leader with over ten years of experience working with and/or managing teams of designers, developers, and artists. He loves working with projects involving Symfony, Drupal, Wordpress, Angular, and Laravel but most of all loves the challenge of a new technology. In his spare time Jake is an aspiring fisherman and woodworker while not spending time with his wife and two children.

Unless otherwise specified, source code in this post is licensed under a
Creative Commons Attribution 4.0 International license (CC BY 4.0).

You might also like...

20

Oct.

Steve Hulet

Announcing Fresh Consulting’s WCAG 2.0 PHPCS Linter

Today, Fresh Consulting is announcing the release of our WCAG 2.0 PHPCS Linter. The linter is a set of rules (or sniffs) for PHP Code Sniffer which can automatically detect and alert when certain WCAG 2.0 violations are detected in code. WCAG 2.0 supports designers and developers in meeting the guidelines and success criteria of accessibility. The … Continued

17

Oct.

Sean Patterson

Dev Principle #11: DRY – Don’t Repeat Yourself

As the size and scope of a project increase, so does the complexity of the code base. One way to maintain and stabilize your code is to adhere to the “DRY” Principle: Don’t repeat yourself. #1: Use the DRY Principle to Decrease the Size of Your Code Base If you’re writing code to do the same … Continued

30

Aug.

Xavier Reyes

You Should Be Using BitBucket Pipelines

Commonly, developer workflows include pushing code to BitBucket. From there, you run processes like testing, updating a staging server, and generating documentation. All of these processes can become very repetitive. Thankfully, they can also be automated. That’s where Bitbucket Pipelines comes in. It’s simple – you only have to create a set of scripts that run … Continued