Getting started with Deploybot & why you should stop using FTP

I’ve known for a long time that manually transferring websites over FTP wasn’t the correct way to do it, but having the time to investigate and implement another method was tricky, we work to tight schedules here at WATB. Luckily though after completing a recent project I had some time to look into deployment, and the tool we ended up trying out was Deploybot.

Deploybot acts as a sort of tunnel between your Git repositories and your hosting. It allows you to link up a repo to multiple hosting accounts, through what it calls environments. An environment allows you to control exactly where your deployments end up.

For example, a basic implementation, and one ideal for most of our projects, involves having a Staging environment and a Production environment. We connect our staging environment to our testbench – this is a portion of our own hosting we use for testing client sites. The production environment is then linked to the clients live hosting.

We’re then able to link different branches of our repos to each environment. so we have a Staging branch and our usual Master branch which we use to push to production.

Here then is a simple walk through of how we set up Deploybot. It won’t cover everything in detail but it should give you a pretty good idea of how it works.

Step One – Tidy up your Repo and prepare Git

Your projects probably aren’t best set up for Deploybot off the bat. I’d therefore strongly suggest a good old fashioned repo tidy up – removing dud files, cruft and anything that isn’t relevant to the project, for example rogue PSDs. Once your repo is OCD level of clean and tidy, add a Staging branch by running:

git checkout -b STAGING

git push origin STAGING

Step Two – Connect your repo to Deploybot

Setting up a Deploybot account is straight forward so I won’t bore you with the details – but once you have done so login to your dashboard. Then, from the menu at the top, select Repositories and click the Connect a Repository button. You’ll then get a screen like this:

If you haven’t already connected a Bitbucket, Github or self-hosted Git account, you’ll be prompted to do so. It’s pretty straightforward, at least for Github or Bitbucket.

Once you select your repo and click Connect, you’ll need to wait a few minutes for Deploybot to connect the repo to your account. Then, click through to your repo from the Repositories page. You’ll then get a page of environments, a bit like the one below, but yours will be empty.

If like me, the Staging and Production setup is enough, you’ll need to add these. Click “Add an environment” and you’ll get a page like the one below.

Make sure you select the correct branch as per you repo, so that your Staging environment uses your Staging branch, etc. You should also only enable automatic deployments for staging. If you break your staging site, it isn’t of tremendous consequence. Breaking a live client site with a rogue deploy could have serious consequences for both you and your client, so you should only manually deploy.

Step Three – Connect your Servers to Deploybot

Your next step will be to connect to the relevant server. Remember to connect to yours for Staging, and your clients for production. You’ll get a screen like this:

You ideally want to use SSH/SFTP if possible, but many clients still use shared hosting so normal FTP is possible. You still avoid many of the pitfalls that you experience using FTP clients.

When you finish adding in the server information, Deploybot will attempt to connect. If successful, you’ve finished setting up your environment. You can then repeat this process for setting up each environment you need.

Remember to specify the server path to your project. For WordPress themes this will be the theme folder. I generally recommend not including the whole CMS in a repo. I also recommend that you empty folders before you run your first deployment, to avoid any potential issues, but of course backing up first.

Step Four – Deploy a Commit

You’re now all set up and ready to rock and roll with Deploybot. You should first test your Staging deployment by pushing a commit to your Staging branch. If all goes well, the deployment will automatically run and you should see the change on your server.

Deploybot Advantages

We’ve already found numerous benefits to using a deployment tool.

• A streamlined workflow. Not having to manually upload files to staging/testbench servers saves us a bunch of time. Less time uploading, more time working on the important stuff.
• Ability to quickly and easily roll back – Deploybot lets you roll back to any previous commit with one click of a button. If you encounter any problems with your build, this makes rolling back so much easier.
• Helps eliminate user error. FTP clients are open to user error, it’s far too easy to overwrite a site or upload to the wrong server – we’ve all done it! Deploybot means we won’t make mistakes dragging and dropping. I’ve accidentally hit a keyboard button and slipped with my mouse causing my uploads to mess up when using an FTP client.
• Makes Git even more useful. We already loved using Repo’s to track our work and changes, but Deploybot makes Git Repo’s even more useful.
  

There’s many other benefits, but these were what I could think of. We’ve only been using Deploybot a few days and already it’s clear to see how tools such as this allow for a better, more efficient, more safe front-end workflow.