Software, Development, and WordPress

Using Codeship For Continuous Deployment of WordPress Projects

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).


  1. Jason Bahl

    “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.”

    I actually like when folks write about tools they use. I’m always a fan of finding out how other folks make their workflows better. Thanks for posting!

    • Tom

      Sure thing, Jason. Glad you dig it :).

  2. Jon Brown

    Diito. I love when devs write about tools. That’s because they generally write about the things they actually use, the things they’ve tried and abandoned, and why they made that choice. This makes for much better reading than the dumb round up posts that simply list “5 deployment tools you could use”. Ugh, I hate those posts.

    One note here, you don’t specify when you use this? Ongoing site development? Offline theme development? Offline plugin development? Etc… While these could all be handled by one tool, maybe it doesn’t make sense to do that. I don’t know anyone writing tests for theme development, but maybe there are. Maybe it doesn’t matter if one has tests written beyond a syntax check, using CodeShip might still make sense.

  3. Manuel

    Hey Tom,
    thanks for the great write-up. I’m one of the co-founders of Codeship and it makes me extremely happy and proud to read articles like yours. Thanks for your nice words about our documentation. We still think it’s lacking a bit (for example how to work better in teams) – but we’re working on that. If you have any feedback about the docs our the service in general I’d love to learn about it.

    I’m glad Codeship can help you with your daily workflow.
    Thanks again for writing this article!


    • Tom

      Thanks so much for the comment, Manuel. As I continue to use Codeship and continue to get more involved with it, I’ll definitely provide feedback as needed.

  4. Akond Rahman

    Wow …great article ! Thanks for writing such a great blog post. I was curious what type of testing WordPress does as part of its continuous deployment process ? Does it conduct unit testing, functional testing, integration testing, and A/B testing ? How about code reviews ?

  5. Jason Resnick

    Hi Tom,

    This looks like a great tool for application/ecommerce sites. I’m curious your thoughts smaller sites, such as more of the brochure-ware type of sites for small businesses. These sites usually don’t have any sort of tests to run or build scripts to tie together environments. Would this be overkill?

    • Manuel Weiss


      co-founder of Codeship here. We have a lot of users that exactly fit that profile. It’s one of the main reasons we offer a free plan. Everybody should have a proper deployment workflow in place. Codeship can help a lot there.

      Feel free to give our free plan a try. I am happy to help with any questions.

      Have a nice day!

      • Jason Resnick

        Thanks Manuel… I may just do that. Only thing though is that I’d have to have ssh access right?

        • Manuel Weiss


          Codeship needs ssh clone access to github, that is correct. If I misunderstood your question let me know!



  6. Ahmad Awais

    Hey, Tom!

    Good read. I lead a pretty small team, but I have started to think about Continous Deployment after I read about it at WP Pusher’s blog. Codeship looks like a pretty good tool.

    • Manuel Weiss


      Co-founder of Codeship here. We would love if you gave Codeship a try! I myself, or my team via, are happy to help with any question you might have and with helping you setting up your first project.

      Have a great day!


  7. Julian

    May I ask, how do you handle WordPress Database changes when pushing code?

    • Tom

      It depends on the environment I’m using. Sometimes I’ll sync using WP Migrate DB Pro. Other times, I’ll use synchronization tools provided by a host (like Pantheon). And sometimes I don’t worry about changes in staging and development.

Leave a Reply

© 2020 Tom McFarlin

Theme by Anders NorenUp ↑