During the preparation I've read a few articles and discussions on this topic. And I thought everything will be easy, but I ran into some minor issues.

FromMySqlToPostgreSql

I've started at Converting from other Databases to PostgreSQL and found out about AnatolyUss/FromMySqlToPostgreSql. I was surprised how easy everything went with this package, but just temporary, until I found issues with double single quotes in Postgres DB.

Schema was converted properly, including FKs and indexes, I'm not sure about sequences (auto increments). But I had issues with double single quotes. For example I had something like this in MySQL It's, and after conversion I ended up with It''s in PostgreSQL.

Configuration is so simple, you just populate provided example XML or JSON configuration file. After that you can execute PHP script with reference to one of those files, and you end up with data in new DB.

I'm pretty sure this will be solved, because package is under development, and I see some new commits are there. So I'm almost sure you should try this package if you decide to do migration.

mysql-postgresql-converter and few more steps

Secondly I went with more manual work, but I got everything in place.

• First of all I ran migrations to create tables in new DB, because I already had DB migrations files in project.
• Then I used mysqldump without create statements as starting point:

mysqldump --compatible=postgresql --default-character-set=utf8 --no-create-info -r dumpfile.sql -uroot yourdb

• After that I used lanyrd/mysql-postgresql-converter to convert insert statements to correct format:

python ~/Desktop/mysql-postgresql-converter/db_converter.py dumpfile.sql dumpfile.psql

• Next step was text editor, and reorganisation of inserts to avoid FK exceptions, you have to do this on your own...
• At first I thought this would be the last step. So execute your SQL against new db:

psql -d newdb < dumpfile.psql

• After that I found out I had issues with 'AUTO INCREMENTS' or sequences in Postgre. I wasn't able to execute new insert because of this. A few hours later, after some digging I found this is expected issue, and it's covered in PostgreSQL wiki Fixing Sequences.
  So you have to execute some query that will return a list of queries for fixing sequences:
  

SELECT 'SELECT SETVAL(' ||
       quoteliteral(quoteident(PGT.schemaname) || '.' || quote_ident(S.relname)) ||
       ', COALESCE(MAX(' ||quote_ident(C.attname)|| '), 1) ) FROM ' ||
       quoteident(PGT.schemaname)|| '.'||quoteident(T.relname)|| ';'
FROM pg_class AS S,
     pg_depend AS D,
     pg_class AS T,
     pg_attribute AS C,
     pg_tables AS PGT
WHERE S.relkind = 'S'
    AND S.oid = D.objid
    AND D.refobjid = T.oid
    AND D.refobjid = C.attrelid
    AND D.refobjsubid = C.attnum
    AND T.relname = PGT.tablename;

You end up with something like this:

SELECT SETVAL('public.tablenameidseq', COALESCE(MAX(id), 1) ) FROM tablename;

Conclusion

Based on some articles I've read I expected noticeable performance difference, but 9.5 is pretty close to MySQL 5.7. It was harder than expected, but I'm happy I did it. Because Postgre expects correct types I've found out immediately I've had some errors in my validators. And most important it was fun, and I learned something new!

You can consider building git deploy solution with git hooks and scripts on your server or you can go with something Ruby developers do for a while, execute a bunch of commands over ssh.

As someone who is developing in Ruby I'm in contact with capistrano pretty much every day, and I must admit it's great tool for deploying your code to live servers.

Deployer is exact match written in PHP. I discovered it few months ago, and finally tested it, and I'm happy to share some thoughts.

It's absolutely possible to use capistrano for deploying PHP project, because tool actually runs on your local machine, and execute shell commands over ssh on the server. But it is interesting to have deployment configuration in same language as project, it has less dependencies in development environment.

First thing I noticed is syntax that recalls Capistrano 2.x memories. For example running deploy task on servers marked as production:

capistrano 2.x cli command:

cap deploy production

capistrano 3.x cli command:

cap production deploy

deployer cli command:

dep deploy production

Other than that, everything else is similar too. So dep expects deploy.php file in current working directory, and it will use that file for configuration.

Keep in mind your server must have all dependencies for running specified tasks, e.g. git for fetching code from the repo.

Installation

Install globally and use it anywhere:

curl -sO http://gordalina.github.io/cachetool/downloads/cachetool.phar
mv deployer.phar /usr/local/bin/dep
chmod +x /usr/local/bin/dep

Or install it as a project's dependencie:

