Hi everybody,
In the previous article here How to use WordPress with Git efficiently , I showed you the best practices when you have to deal with Git and WordPress.
It’s good, but what if you have to deal with multiple environments like “local, staging and prod”? What would be the best deployment procedure?
WordPress is a cms managed essentially through the database, partially with files, and plugins don’t have a repository system like Packagist with Composer or NPM, so hard to deal with third parties properly in all environments, you’ll have to put all the plugins in your vcs (Versioning Control System) or install them manually in all your environments.
And, about the database, it is very difficult (impossible) to manage it through a vcs.
If you didn’t managed yet to work with Git and wp-cli in your WordPress project, please refer to my previous article How to use WordPress with Git efficiently.
To deal with deployments best practices under WordPress, we will use the most famous “Capistrano” adapted for WordPress, link here https://github.com/Mixd/wp-deploy. It’s not really good explained, let me save you some time.
Let’s start:
- If Ruby, gem, bundler and wp-cli are not installed in your machine, install them
apt-get install ruby gem rvm gemset use global && gem install bundler #Now install wp-cli curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar chmod +x wp-cli.phar sudo mv wp-cli.phar /usr/local/bin/wp
-
Download the github repository on your machine
git clone https://github.com/Mixd/wp-deploy <YOUR_FOLDER_NAME>
-
Be sure that the owner of the last created folder is not “root”, it will cause you issues with Capistrano and wp-cli. If the folder owner is “root”, change it to any other profile you have.
-
Install the ruby gems dependencies
cd YOUR_FOLDER_NAME && bundle install
-
Write your wordpress repository config (with the right branch, mainly development) inside prepare.sh file
nano config/prepare.sh
-
Automatically pull your WordPress repository inside our main repository, it will be pulled inside a wordpress directory
bash config/prepare.sh
-
Check that your repository has been pulled inside the “WordPress” directory with the correct branch name
cd wordpress && ls -al git checkout
-
Perfect ! Now let’s configure general settings
cd ../config && ls -al #You can look at all the files inside. For general settings we will only use the deploy.rb file nano deploy.rb #wp_user: The username of your WordPress administration user. #wp_email: The email address of your administration user. #wp_sitename: The site title of your WordPress installation. #wp_localurl: The local URL of your site. #application: The name of the temporary folder used by Capistrano when deploying the website. #repo_url: The SSH URL of the remote repository. Capistrano uses this to clone the repository onto the server.
-
Now let’s fill in database details for all of our environments
#First duplicate the database.example.yml file and edit it cp database.example.yml database.yml nano database.yml
-
Alright ! Now let’s configure our deployment environments
cd /deploy && ls -al #You must see two files, production.rb and staging.rb, open them and fill in correct informations #stage_url: This is the URL of what the website will be under in that environment. This should always have the HTTP protocol (http://site.com, https://site.com, etc etc). You'll need to make sure your vhosts on the server are setup for this URL. #server: The IP address of the server to connect to via SSH. Each environment can be on a different server, think staging server vs production server, keeping things nice and compartmentalized. #user: The SSH server you'll be using to connect. #deploy_to: The folder on your server where the site will reside.
You are almost done. You are now on your development branch inside the staging environment, be sure that you have a working production environment.
If you already have a database for your project, install it manually, if not, you can deploy your project locally.
bundle exec cap staging wp:setup:local #Then check your database
Your purpose now is from staging to push modifications on production and rollback immediately if something is going wrong. Never push directly from local environment to production, and, like it is done for WordPress, you can easily push/pull/backup your database from any environment to any other.
These are the list of all commands available.
deploy # Deploy the project to a given environment deploy:rollback # Rollback to a previous deployment. wp:setup:local # Setup your project locally wp:setup:remote # Setup your project on a remote environment wp:setup:both # Setup your project locally and on remote environment wp:set_permissions # Set 666 permission for `.htaccess` and 777 for `uploads` on remote environment wp:core:update # Update WordPress submodule (core) locally. db:push # Override the remote environment's database with your local copy. Will also do a 'search and replace' for the site URLs. db:pull # Override the local database with your remote environment's copy. Will also do a 'search and replace' for the site URLs. db:backup # Take an sqldump of the remote environment's database and store it in a folder of your local repository called db_backups (its ignored in Git) uploads:push # Override the remote environment's uploads folder with your local copy. uploads:pull # Override your local uploads folder with the environment's copy. cache:repo:purge # Remove the repo folder on the environment in question.
If you need more informations about capistrano and this tutorial, this is a useful link:
http://capistranorb.com/
https://github.com/Mixd/wp-deploy
Creativ' Coders 