Continuous Integration with TravisCI

Goals

By the end of this lesson, you will:

• Understand what continuous integration is and why it’s important
• Be familiar with a typical deployment flow for agile teams
• Be able to implement TravisCI for continuous integration and automatic deployments for front end applications that use Jest

What is Continuous Integration

Continuous Integration is a jargony buzzword that means “releasing changes fast and often”. The goal of CI is to ensure stability by releasing smaller changesets at a time that are each fully tested. Many projects these days will rely on some sort of automated service to handle testing these changesets and facilitating frequent releases.

Some of the most common CI services you’ll hear about are TravisCI, CircleCI and Jenkins. They all behave in a similar manner, though the setup and configuration process for each tool is slightly different. Focus on integrating TravisCI to perform a full build of an application, test it using our test suite, and once that is finished, automatically deploy our changes to Heroku.

Why Use a CI Tool?

Being able to run and test a full build of your application before you release it to production is important. Think of how easy it was to deploy new changes to your production apps on Heroku. You would make a commit, and it would immediately be reflected on production after running git push heroku master. What if that commit introduced breaking changes? There is no safeguard or filter against pushing up bad code. With a CI tool like TravisCI, we can still take advantage of automatic deployments, but we also get an extra layer of assurance that our app is in good condition before any changes are pushed live.

TravisCI will also help you catch errors that you might not find locally. By more closely mimicking a production environment, we can recognize any differences that might be causing inconsistent behavior between environments. For example, if I am developing an app locally and I did an npm install(JavaScript apps) or bundle install(Ruby apps) months ago, and I did not explicitly lock down the version numbers for each of my dependencies in my package.json or Gemfile, I might not notice that my production environment received more updated packages during the npm install/bundle install phase. Some of these packages may have included breaking changes that would only be exposed in production, and impossible to reproduce locally until another npm install/bundle install was run.

Getting Started with TravisCI

1. Sign up for a TravisCI account here and login with your GitHub account.

2. Authorize TravisCI to access information about your GitHub repos (it’s ok)

3. Click the + button next to “My Repositories” on the left pane

4. Search for the name of the repository using the Filter repositories box (you might have to click the Sync account button on the top right)

5. Flip the switch!

6. Go back to your TravisCI dashboard (Click on the Travis CI icon on the top left of the page)

That’s it! Easy, right? Just kidding.

Now, any time you push new commits to your remote repository, TravisCI will automatically kick off a new build so you can keep an eye on the overall health and stability of your application.

Note: If you don’t see your repo after you’ve flipped the switch, try refreshing the page.

Configuring TravisCI

As you may have noticed, front-end repos are made up of 90% config files and 10% actual code. In order for TravisCI to be able to run our code and run our tests, we need to add a .travis.yml file to the root of our repository.

Any time TravisCI runs a build, it will look for this .yml file (pronounced “Yam-El”) and follow any instructions we provide.

What is a Build?

Think of all the steps you have to take if you want to collaborate on a classmate’s project. You have to fork their repo, clone it down locally, make sure you have an up-to-date version of Node (or some other platform) on your machine, install any dependencies, start up a server and maybe run a file watcher.

Sometimes more complex projects require additional steps. This setup process is called a build. It’s all the things you need to do to get your app up and running. CI tools will run through all of these steps (and then some!) to make sure the application is in a stable, working state before it goes to production.

Phases of the Build Process

The .yml file can define settings for various phases of the build lifecycle. In TravisCI, there are two main phases of the build lifecycle, three if you add on automatic deployment:

• install: install any dependencies required (configure the virtual machine (VM) to be able to run your code)
• script: run the build script (run your code and tests)
• deploy: deploy your code to your web servers (such as deploying to Heroku)

Getting Setup w/ Travis CI for FE Apps

The following instructions for getting setup with Travis CI are specific to React applications. We will start by creating a new .yml file!

"scripts": {
  "start": "react-scripts start",
  "test" : "jest --forceExit",
  "test:watch": "jest --watchAll"
}

"scripts": {
  "start": "react-scripts start",
  "build": "react-scripts build",
  "test": "react-scripts test --env=jsdom",
  "eject": "react-scripts eject"
}

language: node_js
node_js:
  - "node"

language: node_js
node_js:
  - "node"
notifications:
  email: false

gem install travis -v 1.8.10 --no-document

travis encrypt $(heroku auth:token) --add deploy.api_key --org

language: node_js
node_js:
  - node
notifications:
  email: false
deploy:
  provider: heroku
  api_key:
    secure: THISWILLBEUNIQUETOYOURHEROKUAPP
  app: cool-app-name
  skip_cleanup: true