composer require deployer/deployer:^3.0

This way you can even put it in "require-dev" block and get functions recognized by your IDE or editor of choice, and avoid installing it on live servers too.

Configuration

Consult official documentation and discover how to define variables and use existing recipes.

This is configuration I've used during this test:

<?php
require 'recipe/laravel.php';
set('repository', 'git@example.com:user/repo.git');
set('http_user', 'deploy');server('production', '127.0.0.1')
    ->user('deploy')
    ->env('deploy_path', '/home/deploy/apps/djordjekovacevic.com')
    ->identityFile()
    ->stage('production')
    ->forwardAgent();

So I pulled existing recipes for laravel, which will do those things for you:

• create directories structure
• pull latest code from your git repo
• pull composer
• install dependencies
• symlink storage/ and .env from shared/ dir
• symlink current to release dir if everything went well

By default deployer will deploy mater branch, but you can override that with optional param tag:

dep deploy production --tag=my-test-branch

I used my ssh key to identify myself instead of password, and I also forwarded my identity agent to enable pulling from my git repo with same key instead of having one more key sitting on the server. Keep in mind that this setup require correct configuration of ssh agent on your server, your public key inside .ssh/authorization_keys file on the server and your git repo inside .ssh/known_hosts file.

Reset you OPcache after deploy

I used PHP-FPM 7, and by default it has Zend OPcache enabled. So after deployment you have to reset cache, or you won't be able to see changes for a while!

There are two possibilities, reloading FPM process (this operation require sudoing), or running reset via PHP. I've chose second, because I have correct privileges to execute that code without sudo.

I did it with gordalina/cachetool package. You install it on the server and create additional task that looks like this:

task('opcache:reset', function () {
    run('php cachetool.phar opcache:reset --fcgi=/run/php/php7.0-fpm.sock');
});
after('deploy', 'opcache:reset');

I mean it's so fun for me, I'll consider VPS instead of PaaS solutions :)

It's been a while since I've blogged last time. In meantime I've upgraded styling of my blog.

Mainly because previous styles wasn't mobile friendly.

This is just a reminder for me how it looked before this upgrade.

I had a lot of ideas, but not enough time to realize all of them.

So I decided to go with small subset in first round, and achieve better readability on small devices.

I hope this article will get follow up. With further improvements.

Original look:

New look on desktop:

New look on mobile:

I want PHP 5.6+, so I did some basic testing of those services to pick cheep and good solution to host my blog.
OpenShift because I use it and it's free for 3 small gears, it was pretty good solution few years ago.
Heroku because I used it for Ruby on Rails projects and they support multiple languages (even multiple build packs for one project)!
I used FortRabbit too, so I decided to test theirs new apps.

I used basic Laravel 5.2 with tree routes for this test:

• / - Default route that ships with Laravel installation
• /test - Hits method on TestController, pass one var to view and render it
• /info - This route call phpinfo()

TL;DR

Just compare FortRabbit's and Heroku's features and prices and chose one of them.
I prefer Heroku, but it was easier to transfer to FortRabbit because of MySQL support.
You know what, I'll probably continue further research and probably transfer to Heroku or something else (eg. Digital Ocean VPS and deploy with Deployer). Right now FortRabbit is much better solution than OpenShift, step in right direction :)

OpenShift PHP 5.4 and Laravel 5.0 (current setup) vs FortRabbit PHP 5.6 and Laravel 5.2 (future setup)

• OpenShift PHP 5.4 and Laravel 5.0 + CloudFlare
• FortRabbit PHP 5.6 and Laravel 5.2
• FortRabbit PHP 5.6 and Laravel 5.2 + CloudFlare

OpenShift

"There ain't no such thing as a free lunch"

I'm not sure about paid version but they simply don't maintain their service. It's all about OpenShift v3 these days... But it's free, so I decided to give it a try and benchmark this setup against other opponents.

pros:

• Free for 3 small gears
• MySQL 5.5 with 1GB of storage (use 1 of your 3 gears)
• Don't require any payment information for free plan
• Simple cronjob support via predefined file structure

cons:

• Idles after 24 hours
• First request after idle almost always fails
• You have to use 3rd party cartridges for beyond outdated default cartridges

Results (Nginx & PHP 5.6.16 @ free OpenShift - 3 gears scaled):

Complete results files:

