Sometimes I come onto a project and there is no continuous integration or tests. I like working with tests and using a continuous integration setup, especially when working with others. I also think that a project’s quality will increase and the speed also increases when we get automated feedback from continuous integration.

Typically a good first step for me is to get some basic tools running. Before I even write any tests, I get some basic sanity checks in place. If I am running in a Ruby environment, for example, I may run some static analyzers and fail the build if they fail. I might also check that every Ruby file that we have at least passes ruby -c (which checks for syntax errors. In JavaScript-land, this might take the form of jshint or another linter. In compiled languages, just ensuring that you can compile your code might be enough.

I ensure that the tools work locally first, fixing any issues needed and relaxing overzealous rules. Then I make a script that runs whatever tools that I want to run. This enables the team to run it locally and makes it easy to run on a server. Then I would get a basic CI environment running that script.

Approaching CI in this manner demonstrates value early. These checks ensure a base level of quality, and retain value even after tests are added as a smoke test. If your files have syntax errors, they are likely to not be right, so I can fail the build early and get faster feedback and use fewer testing resources. If the build fails at this point, there are some potential process problems or inefficiencies that can be sorted out.

Going small early de-risks setting up a CI server and writing tests. Once you have a basic setup, it is fairly easy to add other checks, including automated tests. Also, CI vendors encourage a low cost of change to move to a different CI environment, so there is little lock-in.

I like running these kinds of tests before committing or pushing code in case I missed something obvious while writing or rebasing. These checks are typically pretty fast, so the extra time is not a big deal. I will generally think of what I want my commit message to be or consider if I missed something. There are tools to run checks like these continuously or when files change as well.

The event that prompted this post was realizing that I had various important JSON files that held either system configuration or managed dependencies. By at least ensuring that they were valid JSON, we prevent a whole class of problems from ever happening.

What simple issues could a basic CI setup help you prevent on your project?