If you’ve been in web development for a while, you’ve probably screwed up a file transfer as you’re trying to update a site. In the best case scenario, you add a bunch of easily identifiable files to a directory and you remove them to fix the error. Yes it costs you time and it’s annoying, but no harm done.
In a worst case scenario, you transfer a bunch of theme files improperly. Then you have to figure out which ones were overwritten, which don’t belong at all, and how on earth will you recover your theme’s proper working state.
Today we’re going to tackle solving this problem using Git and Deploybot to automate your deployment process.
What is Automated Deployment?
A basic automated deployment has four pieces as shown in this diagram.
Most developers start with just their code and the server. They make changes to their working copy of the site, and then push those changes directly to the server via FTP. Tools like Coda or Dreamweaver have direct FTP integration so that you can do this from inside your coding environment.
The next step many developers take is to add a staging site so that they’re not modifying the live server directly. You can do this with something like VVV or MAMP. Often this also means you’re using a version control system like Git to manage the changes you make to your local working site.
When you add a staging site, you also add complexity. How do you get your code changes from your local working site to a staging site where your client can see the changes? Yes, as I already said, you can use a basic FTP client like FileZilla, Transmit or Forklift to move the files as you make changes, but this is error prone and this is where automating your deployment process will save you so much time.
Instead of you taking the files you change and pushing them to your staging server, you use another system to automatically detect the changes in your Git repository and push only those changes to the staging site your client can use to check the work.
That still leaves your live site as a manual deploy though, which is much scarier because it can mean the loss of real money if you take down a live working site. Instead, let’s assume that you’re going to set up your deployment system to automatically deploy to staging, and then your system will deploy with a single click to the live environment when you’re ready to go.
So now you have a system that looks like this.
Let’s dive in so I can show you how I set up this deployment process for every client I work with. These are the steps I take as soon as I start a new project. I always make sure that my deployment process is set up and working before I start doing any other work on a client project.
How to Structure your Git Repository
Your first choice to make is, which directory will you set up your automated deployment in? Unless my client specifically requests that full source control for their WordPress install, I use the wp-content directory to set up my automated deployment system. That starts in terminal by issuing this command that initializes a git repository.
Now it’s time to ignore the files you won’t want to deploy all the time. These are files like backup files, images, and any of the custom project files that many code editors add to a directory. You can see my usual .gitignore file below.
Feel free to add or remove from this as needed. Almost every project I work on needs some sort of custom entry to ignore some file that is specific to my local working site for which the staging and live sites will have their own custom file I don’t want to overwrite.
From here it’s time to set up the branches you’ll need to get your deployment system going. I use two main branches. First is the master branch which corresponds to my live production site. Second, is a branch I label staging and corresponds to the staging site I want my client to use as a way to check the changes we’re making.
When you initialized your Git repository you already got your master branch, so use this command to add a staging branch and check it out.
git checkout -b staging
This command creates and checks out a new branch. If you’re new to git, you can find more information on the available commands in the Git documentation.
Now you’ll need to push your project into your source control system. Github and Bitbucket are two popular choices which both work with the automated deployment system we’re going to use called Deploybot. When you create a new repository with either site they’ll give you further directions to add your local repository to your online version in Github or Bitbucket.
Setting up Deploybot
When I was first getting into more complex work as a developer my friend Duane kept recommending Deploybot to me when I complained online about messing up manual FTP deployment. It took a number of recommendations before I finally did what I was told, but I’ve now been a happy Deploybot customer for years.
While there are other ways to deploy your sites many of them involve interfacing with Git Webhooks or some automated deployment configuration files via your code editor. There is lots of power in those other tools, but if you’re just getting started with automated deployment, then going with something straight forward like Deploybot is the place to start.
To get started sign up for a Deploybot account and connect Github or Bitbucket to your account. I’ll use my existing Bitbucket account today. Start by adding a new repository to your Deploybot account.
Once you’ve found the repository you want to setup for automated deployment click the button labelled connect at the bottom of the page. This will send you back to your repository page while Deploybot finishes initializing your repository. Generally this is done in a minute or two so fill up your coffee and come back to finish setting up your deployment process.
Once your repository is set up, click on it to get taken to its main page. Since we have no sFTP information set up yet it will have a big box on it telling you to set up a server. Click on the button to create an environment and server.
Let’s start with deployment to our staging environment. So label your server as staging. Choose automatic deployment and make sure you set the branch to staging.
When your done click the Save button on the bottom of the page to move to your server configuration.
On the next page label it as a Staging server again and put in your sFTP information from your site. If you’re not sure where to find them, read this helpful guide.
With your sFTP information entered you can scroll down to the bottom and save it. Deploybot will then test your connection to make sure that the information you provided works. Now it’s time to do our initial deploy for the site to make sure it all works. I often add a test.txt file to the deploy as an easy way to verify that the deploy worked properly.
To start your deploy to your environment history and click deploy.
Now you’ll see a page with your last git commit message on it as the note you’ll see inside Deploybot next to this deploy. For big changes I’ll change this, but if I’m just changing CSS or something minor the commit message can stay. Since this is staging, every single commit to our staging branch will be deployed automatically, which means your commit messages are what will show up. It’s only the initial commit that we need to do manually to our staging site.
Now verify that your files have been published to the staging site and we can set up the live deployment.
For your live deployment, make sure that you don’t choose automatic deployment and make sure that you choose the master branch as the source of your deployment. We want this to be a manual deployment when we’re ready to push changes to our live site.
To do this you’ll need to check out your master branch then merge your changes from your staging branch into master.
You can do that with these commands.
git checkout master
git merge staging
git push origin master
Now when you go to your Deploybot account you’ll be able to manually deploy your changes just like we did with our initial deployment to our staging environment. For your live environment, make sure you change the deployment message to suit the changes that are being pushed to your live site. You should also create a backup of your site. You can do this by accessing the backups navigation on your site and then creating a manual backup.
That’s it, you’ve got your automated deployment system setup for both staging and live environments.
Other Deployment Considerations
While this system is a big step forward for most developers, it’s not without its issues. The biggest one being that if you have a bunch of changes you’re still waiting for FTP to finish transferring files that have changed. This can mean that someone visits your site and not all of the files your site needs to run are present.
For many clients this won’t be an issue, but if it is for your site then you’ll need to look at setting up an Atomic deployment system. This type of deployment system moves all the files, verifies that they are working correctly and then changes the file settings on your server so that the new directory is now the one that runs your site.
The process of linking to a new folder takes such a short time that only a computer would notice. That also means if you find a problem later, you can change your system link back to the old version of the site to rollback to the version that was working. This again only takes a very short amount of time and reduces downtime.
No matter what you choose to do, stop using an FTP client to deploy your client files today. The small monthly cost of Deploybot is recovered every time you don’t make a mistake deploying your files.