Automatic Versioning in Laravel 5

I started with this article http://afaraz.it/post/laravel-4-versioning-your-app-using-git

I had to make changes because the author is using a post-commit hook.  Every time I committed, I had a dirty repository since it was updating the version file after commit.  This solution is verified working in Laravel 5.

First, create your new command:

$ php artisan make:command Version

Here is my Version.php command file:

<?php namespace SalesMonkey\Console\Commands;

use Illuminate\Console\Command;
use Symfony\Component\Console\Input\InputArgument;

class Version extends Command
{

 /**
 * The console command name.
 *
 * @var string
 */
 protected $name = 'version:update';

 /**
 * The console command description.
 *
 * @var string
 */
 protected $description = 'Update the version number in app/config/version.php';

 /**
 * Create a new command instance.
 *
 */
 public function __construct()
 {
     parent::__construct();
 }

 /**
 * Execute the console command.
 *
 * @return mixed
 */
 public function fire()
 {
     // get file containing current version information
     $versionFile = 'config/version.php';

     // get the argument passed in the git command
     $version = $this->argument('app_version');

     // discard the commit hash
     $version = explode('-', $version);
     $realVersion = $version[0] . '-' . $version[1];

     // save the version array to a variable
     $array = var_export(array('app_version' => $realVersion), true);

     // construct file content
     $content = <<<CON
<?php

return $array;
CON;

     \File::put($versionFile, $content);
     $this->line('Setting version: ' . $realVersion);
 }

 /**
 * Get the console command arguments.
 *
 * @return array
 */
 protected function getArguments()
 {
     return [
         ['app_version', InputArgument::REQUIRED, 'version number is required'],
     ];
 }

 /**
 * Get the console command options.
 *
 * @return array
 */
 protected function getOptions()
 {
     return [];
 }

}

I didn’t want the commit has to be part of the version, so I explode on the hyphen and only use the first two array elements (the git command formats it’s output like this: tag-#commits_from_tag-commit_hash)

Register the command in Kernel.php:

protected $commands = [
    'SalesMonkey\Console\Commands\Version',
];

Create an empty version.php file in config/.

Create a pre-commit hook in your local repository. It should look like this:

#!/bin/sh
php `pwd`/artisan version:update `git describe --tags`
git add config/version.php
echo "updated version"
exit 0

You can test your results by running:

$ pa version:update 1.0-4
Setting version: 1.0-4

Open up config/version.php and you should see version 1.0-4 as the app_version!

Homestead (written by Laravel)

Homestead is a pre-built Vagrant environment for PHP development (though it can be used for HTML5 and Javascript only apps as well).  It was made by the team that brought you Laravel, but it’s not limited to Laravel alone.  I’ve used it for Laravel, CakePHP and straight PHP applications.

Vagrant allows you to create lightweight, portable development environments.  It’s very powerful, and can use VirtualBox, VmWare Workstation, Digital Ocean, and AWS as the Virtual Machine (VM) engine.

Homestead comes with (as of this writing):

  • Ubuntu 14.04
  • PHP 5.5
  • Nginx
  • MySQL
  • Postgres
  • Node (With Bower, Grunt, and Gulp)
  • Redis
  • Memcached
  • Beanstalkd
  • Laravel Envoy
  • Fabric + HipChat Extension

The beauty of Vagrant is that you can add any other packages you want through provisioners.  You can use Puppet, Chef and even shell scripts to add/remove/upgrade software.

If you really want to isolate your development environment, this is the way to go.  For example, if you work in teams each developer can develop on a local Homestead box with the same software configuration.  If you’re managing your database changes with a migrations package, then each developer can make their own database changes independent of each other.  When a feature is ready for testing, then the person testing can fire up their Homestead environment and pull the latest changes.  They can run the migrations and begin testing.  Since the testing environment is identical to the development environment, issues found outside of code issues will be minimized.

If you want to demo a feature or software application, using Homestead would be a great way to do it.  Whoever is giving the demo can fire up Homestead, pull the latest production code and run the migrations.  The application will be at the same version as production.

And, you can run multiple applications in one instance of Homestead.  Simply add a new shared folder and Nginx site configuration to the Homestead.yaml file and update your hosts file!

I use Homestead for my own side projects and for small projects at work.  I highly recommend it as it has an extremely low barrier to entry, and is supported by the team that writes Laravel.  It was the easiest Vagrant solution I’ve used, I had no issues and it was up and ready to go in seconds.

 

Intro

Welcome.  My name is John Sposato Jr., and I will be using this site to discuss Software Development topics both known as well as things I will be learning.  I have over seven years experience in the field, and I have learned a lot over that time.  Topics will include design patterns, testing, agile, and whatever else I feel I want to share.  I hope you enjoy what I write about, and if you feel I’ve got something wrong, please comment and let me know.

 

About Me