• OpenShift n100 c5 /
• OpenShift n1000 c10 /
• OpenShift n100 c5 /test
• OpenShift n1000 c10 /test
• OpenShift n100 c5 /info
• OpenShift n1000 c10 /info

Heroku

If you ever worked with Rails you probably have some experience with Heroku. It's probably first service with git deploy I used.
They provide support for multiple languages, and even Apache or nginx servers for PHP. By default Heroku setups your app to use PHP 7, but you can specify desired version in composer.json and they will use that version. Also you have to setup default build pack manually or Heroku may make wrong assumption because of package.json. You have control over your services trough Procfile to set web or worker or anything else.
Main issue when transferring live project is eventual migration from MySQL to PostgreSQL if you want to stick with Heroku's default stack.

pros:

• Up to date stack
• Support multiple languages
• You can use multiple build packs (eg. PHP and Node.js)
• PostgreSQL support
• GUI for ENV var
• Support cron jobs via add ons
• Fair pricing for smaller project, starts at $9

cons:

• Don't support MySQL by default (you have to use 3rd party add-ons)
• Free plan idles after 30 minutes
• Free plan must idle at least 6 hours per day
• For custom domain setup you have to provide payment information, even for free plan (and custom domain is free feature)

Results (Apache & PHP 7.0.1 @ free Heroku):

Complete results files:

• Heroku n100 c5 /
• Heroku n1000 c10 /
• Heroku n100 c5 /test
• Heroku n1000 c10 /test
• Heroku n100 c5 /info
• Heroku n1000 c10 /info

FortRabbit

This is PHP exclusive stack, with git deploy and it's pretty good one. New apps are great, but they lacks some features too.

2016-01-22 Update:
FortRabbit support workers for new apps now.

pros:

• Up to date stack
• MySQL support
• GUI for managing PHP ini and PHP version
• GUI for ENV var
• Fair pricing for smaller projects, starts at 7€ (5€ app server + 2€ MySQL)

cons:

• Don't provide free plan, so you have to pay even for testing
• Currently don't support cron jobs, or workers, it's in development for new apps, but you can check one of the links here
• No SSH access, so you cant run artisan commands

Results (Apache & PHP 5.6 @ 7€ instance):

Complete results files:

• FortRabbit n100 c5 /
• FortRabbit n1000 c10 /
• FortRabbit n100 c5 /test
• FortRabbit n1000 c10 /test
• FortRabbit n100 c5 /info
• FortRabbit n1000 c10 /info

Complete results on same instance with PHP 7.0:

• FortRabbit n100 c5 /
• FortRabbit n1000 c10 /
• FortRabbit n100 c5 /test
• FortRabbit n1000 c10 /test
• FortRabbit n100 c5 /info
• FortRabbit n1000 c10 /info

Complete results on same 35€ instance with PHP 7.0:

• FortRabbit n100 c5 /
• FortRabbit n1000 c10 /
• FortRabbit n100 c5 /test
• FortRabbit n1000 c10 /test
• FortRabbit n100 c5 /info
• FortRabbit n1000 c10 /info

First of all I want to have my git history in place for each file.
This leads me to the slightly different approach during migration than official upgrade guide suggest.

