Documentation

Didn't know where to start? Here we have something might be useful.

Overview

Overview

Please take note that once you convert your Web Application to use Atomic GIT deployment, there is no way to downgrade back to using standard GIT deployment without deleting the deployment folders.

If you are using RunCloud powered GIT deployment, you may notice some web application downtime when your deployment runs composer install or npm to build your assets (js and css).

For large sites with thousands of users accessing them concurrently, this will result in a poor user experience that is widespread. Many users will experience your website downtime when all you are doing is upgrading it to a new codebase.

This is where Atomic GIT deployment provides an optimal solution. When you do a GIT push, your website will be built in the background. All the composer install and npm build processes will run inside a separate folder without touching the site that is currently being served. But when the build process is done, it will atomically switch your site to the new codebase without needing any downtime, and provide a seamless experience for your users.

Parallel Deployment

When you use Atomic GIT Deployment, you can control multiple Web Applications with the same GIT repository. All deployment will be running at the same time inside every Web Application. Horizontal scaling of your site is no longer a problem when two or more sites on different servers can be built together at the same time. Now all you have to worry about is how to share uploaded files across your network. *Hint* GlusterFS, shared storage and, as a last resort, Amazon S3.

Deployment Tasks

The build process is divided into three tasks, cloning a new release, installing Composer dependencies and activating the latest release. The build process will be run by task even though you have multiple Web Applications. Thus, it will wait for every Web Applications to complete it’s current task before continuing to the next deployment task.

If your deployment hits an error, the build process will stop and cleanup by itself. Your website will not change to a problematic deployment, thus maintaining the uptime of your site and ensuring a seamless user experience. For parallel Web Application deployment, if one Web Application causes an error, every Web Application will stop from building the next deployment task.

Folder Structure

When you upgrade your Web Application to allow Atomic GIT Deployment, you will notice the folder structure will change. For example, a Web Application named myawesomesite owned by user runcloud will have a Web Application root path at /home/runcloud/webapps/myawesomesite. Then inside this folder, you will have your source code. But inside Atomic GIT Deployment, you will have configs, live, releases and storage.

  • configs - This is to store your config file(s). E.g, you can store Laravel or Symfony .env or CodeIgniter config.php here.
  • live - This is a symlink that points to your latest release.
  • releases - Inside here, there are four folders with the latest releases sorted by time of release.
  • storage - This is where to store your uploaded files.