Continuously Continuing to Integrate

5th February, 2016 - 4 minutes read

Now that we have all embraced Vagrant as part of our development process and the naysayers say ‘nay’ no more, we felt it was appropriate to move onto the next step and become involved with Continuous Integration (CI) in our dev process.

As I’m sure everyone is aware CI is essentially the process of continually updating an application with developer changes many times per day to ensure that a master or production branch of the application code is always maintained and deployable. As part of the CI process, there will be an automated testing phase to ensure master branch code does not contain any errors introduced through any new development changes.

Of course, continually integrating commits by multiple developers has its drawbacks and in itself requires the inclusion of more testing both by the devs on their own code on their local machine and within the automated testing phase (more on that later). Miro now requires all devs to rigorously test their code changes and once committed are tested again by another member of the development team prior to being merged into the master. When we merge into a master branch our CI platform performs some automated tasks and if these are successful it will deploy to our staging server.

Our chosen CI platform is CircleCI (http://circleci.com) as this has proved to be the clearest and most efficient to setup and use. We had reviewed others offerings such as CodeShip, AWS’ CodeDeploy and TravisCI but they didn’t provide as much clarity around our particular requirements or were limited in the number of builds that could be run per month. CircleCI included deployment to Amazon Web Services which was fundamental to our setup and once we had a handle on the configuration via the circle.yml file deploying became a breeze.

The circle.yml file provides all of the relevant information pertaining to the needs of the CI server that Circle creates and runs our tests against including PHP version, environment variables, database definitions and, of course, the test scripts. The CircleCI account settings are where we hook into our GitHub repository which, along with the branch config in the circle.yml means that any merge to our master triggers a build in our CircleCI account and the tests would begin.

The circle.yml file contains a deployment section that allows it to deploy directly to our AWS staging server (in our case an Elastic Beanstalk application) once all tests are passed.

Here’s a small snippet from our circle.yml file.

test:
override:
- casperjs test /path/to/your/script-tests.js
deployment:
staging:
branch: master
commands:
- sudo eb deploy name-of-the-aws-eb-application

As you can see the deployment section defines on which branch a deploy to the AWS EB application should be triggered, in our case master but it can, of course, be any branch.

Prior to this section, however, we have the detail about the tests to run against our code. We use CasperJS as our test utility to enable us to run through a number of workflows on the website application to make sure key functional items all operate as expected within both frontend and backend parts of the application. Any CasperJS tests that fail cause the CircleCI process to return a failure and the code not deployed. Conversely successful tests will follow with the call to deploy onto the AWS Elastic Beanstalk environment and, all being well, a new version of the application is made available to the world!

Tags: , ,