How we use Continuous Integration(CI)?

We’re going to keep this article focused on what continuous integration means to us, how we use it & not beef it up with standard definitions. 🙂

In a nutshell, continuous integration is automation in product testing & deployment/delivery.

We all maintain multiple environments for our products. At Visa Guide, we are currently maintaining 2 environments in AWS : development & production.

To push new code to these environments, we have to perform certain tasks for front-end as well as back-end.

Front-end tasks
  • Install npm / bower dependencies
  • Generate a new build using corresponding environment variables
  • Run tests
  • Copy paste contents of dist folder to AWS s3 bucket
  • Invalidate AWS CloudFront cache
Back-end tasks
  • Install composer dependencies
  • Generate a new build using corresponding environment variables
  • Run tests
  • Create zipped folder of project files
  • Create new application version in AWS EB application
  • Deploy new application version
  • Run migration scripts to update database

Even if you are not able to relate to some of the tasks mentioned above, continuous integration is still important for you because it is about automating your product’s specific needs, not implementing a template of tasks you can find online.

Let’s dive into how we could automate these tasks.

Step 1 : Setup your project at CI provider of your choice

There are many options to choose from today. Some of them are..

These providers give you computational power in cloud to automate your tasks & are built to address needs of product testing & deployment. For eg. they come with ready made hooks to your code repositories. Few clicks & your GitHub / BitBucket repositories are ready to sync whenever new code is pushed.

Of course, you could spin up your own servers to use as CI provider & DIY all integrations you need. But, I’d let the geek in you answer whether that’d be worth the effort. 😉

Having said that, it’d be definitely an overkill to implement build management (maintaining past builds) yourself, which these providers offer out of the box. A build is nothing but one cycle of executed tasks that may result in new code deployment, if error-free.

Once you nail down your choice, it usually involves creating a project by choosing a repository you want to run builds on.

Step 2 : Setup access for CI to communicate with your environment

You’d need to setup a way for your CI providers to communicate with your environment servers. Usually, this setup involves setting up SSH permissions.

Setting SSH permissions in CircleCI

Also, some popular cloud platforms provide a different way to grant access to services that manages environment servers in turn & your CI provider may provide you a way to set it up in easier fashion. For eg. AWS IAM allows setting up access keys to access to other services. Same can be used at CI provider as well.

Setting AWS access keys in CircleCI


Step 3 : Prepare configuration file & write bash scripts

As I have mentioned, CI is about automating your product’s specific needs. So, you need to have a way to configure CI in a unique way that meets your requirements. That’s why providers come with a way for you to maintain a configuration file. Sample is given below.

 build_dir: api
 # list of branches to build
 - master
 - development
 - cd ../webapp && npm install
 - cd ../webapp && bower install
# Install dependencies for deployment process
 - sudo pip install awscli
 - sudo apt-get install zip
 - sudo apt-get install curl
 # Cache the dependencies to speed up future builds
 - "../webapp/node_modules"
 - "../webapp/bower_components"
 # - cd ../webapp && ./node_modules/.bin/ember test
 branch: development
 - cd ../webapp && ./node_modules/.bin/ember build --environment=development --output-path=../dist
 - cd ../deployapp && /bin/bash
 branch: master
 - cd ../webapp && ./node_modules/.bin/ember build --environment=production --output-path=../dist
 - cd ../deployapp && /bin/bash

Tasks that you cannot cover directly via configuration file can be implemented in bash scripts & they can be referenced in configuration file to be executed at the time of deployment.

We have been using CI from the start & we have seen great advantages of having testing & deployment automated, from time saving to removing overheads & chances of manual errors in the process. Once you set it up, you’d know it’s not magic but ask a non-technical person to click on Merge pull-request button & once they do, tell them, Congratulations! You have just released our new version of a website / mobile app & you’d see on their face, it’s nothing less than a magic. 😉

Leave a Reply