WordPress Version Control and Deployment – Part 2

Getting Your Code on the Server

Now that we know all the tools we should have in place, the next step is using them to create a WordPress site, version control it, and ultimately get it onto a server.  There are numerous other articles explaining various methods to do this, so keep in mind that you may want to do things a little differently and that is okay. You are probably going to make mistakes along the way, I know that I did, it only serves to make you a better programmer.

1. Create a new site in AMPPS

The first step is going to be creating the site in AMPPS. To do this, log into the control panel by clicking on the application followed by the house icon. Under configure there is an option to add a new domain.


This will create a folder in AMPPS www directory, which is where your site will be. I typically terminal to that directory and remove the cgi-bin folder because Git doesn’t like non-empty folders but you can also remove it using SourceTree or Tower.

2. Setup Git in Beanstalk/Locally

Now that we have a working web directory on our server, we need to have a git rep set up before we install WordPress so that we can track all the changes. Log into Beanstalk and create a new repo, don’t worry about the deployments for now, only focus on naming it something cool.


When you are done setting up your Beanstalk repo, it will provide you with the details on how to set up your new local repo. There will be a path such as: https://lukesaccount.git.beanstalkapp.com/site.git.

You have several options to clone this repository, using the command line to clone the repo or using a program like SourceTree. We will use the later since it is more visual and probably less error prone to start off with.

Open up SourceTree and click on the New Repository Button, then choose clone from URL.


Using the path of your repository that Beanstalk provides you, copy the URL into Source URL field. Once that is done you can use the button beside the Destination Path to locate the directory of your website you want to use git with. This by default is /Applications/AMPPS/www/site-folder when you are using AMPPS but will vary on whatever local server setup you have. Before you set the destination path, you can use that window to delete the cgi-bin folder as I mentioned you could do before. You cannot initialize git in a non-empty directory.



Once you complete cloning the repository, any changes you make will be recorded, however you will still need to remember to do standard git commands or use SourceTree to stage, commit, and then push the files.

With SourceTree this will be the workflow:

  1. Change a file
  2. SourceTree sees you made a change
  3. Check the files you wish to stage in the commit
  4. Using the commit message field, type a message for your commit and press Commit
  5. At the top press the Push button (alternatively there is an auto-push button below the commit message field)

With Terminal here is your workflow:

  1. Change a file
  2. In terminal type git add .
  3. Next type git commit -m ‘enter a message here’
  4. Finally type git push beanstalk master (beanstalk may be origin instead)

Now that you have a basic workflow going, your files will be pushed remotely to your Beanstalk repository. Pretty neat right?

3. Get WordPress Going

The next step is going to vary depending on exactly how you like to set up WordPress. For me, I prefer to use the built in install in AMPPS, which is located on the left admin menu inside the control panel.  Simply click on WordPress followed by install, select the domain (aka the domain you set up), use either a root or folder install, and the rest is pretty much straightforward.


Once the installer is complete you should be able to browse to your site. Viola! You’re not done though. There are a lot of things inside of WordPress that you do not want to copy over into your repository. Don’t forget to push your files! Some people don’t like/disagree with keeping the WordPress install in the same repo as everything else, with many opting to submodule or ignore everything other than theme files. I prefer do track everything because in the end, it makes deploying sites so much easier.

4. Wp-Config for Version Control

So now that you have your WP site synced up, we need to do something about the difference in database credentials. Although we don’t have the code on a remote server yet, it will be there soon, and we don’t want to use the same DB credentials (local servers means crappy passwords for ease of use).  There are several ways to handle this by by far the best way I have found is modifying the wp-config.php file to use a local or dev file unless the site is a production server. This has the benefit of making it easier to work with multiple staging/dev servers as well as keeping extra crap we don’t need out of our code.

Below is a gist that I use when setting up my WordPress config files:
As you can see, we are simply replacing the default lines of code that define the database and wrapping them in a simple if statement that looks for a wp-local-config.php or wp-dev-config.php file and if neither are found it defaults to what is in the else statement. I use the local config file on my local system and the dev on my dev/staging environment. Those files are just a simple php block with the database information, collation, db user, etc. You’re probably wondering how we deal with the local config file since it is inside of the repository. Won’t it get staged and render our neat little hack useless? Technically if we do nothing you’d be correct however git has a handy utility called .gitignore which tells the repository to ignore that file and any changes made to it.

