How We Manage Sites With Beanstalk
Years ago when we began developing websites, things were pretty simple. We usually only needed one person to work on a project, often myself. The sites we built were very simple, often static sites. We could build things locally and just FTP them up to the live server. If clients wanted changes made, we just made the changes for them since everything was setup via html files. Then things changed – sites became more complex, we needed 2 or more developers working on a project at one time. Changes needed to be tested before being deployed and clients wanted to edit sites quickly – on a daily or hourly basis. That’s when we decided our old methods weren’t working so we needed something new. Enter version control with Beanstalk.
What is Beanstalk?
Beanstalk is a hosted version control system. They provide a place for you to upload your code, track changes, and deploy it to servers. Beanstalk offers several different types of code hosting but we use git. Nearly every site we develop begins as a repo in Beanstalk.
Our Process
Following is our process for developing sites using Beanstalk.
1) First we’ll add a new repo in Beanstalk and then open that in Tower.
2) Next we add our starter files – we have a copy of WordPress in a separate repo that has a few config file changes, our starter theme, some common plugins, and a gitignore file.
3) The first thing we do with the fresh set of files is change our config settings. We use a local-config.php file for developing things locally so that our main wp-config.php file can use the dev or live server settings.
// Check for a local config file
if ( file_exists( dirname( __FILE__ ) . '/local-config.php' ) ) {
define( 'WP_LOCAL_DEV', true );
include( dirname( __FILE__ ) . '/local-config.php' );
} else {
define( 'WP_LOCAL_DEV', false );
define('DB_NAME', 'db');
define('DB_USER', 'user');
define('DB_PASSWORD', 'pass');
define('DB_HOST', 'localhost');
}
We use gitignore to ignore the local-config.php file in our repo.
4) Next we’ll push our initial commit up to Beanstalk.
5) After our files are in Beanstalk, we’ll login and setup deployments. A deployment is Beanstalk’s way of delivering files to a server. They have several options, but we generally use SFTP. One of the cool things is that they allow you to include deployment commands in your commit messages, so something like [deploy:dev] would upload your files to your “dev” environment.
6) Next comes the all important “ignore” list. The ignore list allows you to flag files in your repo that you don’t want to deploy, all on an environment by environment basis. So for example, if you wanted to avoid deploying wp-config.php, but you still wanted that managed in your repo, you could add wp-config.php to your ignore list. Here’s the list of ignores we use:
.htaccess
wp-config.php
/wp-content/uploads
/_db
The _db directory is used for database backups. If you’re running a cache plugin or another plugin that generates uploaded files, you would likely want to add those directories to your ignore list.
7) Once everything is setup in the environment, we’ll do the initial deploy to the dev site. We also setup a database and install WordPress on the dev server.
8) Next we’ll develop the site, deploying code as we progress. A plugin like WP Migrate DB Pro comes in really handy for syncing the dev site database with your local machine. Just use it carefully when working with multiple people so you don’t overwrite each other’s changes if you push the database up from your local machine to the dev server.
9) Once development is done, we’ll create a live branch in the repo. We’ll then setup a new Beanstalk environment to deploy this branch to the live server. There are many ways to handle branches, but for most of our projects we keep things simple with a master and live branch. If a site is more complex, we sometimes create new branches for major features and merge those back into master and then live, as needed.
10) Once a site is live, it’s common for clients to request further changes or updates to a site. The way we handle that is by working in the master branch (or a feature branch) to make the changes, then deploying those to dev with [deploy:dev] for testing, and then merging into live. Once changes are in live, we use [deploy:live] to deploy those changes.
Common Pitfalls
While this process generally works really well, there are a few things to keep in mind to avoid problems.
1) Don’t give clients direct FTP access. If they edit files directly on the server, those files could get overwritten when you do a deployment. That’s also why it’s important to add directories like the uploads directory to the ignore list in Beanstalk.
2) Disable the file editor in WordPress. This is just like FTP access – any changes here will likely be overwritten when you make changes and deploy via the repo. You can disable the editor by dropping the following code in your theme’s functions.php file:
/*
* Disable Theme Editor
*
*/
function remove_editor_menu() {
remove_action('admin_menu', '_add_themes_utility_last', 101);
}
add_action('_admin_menu', 'remove_editor_menu', 1);
3) Disable automatic WordPress updates. They’re great, but you don’t want the live server getting updates that your repo doesn’t have. Check out the definitive guide to disabling WordPress updates.
4) If you’re going to add plugins or upgrade WordPress, do it on your local copy and push that up to dev and live. You want to make sure those new files are in the repo, not directly on the server.
5) Always have backups before making any changes to a live site. It’s just common sense.
6) If you’re running a cache plugin or a service like CloudFlare, be sure to clear your cache after pushing changes to your dev or live server. Often times cache plugins will clear the cache when you’re working from within the WP Admin but rarely do they automatically refresh the cache when you’re pushing code via Beanstalk, FTP, etc.
7) Keep in mind that using this setup will manage your files in git/Beanstalk but it will not manage your database. Any WordPress content, plugin settings, extra fields, categories, etc are stored in your database. So if you make changes to your dev site database, you’ll need to make the same changes to your live database. You’ll want to be especially careful with things like category id values or page id’s. If you’re writing a custom query in your theme to call in a category by id, the id value may be different on your dev and live sites if you’ve created that category on each database separately.
8) If you’re going to be pushing WordPress core files or plugin files to your live site, I’d recommend disabling your site to visitors while you push the files. This will protect both your users and your site from any activity during major changes. One easy way to do this is by using a “.maintenance” file at the root of your live site. We usually login via FTP, upload the .maintenance file, do the Beanstalk push, and then remove the .maintenance file. The content of your .maintenance file just needs to be:
<?php $upgrading = time(); ?>This will put up a notice that your site is being upgraded and will be back soon. If you want to avoid all FTP access, you could use Beanstalk to push the .maintenance file before you push the files and then remove it when you’re done. It’s a couple extra commits, but it should work fine if you prefer that route.
Going Forward
If you’re not already using Beanstalk or some sort of version control system, I’d highly recommend checking it out. Moving to this workflow has helped us grow and enabled us to manage much more complex projects. Beanstalk also has a lot more features and integrations that can help speed up your workflow.
What solution are you using? Have a better way of using Beanstalk? Let us know in the comments!