Using Codeship.io for testing RingoJS or other JVM-based applications
Continuous Integration and Continuous Deployment
If you have quick iterations, a various number of feature branches and a lot of code merges per day, Continuous Integration is the way to go. But also small projects can profit from it if the effort to setup a CI workflow is low. That’s why I’m using Codeship.io for some of my RingoJS-based projects. The setup takes only minutes and you get a nice and straightforward workflow. In my case every push to the repository on Github triggers a build on Codeship and runs the tests. For my personal cloud-based projects I use the App Engine integration to deploy the application if everything is fine. All projects I test via Codeship are fully open source, so my security concerns are low. If you want to use their service for more critical applications, they provide an overview over their security strategy.
After the setup commands you can execute your Ringo tests by invoking Ringo via the run.jar, which contains the previously built runtime. If your tests fail, Codeship will send you notifications and you can see the stack trace in the build’s output.
How a build looks like
All steps are listed in the details of a build. If a step fails, you can click on it and see the output on the console. Codeship shows you the author, the branch and SHA hash of the commit and how long each step took.
For me Codeship is a convenient addition to my workflow. In my opinion the biggest advantage is that you can always test your Ringo packages against the latest master from Github and don’t have to update your local clone / fork. I configure the build and define the test commands and every push to the repository will be tested without any exceptions. Just yesterday, you see this failed build in the first screenshot, I forgot to update my Datastore index definitions for a RingoJS-based Google App Engine application and Codeship immediately sent me an e-mail with an error report, which reduced the downtime to a minimum. On the other side you externalize your build workflow and this might not be a solution for everyone. You have to consider carefully whether an external CI-service will improve your workflow or if you keep relying on your local set of tools.