Deployment

Page last updated on April 10, 2018

Writing code and releasing new versions is fun.  It is even more fun when somebody uses your software.  In order for people to use your software, you need to deploy it.  In this section we’ll talk about the deployment process for Qobrix applications.  But before we do that, let’s refresh your memory on a couple of subjects – System Requirements and Qobrix Installation on the development environment.

Preparation

We’ll assume here that you already have access to:

  • configured server environment,
  • git repository with all the source files,
  • network, for downloading all the requirements.

Here are a few things to do, when you are preparing for the deployment of the new version to test, staging, production or other environment:

  1. Pick the version that you will deploy.
  2. Pick the time to deploy.  Some versions can take only a few seconds to deploy, while others might require hours (large database migrations, for example).  You might want to avoid end of day or week deployments.  Or, on the contrary, you might prefer those.
  3. Communicate the intent to the rest of the project team.  Example: “I am about to deploy vX.Y.Z to the FOO environment of the ABC project“.  Give people a few moments to respond.  You might also need to notify people outside of the project team, like the actual application users, or management, or somebody else.
  4. Cover your … back.  Make sure that either you have all sufficient access and knowledge to fix any  potential issues, or the appropriate people are available.  Just in case things go wrong.

Deployment Actions

When we talk about deployments, we usually have only one of the following three deployment actions in mind:

  1. app:install.  You only need this once.  Installation deployment performs an initial setup of the application on the new environment.
  2. app:update.  This is the most frequent one.  During the lifetime of the application on a particular environment, you perform update deployments to bring new features, improvements, and patches.
  3. app:remove.  Much like the install, you only need this once.  When you want to remove the Qobrix application from a particular environment, you run a removal deployment.

But … but … how do I rollback?“, we hear you ask.  It’s true, many deployment processes include a rollback action, which reverts the application to some previous version.  We have thought long and hard on this subject and decided to not provide rollback functionality.  It’s difficult, unreliable, and, simply put, is not worth it in our case.  When you do need to rollback, you simply deploy an update to a previous version (and hope that works).  In all the time we built and deployed Qobrix applications, we only needed a rollback once.  Maybe twice.  And we survived without it.  Our preferred approach is to simply deploy the next version.  And the next.  And the next.  Repeat, until the problem is solved.  If all went south completely, restore from backup.  You DO have a backup, right? Anyways.  Here are the steps to perform each one of the above deployment actions.  Once again, we only show you the basics.  You can integrate the deployment process with your tool chain (we are big fans of ChatOps, via HipChat).

app:install

Deploying the Qobrix application to the server for the first time is almost as easy as installing it on the development environment.  Have a look at this example session (we removed the output as it’s quite verbose and not really needed for now):

# Login into the server
ssh user@web.server
# Navigate to the web server root folder
cd /var/www/vhosts

# Clone the repository (adjust the URL)
git clone git@bitbucket.org:QoboLtd/example.com.git
# Navigate into the project (adjust the directory name)
cd example.com
# Checkout tag (adjust to version you are deploying)
git checkout --force vX.Y.Z
# Provision the .env file (adjust as necessary)
cp ~/projects/configs/env.live .env
# Install composer dependencies
./bin/composer install --no-dev --no-interaction --no-progress --optimize-autoloader
# Setup the application
./bin/build app:install

# Restart the web server (adjust as necessary)
sudo sh -c "nginx -t && service nginx reload"
# Logout from the server
exit

app:update

After installing the application, you’ll want to run updates.  This is a frequent operation and it’s even easier than the installation.  Here are the example commands:

# Login into the server
ssh user@web.server
# Navigate to the web server root folder
cd /var/www/vhosts

# Navigate into the project (adjust the directory name)
cd example.com
# Fetch source code updates
git fetch --all
# Checkout tag (adjust to version you are deploying)
git checkout --force vX.Y.Z
# Install composer dependencies
./bin/composer install --no-dev --no-interaction --no-progress --optimize-autoloader
# Update the application
./bin/build app:update

# Restart the web server (adjust as necessary)
sudo sh -c "nginx -t && service nginx reload"
# Logout from the server
exit

app:remove

Removing the Qobrix application from a given environment is the simplest of all the deployment actions.  Here’s what you need to do:

# Login into the server
ssh user@web.server
# Navigate to the web server root folder
cd /var/www/vhosts

# Navigate into the project (adjust the directory name)
cd example.com
# Remove the application setup
./bin/build app:remove

# Navigate out of the project folder
cd ..
# Remove the application (adjust the directory name)
rm -rf example.com
# Restart the web server (adjust as necessary)
sudo sh -c "nginx -t && service nginx reload"
# Logout from the server
exit

Final Touch

You don’t really have anything else to do after the deployment, except for notifying the rest of the project team. That is if you haven’t configured automated deployment notifications.   Keep in mind that project updates usually affect people outside of the technical team (application users, for example).  So, it’s a good idea to notify them with some less- or non-technical message as well, providing some description of the deployed changes.