5. Ignoring the crap you don’t want.

Since we have a file that should not be tracked in the repository, we need to ignore it. Just like with the other commands in git you have two options, you can either use the command line or SourceTree. I find it easier to ignore files in SourceTree. It really is as simple as opening the program, looking at the unstaged files section, right clicking on the wp-local-config.php file and selecting Ignore.


If you accidentally tracked a file and need to remove it, there is also a Stop Tracking option as well, although I believe you need to remove it after doing that otherwise the file will still be there remotely in Beanstalk. Depending on your requirements there will be other files you wish to avoid tracking. Most of the time these will come in the form of images, build files using grunt/gulp, or entire directories. I strongly recommend ignoring the uploads folder in WordPress. Images are generally not supposed to be tracked as they cause repositories to get HUGE, same with Node modules and other build files.

Here is an example of a .gitignore file I’ve used on a project:

6. Set up the Remote Site and Deployment.

Everything is almost in place. The next step is getting the code into place. Since I work with WordPress mostly and because most websites today have some sort of database, you will want to copy that over first. I’ve been experimenting with WP-CLI and hope to cover that soon once I am more comfortable with it. WP-Cli is a command line for doing cool stuff with WordPress but I see it’s best use for doing a database migration as it can do URL replacement. For now though just copy your DB over however you’d like.

Once your database and dev site is set up the first thing you will need to do is log into Beanstalk. Select the repository you are creating the deployment for and press the deployment button, then you will need to create a new environment.



For this next part, I have my own process which you can feel free to copy or create your own. I will prefix the name of my deployment with the type of server it is going to such as DEV – Lukes Site. Then I will set the color of the repo to green if it is dev/staging and red if it is production. All of these exist as safeguards to help mitigate mistakes.


Next we need to decide what type of deployment to use, I always use automatic on staging and dev but Never EVER EVER use anything but manual on a production environment. This will help prevent you shipping code that you find out breaks the site.


After selecting the type of deployment you will need to select the protocol that the connection uses such as FTP, SFTP, etc. This is going to vary depending on your environment setup. Now we get to enter all of the good stuff, host names, usernames, passwords. One thing to remember is that since we are deploying to a remote server we want to make sure our code goes to the right place.

I typically open up Filezilla and SFTP to the server and check the remote path. It almost always looks like /public_html/www/siteroot or /public_html/www . This is important because sometimes the way some FTP programs connect will vary slightly and it makes sense to double check (I learned this the hard way).

Screen Shot 2015-08-19 at 10.08.40 AM

With all of the information entered, you can pretty much bypass the rest of the steps, Beanstalk will do a connection check and if all things are good, you should be able to tell Beanstalk to deploy the code. As long as you used the automatic method, your code should end up on the server after the next commit or if you manually deploy.

For your production environment, the setup is exactly the same just remember to use manual deployment to prevent any Uh-Oh moments from happening. You can add as many servers to this as you’d like. There are also a lot of cool post deployment options as well that you should check out.

7. That’s a Wrap.

Whew! That was a lot to take in. I spent a good part of a year looking up various methods to handle deploying code because I grew tired of wasting time being an FTP commando. I’ve gone through just about every article I could find on this topic and while none of them were step by step guides, combining a lot of what they did in addition to my workflow specific needs, I was able to create a setup that I believe works quite well.

Hopefully this article helps others make sense of such a massive and complicated topic that is still being researched, talked, and argued about. I’m definitely far from using every best practice but this is definitely a solid starting point for WordPress version control and deployment.

I’d like to give a shout out to Issa Diao for helping me get started with Git, as well as the team at Beanstalk for being awesome folks who created an awesome tool.

WordPress Version Control and Deployment – Part 1

What You Will Need

Today’s web developer works with many technologies. Gone are the days of building a site using only HTML and CSS. Teams are also getting larger and as a result it is becoming increasingly common to see multiple people working on one website at the same time.

