Last week we supported GitLab as a first-class citizen in Moss. If you host your application code in GitLab.com repositories, you can now enjoy all Moss features that previously were only available for GitHub and Bitbucket. As in the latter cases, you just have to authorize Moss to access your GitLab account and it’ll be able to deploy your GitLab-hosted repos.

In this way you can trigger automatic deployments after pushing your code, or deploy manually with just one click. In either case, your websites will benefit from a zero-downtime process. Want to know the details? Please keep reading 😀

Push to deploy

Whenever you push your code to a given git branch or tag of your choice, Moss will deploy your website (if you want). Basically, Moss registers a webhook in GitLab.com to get notified as soon as you push into your repository. Then Moss determines the website(s) that are affected and triggers the required deployment processes.

A single git push might involve multiple deployments. E.g. if you have different websites using the same git repo and branch/tag. Also if you launch multiple instances of your website behind a load balancer. In these cases, your websites will be deployed concurrently.

You may enable this feature in Moss at any time by checking the “Push to deploy” box at the corresponding site.

Zero-downtime deployments

Regardless you deploy your website automatically or by using Moss’s “deploy” button, you’ll always benefit from zero-downtime (aka atomic) deployments.

Moss clones your git repo on a new folder of your server. Then it runs the pre-activation script required to build your application. Moss suggests an appropriate script for the PHP frameworks it supports natively, but you can (should!) adapt it to the needs of your application. Usually, such script updates the application’s dependencies and runs database migrations (if any). Here you can see an example  for a typical Laravel app:

composer install --prefer-dist --no-dev --no-interaction
php artisan migrate --force

Once the pre-activation script ends, Moss activates the new release. This means that your web server(s) – Nginx standalone or with Apache – start serving your new release that was hold apart on a different folder. This is done by updating a symlink on the server, hence the “atomic” adjective for these kinds of deployments.

The process described so far has two main advantages:

• Your website won’t have any downtime if your deployment fails, since your current release has been served continuously. Moss will send you a notification to let you know about the error.
• Your website shouldn’t have any downtime if your deployments succeeds, since Moss runs the heavy processes before activating the new release.

In some cases, you need to run some command(s) after your release activates. Following the example of a Laravel application, you have to restart the workers it uses (if any) after activating the new release. In Moss you can do that by providing a post-activation script like the one below:

php artisan queue:restart

You don’t have to do anything to enable zero-downtime deployments in Moss. Just choose your git repo when you create your website in Moss, and review the pre-activation and post-activation scripts to check if they fit your application.

Conclusion

Moss has supported zero-downtime and automatic deployments since the beginning. However, the latter was only available for code repositories hosted on GitHub or Bitbucket. Until now. Moss integrates with GitLab.com too to offer the same server and website management capabilities to GitLab users.

Want to give it a try? Log in or sign up to check our GitLab integration (among others). Your feedback is always welcome!