Author: Eugeniy Marilev
Date of publication: 2014-05-07 10:21:47

The article is dedicated to the system that we have invented for a deployment of our projects. We prefer GIT, so the deployment process is shown in the context of this VCS.

Deployment system consists of the several interrelated parts:

  1. Main repository.
  2. Local environment – developers’ working station.
  3. Staging environment - an intermediate environment needed for testing fresh (latest) version.
  4. Preproduction environment – a copy of a production environment, that has the same files, settings and database structure.
  5. Production environment – a stable version of a project that is available to the end users.

It’s epic to apply a new version!

Applying to Stage:

  1. Get the latest version from the repository: git pull origin master.
  2. Refresh dependencies: git submodule sync && git submodule update —init —recursive.
  3. Apply magrations.
  4. Clear the cache and the assets.
  5. Some other stuff to do that depend on the project complexity.

Applying to PreProduction:

  1. Tag stable version, for example v-1.0.0
  2. git fetch и git checkout v-1.0.0
  3. The next steps are the same as for Stage environment.

Applying to Production:

The steps are similar to PreProduction...

There are some cases that make a deployment process more complicated:

  1. What if a production environment requires more than one server?
  2. What if something goes wrong when a new version is applied? In this case we must find out the reason why one of the environments doesn’t work properly and repeat all the process from the very beginning.
  3. Updating the environments to a new version demands an attention, because if an error occurs, there must be done the rollback to the latest stable version.

Besides, each of this cases may take a lot of time and demands an access with ssh. That’s why we decided to develop a new console command named DeployCommand...

DeployCommand or how to spare some time

You should include a configuration of the delivery command into main application config file. Than, command will be available from linux shell:

protected/yiic deploy pull
protected/yiic deploy upgrade
  • deploy pull – gets the version from the main repository and synchronizes dependencies (modules).
  • deploy upgrade – does the rest.

Therefore we have reduced the deployment process to the two simple console commands.

On a staging environment we add to the cron the following call:

*/15 * * * * cd /var/www/ && protected/yiic deploy pull && protected/yiic deploy upgrade

It gets the latest version of a project every 15 minutes if there is an exception it sends a fail message to your email.

Another command is used to update source code on the production:

deploy fetchAndSwitch --branch=<branch_name>

Maybe we could make a service out of this system?

Really, what if an application could update itself? The principle of the auto updating is described below.

  • An application asks service for a new version once in awhile. Service looks trough the versions of the application, and if it finds one with a status “new” it sends a tag of the commit to the app.
  • The application executes deploy fetchAndSwitch —branch=<branch_name>, deploy upgrade
  • If new version is applied successfully, the application tells service to mark this version with "done".
  • If something goes wrong, the error message is sent to the server and the version is marked with “failed”. In this case source files are reverted to the previous version.

It would be bad if someone could break a system accidentally or not, so we’ve paid attention to the security issues.

  • An application has a unique key, a name and a list of host servers.
  • Only attached users or creators of the project have an access to it.

That’s why an action auto appears in DeployCommand.

Now a stable upgrade goes really easy

The following console command is added into cron on every server, where an application is deployed:

*/5 * * * * cd /var/www/ && protected/yiic deploy auto —key=<app_key_in_deploy_api>

It will check for a new version every 5 minutes and will make an upgrade if it’s needed.

Now the steps of an upgrading to a new stable version are:

  1. Create stable version (tag) at the repository.
  2. Add a new version for the preproduction in the admin part of a deploy-service.
  3. If everything goes right, create a new version for the production environment. Besides, it’s very easy to maintain distributed web applications on the mirror services.

That’s all. The application will be updated.


The evident advantages of the system are:

  1. It’s simple to apply local version, therefore it saves time.
  2. There is an intermediate deployment environment similar to the production.
  3. Sending of the error notifications.
  4. Built-in emergency rollback to the latest stable version

The downsides are:

  1. A php error can occur within the deployment subsystem, so the deploying engine will stop working. In this case you must update the application manually.
  2. For the first time it takes a while for a developer to understand the integration of the deployment system.
Article comments
No results found.
Only logged users can leave comments.