Version control and deployment are very hot topics within the WordPress community right now and they aim to solve these problems. While many of us have heard of these terms and participated in conversations involving them, there are still a small number of people actively using these tools.

Working with so many sites on a daily basis, I found myself wasting a lot of time moving code via FTP or needing to revert changes back after I had made a change to a website. Combine that with CSS Pre-processors, grunt, as well as  numerous other tools, and you have a recipe for disaster.  This is where a version control based workflow coupled with deployment tools comes in handy.

First I’ll explain the pieces of the process and why I’ve chosen them.  Once you have a firm understanding of each part we can then get started with the setup and execution of the workflow. There are a couple of options and approaches which will be covered as well.

You’ll need:

  1. A Beanstalk Account
  2. SourceTree
  3. AMPPS
  4. Git

Shop Develop Locally

This whole process would be pointless if we weren’t building websites on our own machines and we do so for several reasons. First and foremost the speed at which you can work with your code can be pretty dramatic. Even with a fast internet connection you still have longer wait times than what you may realize. Working offline also means that if you lose internet or are without it, you can still work with a dynamically rendered site.  If you are using tools like SASS or Post-CSS they are much easier to use locally as well.

As with anything involving technology, there are a million different opinions on what the best local server setup is. There are purists who will say that you should simply install Apache/MySQL/PHP,  MAMP/XAMPP/AMPPS/etc users who will tell you that their way is best. Some will even say that you should use HHVM.

So which should you use? I think that it is up to you because really anything will do. Each program and method has pros and cons.  While I can only speak from experience about what I have used, I think that you should try out a few options and see what you like.

I’m currently using AMPPS as my server. Initially I used MAMP but I like having the extra installers that come bundled with AMPPS although now you could technically use WP-CLI along with MAMP to achieve similar functionality.

Getting GIT

No modern workflow would be complete without some method of source control. There are many options out there. I prefer using git mainly because I feel like there is more documentation available and most of the tools I use have git repositories. Just as important as deciding which technology to use, we also need a place to actually store the code. Github, Bit Bucket, and Beanstalk are all examples of git repository hosts and ones that I have used.

Depending on how you are interacting with your code, specifically database credentials, you will most likely want to opt for a service that has private repositories. This will prevent people from having passwords to your websites. All of the perviously mentioned services have private options although Bit Bucket is the only one to offer free (as in root beer) private repos.

I use a mix of Beanstalk which also serves as a deployment tool as well as Gitlab to host code internally where I currently work. The reason being that we have so many clients and so in an effort to keep costs down we have been building our own continuous integration system, but more about that later.

Moving Le Code

So you’ve got your code version controlled, you’re working locally, and then you realize that your code still needs to get onto the server. What do you do? This is where deployments come in. There are numerous blog posts about this topic, many of them are going to tell you to use git post-receive hooks to merge the code into a repository on the remote server.  I’m not going to do this.

When I first set out on my path to find a way to “launch” my code I was stuck like many other people. I had just learned to use git. I wanted an easy to understand way to get my code on a remote server. Manually doing that was a pain in the rear and trying to use git to merge the code into a remote repository seemed like another hassle, especially with the amount of work I do on a daily basis.

This was all before I discovered Beanstalk, a tool that works as both a repository host as well as a deployment application. Beanstalk provides you with private repositories and also has the ability to move your code to a server using several methods including FTP/SFTP. There are also built in collaborative tools and code reviewing features.

Although Beanstalk is my go to tool for getting my code on whatever server it needs to be on, the costs can add up pretty quickly. Recently I’ve started rolling out my own deployment system using Jenkins, a continuous integration tool. The documentation on it wasn’t great but I was able to find a plugin for it called Publish Over FTP which can do just about everything Beanstalk does, although it isn’t for someone who doesn’t like a good challenge.

Next – WTF to do with it all

Now that you know what tools you can use to accomplish version controlling and deploying a WP site, the next step is actually doing it. Next week I will cover the whole process as well as provide some tips and tricks.

Part 2 – Getting Your Code on the Server