{"id":329,"date":"2016-05-01T12:51:51","date_gmt":"2016-05-01T10:51:51","guid":{"rendered":"https:\/\/blog.unetresgrossebite.com\/?p=329"},"modified":"2016-05-01T14:14:42","modified_gmt":"2016-05-01T12:14:42","slug":"circle-ci","status":"publish","type":"post","link":"https:\/\/blog.unetresgrossebite.com\/?p=329","title":{"rendered":"CircleCI"},"content":{"rendered":"

\"CircleCI<\/a><\/p>\n

A few months ago, starting a job for a client I never worked with before, I was asked to write unit tests to familiarize myself with their product, and find a way to run these tests whenever a coworker would push his changes\u00a0to GitHub. Testing our code requires a blank Riak database and a blank Redis server.\u00a0Back then, I looked at several solutions such as Jenkins<\/a> or TeamCity<\/a>,\u00a0in combination with Docker. Although I also considered services such as Travis<\/a> and the one we’ll focus on today: CircleCI<\/a>.<\/p>\n

I didn’t knew of Travis and CircleCI before looking into running my own unit tests, which is a shame. Both service will provide you with free virtual machines within EC2, running unit tests according to some yaml file, describing how to setup your environment and validate your code works. The main difference between relies in billing.
\nCircle is free as long as you only run one build job at a time. You may pay to run concurrent jobs.
\nTravis is always free for opensource projects\u00a0–\u00a0as long as your repository is publicly available. You may pay to run tests against private repositories or\u00a0to run concurrent jobs.
\nThe big advantage behind such services is that you may easily install, configure and run\u00a0dependencies your test will require. Setting up Postgres, MySQL, Redis or Riak databases, set a version for NodeJS, Go, PHP, python, …. And they provide with ways of testing Android and iOS applications as well.
\nBoth will Circle and Travis will run your test from private VMs by default, although both would allow you to eventually enable SSH and forward some port\/ip combination to your instance, so you may troubleshoot your tests while they’re running.
\nIn terms of GUI, both services offer with a clean and relatively-lightweight way to track your jobs as they’re running.\u00a0Back when I had to choose, CircleCI GUI was performing better on my old laptop, hence I can’t tell much more about Travis.
\nBoth are integrated to GitHub, and will allow you to enable running automated tests on a per-repository basis, as well as pick the branches you need to build (or ignore).<\/p>\n

\"Tracking<\/a>

Tracking Tests on CircleCI<\/p><\/div>\n

The first thing you need, running automated unit tests, is your unit tests. In my case, the project is a nodejs-based webservice. API documentation is pretty straight forward. I started with a small set of checks (is the service responding, does it fail when I try to call commands without authenticating?). Over the next days, I was able to check all our API calls, making sure our documentation was correct, and that error code were consistent when\u00a0feeding\u00a0these calls with incorrect arguments. Depending on your project, you may not need to get into this much trouble.<\/p>\n

\"circle.yml\"<\/a>

circle.yml<\/p><\/div>\n

Having your unit tests ready, the next thing you\u00a0need is a Makefile, or set of script that would\u00a0initialize your databases (if applicable), install your nodejs\/ruby\/python\/php dependencies (if applicable), … you should be able to easily run\u00a0every step required, having fetched the last revision of your repository, to run your service.<\/p>\n

Now that you can easily start and run tests against your service, you may focus on configuring CircleCI creating a\u00a0circle.yml<\/em>, at the root of your repository. In there, you will tell CircleCI what it needs to do to run your tests. Consider the base system is a Ubuntu 12.04 (precise), and may be changed to 14.04 (trusty). You may define environment variables, enable pre-installed services, install what could be missing. Your commands are issued as the ubuntu<\/em> user, although you have unrestricted access to sudo. There’s much to say,\u00a0feel free to\u00a0give a look at their\u00a0documentation<\/a>.<\/p>\n

\"circle<\/a>

circle jobs<\/p><\/div>\n

Having figured out a way to properly run your tests, and granted that your set of tests is “exhaustive enough”, then you will be able to spot mistakes in the next few minutes of their being pushed.<\/p>\n

Moreover, for those familiar with Slack: you easily\u00a0setup notifications. — and the others should definitely look into Slack<\/a>, I’ll probably post something soon about it, as I was able to get rid of lots of mail and SMS spam, sending my notifications (cron or nagios) there, and still getting notifications on my phone using their Android app: even if you do not work with teammates, Slack can make sense.<\/p>\n

Back on Circle, last but not least, having successfully passed your tests, those of you using CodeDeploy\u00a0(something else I should write a post about) may trigger a deployment, achieving both Continuous Integration and Continuous Delivery.<\/p>\n

\"Slack<\/a>

Slack Integration<\/p><\/div>\n

The\u00a0screenshot on the right shows our Slack thread: our team ends up deploying several times a day, errors\u00a0are spotted as they are pushed to GitHub, whereas the one on the left shows the end of a successful test, that ended up in pushing code to our staging setup.<\/p>\n

\"circle<\/a>

circle unit tests done<\/p><\/div>\n

To conclude, I had my first experiences with CI & CD about 8\u00a0months ago, and was not completely sold on the idea to begin with. I always assume that when I push code, I did test it, and so did my colleagues. Although Continuous Integration definitely helped, in forcing our whole team spotting and quickly fixing whatever mistake someone would have pushed. And at some extent, it sometimes leads me to push “theoretical” patches without even testing them, knowing CircleCI would eventually yell at me, …<\/p>\n","protected":false},"excerpt":{"rendered":"

A few months ago, starting a job for a client I never worked with before, I was asked to write unit tests to familiarize myself with their product, and find a way to run these tests whenever a coworker would push his changes\u00a0to GitHub. Testing our code requires a blank Riak database and a blank […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[8,10],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.unetresgrossebite.com\/index.php?rest_route=\/wp\/v2\/posts\/329"}],"collection":[{"href":"https:\/\/blog.unetresgrossebite.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.unetresgrossebite.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.unetresgrossebite.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.unetresgrossebite.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=329"}],"version-history":[{"count":16,"href":"https:\/\/blog.unetresgrossebite.com\/index.php?rest_route=\/wp\/v2\/posts\/329\/revisions"}],"predecessor-version":[{"id":351,"href":"https:\/\/blog.unetresgrossebite.com\/index.php?rest_route=\/wp\/v2\/posts\/329\/revisions\/351"}],"wp:attachment":[{"href":"https:\/\/blog.unetresgrossebite.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=329"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.unetresgrossebite.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=329"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.unetresgrossebite.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=329"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}