For anyone who has worked on commercial software for an agency or an organization – either large or small – is likely familiar with the idea of continuous deployment.

And it’s a great thing, right?

At several points throughout the day, all of the code that’s been committed to source control is run through testing, compiled (if needed), and then deployed after which an email is sent giving statistics of the build.

When working with WordPress, I think that tools like that are far less common. Instead, we test things locally, maybe we deploy things to staging, and then we hand off the project to the consumer or to the client.

For very small projects, I think a case can be made that that’s acceptable – I mean, you can go overkill on nearly anything – but if you’re going to be working on something that has a lot of moving parts and will be used by a lot of different people, doesn’t it stand to reason that having some type of deployment strategy something we should all be using?

Continuous Deployment For WordPress

Like anyone who has looked into any area for tooling that exists within their field of work, I’m no different. And when it comes to continuous deployment for WordPress, there are a number of different tools I’ve tried.

Sure, there are some really great options available – some free and some commercial – all of which have their pros and cons. But Codeship is a service that I’ve found to be the most useful in my day-to-day work for setting up deployments.

Continuous Deployment For WordPress

This is not a tutorial on how to use Codeship for continuous deployment – they have fantastic documentation that gives you more than you need to know. Instead, this is more of me making a case for why I dig using it.

So, in no particular order, here are the things I’ve really enjoyed about the service:

  • The administrative Dashboard is looks good and is relatively easy to use
  • There’s a short code that you can embed in your GitHub `README` that shows the status of the build: It’s broken, in deployment, or good to go.
  • Email notifications
  • Fantastic documentation
  • Flexible configuration such that you can script your own builds (if you want SFTP deployments, cool; if you can SSH deployments, cool as well)
  • Informative status pages for the progress of the build and deployment process
  • …and more that I’ve yet to need

Writing posts like this always feels a little odd because it may come off as sales-y or sponsored or something like that, but for those who have read for sometime know that this is not how I run this blog. This is me sharing something I’ve found useful as well as what I like about it.

Anyway, so perhaps the largest issue with Codeship is the learning curve that’s required to, say, setup environmental variables and scripts to get your deployment process running exactly right.

No, it’s not that complicated but if you’re, say, working with a custom script that will be using tools within their Linux environment, it takes some time to read through the documentation and the man pages for an application to make sure you get the script just right; otherwise, the build fails and you’re back at the drawing board.

For that, I recommend either SSH’ing into a web server of your own and trying out the command, meticulously reading the man page as well as looking at examples for how to achieve certain tasks, and then writing the commands based on said examples.

LFTP Man Page

LFTP For FTP Deployments

At any rate, everything has a learning curve of sorts and Codeship’s isn’t that large. Like anything, it takes a little while to learn how to do something, but once you’ve gotten familiar with how the system works, it’s pretty easy to keep moving forward from there.

With that said, Codeship is one of the best tools for continuous deployment that I’ve used and will likely continue to use in future projects (both WordPress-based and not).