Official upgrade guide is safest way to migrate your project, but you can try to adjust it and preserve history.
This will be pretty complicated if your project is big, not structured correctly (eg. you haven't namespaces your domain logic, helpers...), not documented or not tested.

I did this on my blog as a proof of concept.
I thought it will be quick task, but it took more time than expected.

Before we dive, this was status at beginning:

• + Project is relatively small
• + A lot of project has been namespaced
• + I'm the only one who worked on this, so even undocumented parts are known to me
• - Pretty small percentage is covered with tests

Prepare for migration

It is good idea to have dump of your project extracted for reference, before you start migration. And one fresh copy of Laravel 5 as a reference where to move files, what to add/remove/update.

Desktop is great place for WiP files, or you can put it somewhere else.

mkdir ~/Desktop/laravel-migration && cd $_

Prepare fresh copy of Laravel 5:

composer create-project laravel/laravel laravel5 "~5.0.0"

Chose your prefered technique to export copy of your project. Just aim to have it in ~/Desktop/laravel-migration/my_project.

Create new git branch where you'll commit everything related to migration, eg. feature/laravel-5.0.

You should use IDE/editor with git support and move files that way, or use git mv via terminal. This ensures git knows how to track history for your files.

At this point I have my project open in IDE and ~/Desktop/laravel-migration/laravel5 open in editor for references. At any point I can open ~/Desktop/laravel-migration/my_project and check old version withoud switching git HEAD from my upgrade branch.

Open official upgrade guide, you will need it for for additional details (eg. changed API of some classes, changed namespaces).

The easiest thing to migrate is namespaced code from old project if you had it, eg. app/Acme. You can just continue to use it, and internally fix dependencies namespaces, eg. Eloquent models.

Move files and dirs to new location

• app/config/ -> config/
• app/database/ -> database/
• app/tests/ -> tests/
• app/models/ -> app/ (you should namespace your models, and update namespaces in relations or load classmap, consult official update guide)
• app/controllers/ -> app/Http/Controllers/ (and update namespaces or load classmap)
• app/assets/ -> resources/assets/ (if you stored your assets within app dir)
• app/lang/ -> resources/lang/
• app/views/ -> resources/views/
• app/commands/ -> app/Console/Commands (don't worry about namespaces yet, fix them latter)
• app/routes.php -> app/Http/routes.php
• app/start/*.php to new places (explained in Laravel's documentation) and remove dir

Copy from fresh Laravel 5 project

• .env
• .env.example
• artisan
• phpunit.xml
• phpspec.yml
• server.php
• app/Console
• app/Commands
• app/Events
• app/Handlers
• app/Http
• app/Providers
• app/Services
• bootstrap/app.php
• bootstrap/autoload.php
• config/compile.php
• config/filesystems.php
• config/session.php
• config/view.php
• database/seeds/DatabaseSeeder.php (and import your seeder calls if you used it)
• public/index.php
• resources/lang/en/passwords.php
• resources/lang/en/validation.php (merge your messages if you edited this file in your project)
• storage/

Remove files and dirs

• app/storage/
• vendor/
• composer.lock
• config/remote.php
• config/workbench.php
• config/*/ - Environment specific configurations are not supported anymore (you should extract those to ENV variables)
• database/production.sqlite - If you don't use SQLite in production
• bootstrap/paths.php
• bootstrap/start.php

Update .gitignore

• Remove composer.lock

• Remove .env.*.php

• Remove .env.php

• Add .env

• Copy database/.gitignore from Laravel 5

Update composer.json

• Remove unnecessary dev dependencies from composer.json to avoid migration problems, and bring them back latter if required!

• Upgrade your composer.json based on one generated in new Laravel 5 project, most important parts:

  "require": {
    "laravel/framework": "5.0.*"
  },
  "autoload": {
    "classmap": [
      "database"
    ],
    "psr-4": {
      "App\\": "app/"
    }
  },
  "autoload-dev": {
    "classmap": [
      "tests/TestCase.php"
    ]
  }
  

Check if you need to update those files

• config/app.php - use old "key" value as fallback option, eg. env('APP_KEY', 'oldKeyValue')
• config/auth.php
• config/cache.php
• config/database.php - keep in mind you might need 'port' configuration for MySQL DBs
• config/mail.php
• config/queue.php
• If you used laracasts/validation package replace it with Laravel's form request
• If you have anything important in BaseController class move it to App\Http\Controllers\Controller class
• If you used Illuminate\Pagination\Paginator class you should probably migrate it to Illuminate\Pagination\LengthAwarePaginator class (follow the official guide for migrating method calls)

So you have some kind of responsive CSS grid in place, let's say Bootstrap's, and you need to create inner elements with same height as container width.
Something like this:

<div class="row">
  <div class="col-sm-3">
    <!-- Element with same height as parent's width -->
  </div>
</div>

I've had this problem few years ago, and Marko Dumić
helped me with pure CSS solution. Since then I copy/paste this snippet to various projects.

// Usage example:
// div.col-sm-3
//   div.square-size-by-width
//     div.square-size-element
//       img
.square-size-by-width {
  position: relative;
  width: 100%;
  padding-bottom: 100%;

  .square-size-element {
    position: absolute;
    width: 100%;
    height: 100%;
    overflow: hidden;
  }
}

Here is HTML markup from teaser with inner markup:

<div class="row">
  <div class="col-sm-3">
    <div class="square-size-by-width">
	    <div class="square-size-element">
	    </div
    </div
  </div>
</div>

This ensures elements inside your grid will scale with grid and maintain proportions!

You want to modernize your assets compilation before you switch to Laravel 5?
Elixir is great tool on top of Gulp, and you can use it for anything with little configuration. Here is my setup for Laravel 4.2 which can be easily adapted to any other framework.

Setup node, npm, global and local dependencies, Bower and Gulpfile

1. Ensure you have node and npm on your development machine.
2. Install Gulp globally: npm install gulp -g.
3. Run npm init to prepare package.json file.
4. Install laravel-elixir with npm install laravel-elixir --save to preserve that dependencies in your package.

• If you want you can install bower for managing front end dependencies:

• Run npm install bower --save

• Create .bowerrc file and set destination for bower components, eg.:

  {
  	"directory": "app/assets/vendor"
  }
  

  • Run node_modeules/.bin/bower init to create bower.json with desired configuration
  • Now you can install frontend dependencies, eg.: node_modules/.bin/bowewr install angular --save

5. Create elixir.json file and set root assets and public paths. Something like this:

   {
     "assetsPath": "app/assets",
     "publicPath": "public/assets"
   }
   

6. Create gulpfile.js and add initial configuration (I don't want source maps in production):

   var elixir = require('laravel-elixir');
   var config = require('laravel-elixir').config;
   
   var bowerDir = 'app/assets/vendor/';
   var jsOutput = 'public/assets/js';
   var cssOutput = 'public/assets/css';
   var jsAssets = 'app/assets/js';
   
   config.sourcemaps = !config.production;
   
   // Example compile setup:
   
   elixir(function (mix) {
   	// MAIN STYLES
       mix
           // MAIN STYLES
           .sass('main.scss')
           
           // VENDOR STYLES
           .styles([
               'normalize.css/normalize.css',
           ], cssOutput + '/vendor.css', bowerDir)
   	;
   });	
   

7. Now you can run gulp tasks from your project, eg.:

• gulp - compile assets
• gulp --production - compile production assets (minified and without sourcemaps)
• gulp watch - Compile assets every time some source file is changed

Add elixir helper function from Laravel 5, or use custom functions for loading styles and scripts

To achieve functionality form Laravel 5 you should copy elixir helper function to some file loaded by composer, eg. app/helpers.php and load that in composer.json.

if ( ! function_exists('elixir'))
{
	/**
	 * Get the path to a versioned Elixir file.
	 *
	 * @param  string  $file
	 * @return string
	 */
	function elixir($file)
	{
		static $manifest = null;
		if (is_null($manifest))
		{
			$manifest = json_decode(file_get_contents(public_path().'/build/rev-manifest.json'), true);
		}
		if (isset($manifest[$file]))
		{
			return '/build/'.$manifest[$file];
		}
		throw new InvalidArgumentException("File {$file} not defined in asset manifest.");
	}
}

If you don't plan to use elixir's version task for versioning assets you can add something like this, and relay on appended timestamp in query string (like Rails 3). Just keep in mind that Laravel 5 doesn't come with HTML helpers, so this won't work after update. You'll have to switch it to something like this:

• HTML::style($path.'?'.File::lastModified($file))
'<link href="'.$path.'?'.File::lastModified($file).'" rel="stylesheet" type="text/css" />'
• HTML::script($path.'?'.File::lastModified($file))
'<script src="'.$path.'?'.File::lastModified($file).'" type="application/javascript"></script>'

if ( ! function_exists('stylesheet_tag'))
{
	/**
	 * Create path from stylesheet's name
	 * Append last modification date as query string
	 *
	 * @param string $name
	 * @return string
	 */
	function stylesheet_tag($name)
	{
		$path = "assets/css/{$name}.css";
		$file = public_path($path);

		if (File::exists($file))
		{
			return HTML::style($path.'?'.File::lastModified($file));
		}
	}
}

if ( ! function_exists('javascript_tag'))
{
	/**
	 * Create path from javascripts's name
	 * Append last modification date as query string
	 *
	 * @param string $name
	 * @return string
	 */
	function javascript_tag($name)
	{
		$path = "assets/js/{$name}.js";
		$file = public_path($path);

		if (File::exists($file))
		{
			return HTML::script($path.'?'.File::lastModified($file));
		}
	}
}

Assets compilation

I prefer to compile assets locally instead on remote machine during deployment.

You can adapt to anything you like. If you compile locally just run gulp --production before committing and pushing assets to remote.

Otherwise you can use .gitignore to avoid committing compiled assets completely and register deploy hook to run same command on server, just keep in mind this will require configured node on your server!

You can't run Laravel 5.1 on OpenShift by default, because it requires PHP >= 5.5.9, and OpenShift provides just PHP 5.4 support.

So if you want to run small presentation or test your app for free, using OpenShift Free Plan, you have to do a lot of preparation by yourself!

Just keep in mind that free plans have 24h idling, which means your application will respond pretty slow if not accessed in previous 24h, because OpenShift will idle those gears.

One more thing to keep in mind! OpenShift gears don't share storage. So if you chose scaling you have to store assets (not versioned) externally, eg. images.

Thanks to Warnar Boekkooi who provided nginx and PHP cartridges we can create proper environment for Laravel 5.1. Required cartridges source code is located on GitHub:

• Openshift Nginx Cartridge
• Openshift PHP Plugin Cartridge

You should check those pages details and supported configurations. You can follow steps there for setup via command line, or continue and do it via OpenShift web console.

OpenShift application creation steps

1. Go to OpenShift's create application page: https://openshift.redhat.com/app/console/application_types.
2. Scroll to the bottom and find in the left corner "Code Anything" title with input field bellow.
3. Paste URL of nginx cartridge http://cartreflect-claytondev.rhcloud.com/github/boekkooi/openshift-cartridge-nginx, then hit next button.
4. Populate Public URL field.
5. Chose Scaling if you want.
6. Hit "Create Application" button and wait for OpenShift to build your environment.
7. Copy application git repo link and continue to the application overview page.

Add PHP cartridge to your application

1. Find on the bottom of the application overview page "see the list of cartridges you can add" link and click on it.
2. Scroll to the bottom of the page and find "Install your own cartridge" title with input field bellow.
3. Paste URL for PHP cartridge http://cartreflect-claytondev.rhcloud.com/github/boekkooi/openshift-cartridge-php, then hit next button.
4. On next page check details and hit "Add Cartridge" button and wait for OpenShift to update your environment.

Additional cartridges

If you need anything else like DB for example use existing OpenShift cartridges (MySQL, PostgreSQL).

Prepare for Laravel 5.1

1. Clone application repo localy
2. Go to repo's root

Prepare Laravel project

1. Run composer create-project laravel/laravel --prefer-dist, and this will create project in laravel subdir. You are not able to create project in non empty dir!
2. Go to file manager and move all files from laravel subdir one step up, then remove laravel dir.
3. Check config/app.php line 81 for APP_KEY!
4. Commit changes!

Update NGINX configuration to enable pretty URLs

1. Open .openshift/nginx.conf.erb in some text editor (eg. Atom)

2. Find server block, starting at line 29 and replace it with:

   server {
       listen  <%= ENV['OPENSHIFT_NGINX_IP'] %>:<%= ENV['OPENSHIFT_NGINX_PORT'] %>;
       root    <%= ENV['OPENSHIFT_REPO_DIR'] %>/public;
   
       index index.html index.htm index.php;
       charset utf-8;
   
       location / {
           try_files \$uri \$uri/ /index.php?\$query_string;
       }
       location = /favicon.ico { access_log off; log_not_found off; }
       location = /robots.txt  { access_log off; log_not_found off; }
   
       location ~ \.php$ {
         fastcgi_split_path_info ^(.+\.php)(/.+)$;
         fastcgi_pass unix:<%= ENV['OPENSHIFT_PHP_SOCKET'] %>;
         fastcgi_index index.php;
         fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
         fastcgi_param PATH_INFO $fastcgi_script_name;
         include <%= ENV['OPENSHIFT_NGINX_DIR'] %>/usr/nginx-<%= ENV['OPENSHIFT_NGINX_VERSION'] %>/conf/fastcgi_params;
       }
   
       location ~ /\.ht {
           deny all;
       }
   }
   

3. Commit changes!

Add composer support

1. Create file .openshift/action_hooks/deploy.

2. Give it executable permissions: chmod +x .openshift/action_hooks/deploy.

3. Paste this content to file:

   #!/bin/bash
   # .openshift/action_hooks/deploy
   
   ( cd $OPENSHIFT_REPO_DIR ; composer install --no-interaction --no-dev )
   

4. Commit changes!

Deploy to OpenShift

Assuming your origin is OpenShift and you want to push local master to remote master run git push.

You should see detailed response from OpenShift about stoping PHP and NGINX, than installing all your dependencies.

Now go to public URL for your app and you should see Laravel 5 default page!