When working with Sail, you will almost always have a local working copy, which
is where you ran
sail init to start your project. This is a copy of your production
application, with a few differences and aspects to keep in mind.
First, any changes you make in production, will not magically appear in your local working copy. This means that if you install a new theme or plugin, update WordPress core, etc., using WP-CLI or wp-admin, these changes will remain on your production server only, until you explicitly pull them to your local working copy.
You can pull changes from production to your local working copy using:
You can learn more about keeping your local working copy in sync with production in our guide.
When you've made changes to your local working copy, you can push them to production using:
This will create a new release directory on your production server, send over all your application files to this new directory, and perform an atomic deploy.
If you're not sure about the state of your local working copy, and whether it is
or was in sync with production, you can add the
--dry-run flag to only show the
changes about to be applied by a deploy:
sail deploy --dry-run
You will see files that will be created, modified or deleted. If the changes
look correct, just drop the
--dry-run flag to perform a deploy.
It is always recommended to perform a full application deploy, however in some situations, you might want to deploy changes only in a specific directory of your WordPress application. You can do so by specifying the path to deploy, for example:
sail deploy wp-content/plugins/my-custom-plugin
This will deploy only changes in the wp-content/plugins/my-custom-plugin directory to production, keeping everything else intact.
Using sparse deploys is a good method to resolve conflicts between production and local working copies, when the two have diverged significantly.
sail deploy will ignore everything in the wp-content/uploads directory.
This is usually the desired behavior, since you don't really want to be pulling
and pushing large files around. However, if you do need to sync your local uploads
with the ones in production, you can simply add the
sail deploy --with-uploads
Note that this will overwrite anything you may already have in the wp-content/uploads directory on your production server.
Deploying uploads is usually useful only when migrating an existing WordPress site to a Sail-powered server on DigitalOcean.
Sail CLI supports adding one or more
pre-deploy hooks, which are executable
scripts that run before deploying changes to production. This is useful for
checking PHP syntax, running unit tests or coding standards checks. Here's
a quick example.
If you'd like to undo a deploy, you can use the rollback command.
If you have any questions or feedback about deploying with Sail CLI, check out the getting help section.