A framework for managing and deploying WordPress websites across multiple server environments using Capistrano 3.
- Ruby >= 1.9.3
RVM is a good option for managing Ruby and Gems. Git is also required. You must have already installed your ssh keys into your remote repository and the environments you'll be deploying to.
Clone this repo into a deployment directory of your choosing and run the installer:
$ git clone [email protected]:Toddses/capify-press.git /home/user/deployments/example
$ cd /home/user/deployments/example
$ bundle install
Create a remote repository somewhere, for instance at GitHub or BitBucket.
Edit the required settings in config/deploy.rb
:
# Required Settings
# =================
set :application, "example"
set :wp_version, "4.1"
set :repo_url, "[email protected]:User/example.git"
set :admin_email, "[email protected]"
set :local_url, "http://localhost"
set :local_path, "/var/www/html/example"
Set up your database info:
$ cd config
$ cp ex-database.yml database.yml
Edit database.yml
with your own details for each environment. Prefix is the table prefix WordPress will use for each environment. Do not include this file in any repo!
Three environments will be created by default:
$ ls config/deploy
local.rb
staging.rb
production.rb
Edit the settings in staging.rb
and/or production.rb
with your own info:
# Required Settings
# =================
server "xxx.xxx.xxx.xxx", user: "your_ssh_user", roles: %w{web app db}
set :stage_url, "http://example.com"
set :deploy_to, '/var/www/example'
# Git Setup
# =========
set :branch, "master"
# WordPress Setup
# ===============
set :wp_debug, true
set :wp_cache, false
You can leave local.rb
alone. For now, it is mostly for semantic purposes.
You're good to go!
You can add or change environments as needed. Say you want to change staging to test, simply rename staging.rb
to test.rb
. If you'd like to create additional environments, copy one of the stage files and edit the settings from there:
$ cp config/deploy/staging.rb config/deploy/test.rb
Slack integration provided by capistrano-slackify. In slack, ensure you have enabled the incoming webhooks integration. Edit config/slack.rb
with your webhook url provided in the setup instructions:
# Required Settings
# =================
set:slack_url, 'https://hooks.slack.com/services/xxxxxxx'
There are also a number of optional settings you can customize. The task will run automatically during deployments.
You can see all described tasks at any time with the command:
$ cap -T
- cap local wp:local:install: Install WordPress locally and set up the repo and database
- cap stage deploy: Deploy the site from the repository to the remote server
- cap stage wp:remote:push: Deploy the site and push the database and uploads from the local server
- cap stage wp:remote:pull: Clone a remote repository and pull the database and uploads from the stage server
- cap stage db:push: Pushes a local export of the MySQL database and imports to the remote server
- cap stage db:pull: Pulls a remote export of the MySQL database and imports to the local server
- cap stage uploads:push: Transfer local uploads content to remote server
- cap stage uploads:pull: Transfer remote uploads content to local server
Each of these tasks takes care of the basic legwork for you. Installing WordPress will create the database, if it doesn't exist, set up your local config files (wp-config.php
and .htaccess
), start your repo with a .gitignore
that's good for WordPress and a basic README, and push it to the remote repo with an initial commit. All you have to do is visit the local site in a browser and complete the WordPress installation.
Deploying will create the config files for the stage automatically.
Pushing/pulling the database will replace the URLs in the database, as well as the table prefixes, so you can bring up the site with no additional set up necessary. NOTE: Push and Pull currently DROP the existing tables if they exist. This means you will ovewrite all data. So be sure you want to perform this action before you run the task. It is in my future plans to create tasks for more of a merging option for incremental database updates as opposed to full data replacement.
Pushing/pulling the uploads will not overwrite, but merge. Existing files will be overwritten, but new files will not be deleted.
If your remote server is running Apache 2, there's already a few tasks to automate the basics. These can easily be extended to handle more of the legwork, and additional tasks for different servers may be added in the future.
- cap stage apache:setup: Enable the rewrite module (usually it is not already enabled)
- cap stage apache:vhost:create: Create an apache configuration file and enable the site
- cap stage apache:vhost:destroy: Delete the apache configuration file and disable the site
The vhost tasks will set up the host with the stage URL you have set.
Feel free to fork this project and create pull requests for any additional tasks you may have created!
MIT License (MIT)
Copyright (c) 2012-2015 Tom Clements, Lee Hambley
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.