Setting up a continuous integration server can help you down the path of automated deployments, even if you don’t have a comprehensive test suite.

We use CircleCI for our continuous integration. We set this up even for projects that have no automated tests. There are a number of reasons for this.

• It’s super simple to do. All you have to do is create a simple config file in your master branch and push it up. There’s some debugging required, and if you want to do more complicated tasks, you will spend more time, but the initial implementation of a code checkout is about 10 minutes.
• If your source code is compiled, and some of ours is, you can verify it compiles cleanly every time a commit is merged. This matters less for scripting languages like php or javascript.
• It’s free. Yes, you only get 1500 minutes, but we haven’t hit that yet. And once we do, you bet that it’ll be worth the monthly fee.
• It integrates transparently with Github, including for authentication.
• Once you have an automated build system, it’s easier to think about other deployment tasks that you can script. For example, creating artifacts like minified javascript, linting your code to make sure simple errors are found, or running database migrations.
• Setting up automation can also highlight manual build processes and make developers question their necessity.
• You build the foundation for automated tests. In my experience there are two hard parts of layering automated tests into an environment that doesn’t have them. Getting started and keeping going. CI doesn’t help with the former, but the first time an automated test catches a regression developers are typically sold on the value. But no developer is going to run a large suite of tests every time they check in code, so having an automated build environment waiting to execute that suite is worthwhile.

We went with external CI rather that internal because setting up your own CI server should be reserved for folks who need that level of customization and control, or who code to never leave their premises. At Culture Foundry we fall into neither of those sets. I haven’t used some of the competitors (Travis, Codeship) but have used Jenkins (and, dating myself, Hudson).

Having a continuous integration server of any kind is highly recommended because it starts the process of turning deployments from fraught manual processes that require humans to read from runbooks into automated regular occurrences that can take place often and are lower risk. You don’t have to have all your code tested to start down that path (this is another case of the perfect being the enemy of the good).