How Reaktiv Studios uses DeployBot in their WordPress workflow

Last week, I shared Loek’s story about how DeployBot changed the deployment workflow for the team at ReSnap. A couple of weeks ago, I had a similar conversation with Josh Eaton.

Josh is a Lead Developer and partner at Reaktiv Studios, a VIP Wordpress studio that specializes in custom development.

Shane: Hey Josh, thanks for taking some time to talk today. Let’s start by talking a bit about Reaktiv Studios and some of the problems you wanted to solve in your deployment workflow.

Josh: Sure. At Reaktiv Studios we build custom web experiences with WordPress. One of the biggest frustrations for our workflow, especially when it comes to deployment, is dealing with merge conflicts from minified files. We use Grunt, and keeping minified files in our repository made those merge conflicts an inevitable, and super annoying, part of our workflow.

We also run a single staging Droplet on DigitalOcean, and we set up each project with its own isolated site there. This is a critical part of how we work and we had to configure and manage deployments for each site individually.

We’re developers, not sys admins and we’re always looking for ways we can streamline this process.

S: What does a typical project look like for your team?

J: Well, when you build with WordPress each project can be really different. Every managed host has their own structure, with different nuances that impact how you deploy your work. Some give you SSH access, others don’t. One host might put the entire site under version control with exclusions, or just put ‘wp-content’ under VCS. The differences extend to where we need to deploy our work too. Some hosts give us a path for uploading our work, and others symlink in parts of WordPress core.

When I heard about DeployBot, my hope was it could help consolidate and streamline these project variables for us, allowing us to have one site structure we use for all projects, regardless of the final host.

S: Got it. So far we’ve talked about you’re experience before you were using DeployBot, can you tell me how your workflow has evolved since you started using DeployBot?

J: One of the first things I think about is the number of merge conflicts has gone way down. This is mainly due to using Build Tools to minify our files with Grunt and keep processed files out of our repositories. We also pull in dependencies with Composer and Bower. Our repository history is much cleaner, and we’re not having to commit everything twice to clear merge conflicts. This is a much better option for us than running builds locally and committing all those files into our repo.

Setting up deployments to our staging server is much simpler now too. Instead of having to install a bunch of dependencies each time, or maintaining an image with up to date dependencies, now I just duplicate an existing server on DeployBot. This copies over all the settings for our staging server.

Another aspect we like is access control. We're able to set up contractors or new employees with limited access to staging and production environments but still provide an easy way to deploy their code. Now instead of having to manage SSH settings or provide login credentials, we can add anyone as a user on DeployBot and manage which repository and environments they can access for deployments in one place.

Moving through the project lifecycle, it also makes it easy to deploy to whichever host we’re using for a specific project. Even when there’s an option for Git deployments with a host, DeployBot gives us a single place to go to deploy every project.

S: Josh, thanks for taking the time to walk us through your workflow and how DeployBot has streamlined some of your process.

I want to thank Josh again for taking a few minutes to talk, and hope his experience is helpful to other teams. If you have any questions about DeployBot you can email support@deploybot.com, or try it for yourself for free.