What is an atomic deployment

Non-atomic code changes

When pushing changes to servers in a more traditional way, using SFTP software for example, what will often happen is that files are written in pieces, and one after another. This can lead to various problems.

A great example is when a PHP file is requested while it's still being transferred, in which case the PHP interpreter can attempt to execute only part of the PHP code in that file, often leading to parse errors or fatal errors until the transfer is complete.

Another example is when one PHP file attempts to require() another PHP file, that's part of the same plugin or theme, but hasn't been transferred yet. This may lead to fatal errors when the first file is requested, because the required file doesn't exist yet.

These problems are especially evident on high-traffic WordPress sites.

Atomic deploys

Atomic deployments solve these problems, usually by uploading to a different directory first, and switch to that directory only when the transfer has finished completely.

Another way of performing atomic deploys, is to push updates to a different server, that is out of circulation and not receiving any traffic. When the files are transferred completely, the load balancer can start sending traffic to this new server, and stop sending traffic to the old one, preparing it for the next deploy. This is a more complex scenario, usually used with large multiple-server applications.

Sail deploys are atomic

Deploying in Sail is an atomic operation. When invoked, the deploy command will first create a new release directory on the production servers, then push all the application files to that new directory.

Once all the files have been written to disk, the symbolic link that points to the current release directory is updated to point to the new release, in one atomic file system operation.

Note that only the deploy and rollback commands are atomic in Sail. This means that site backups, database imports and exports, downloads, etc., are not atomic.