Continuous Integration for Angular Projects with TravisCI

The journey of web development has been amazing for the past few decades. Standards have changed, practices have evolved and things are getting better and better for the web development world. For example, people moved from monkey patching code to MVC and design patterns. Companies and individuals both have been leaning towards TDD (Test Driven Development) instead of BDD (Business Driven Development). And last but not least, CI (Continuous Integration) and CD (Continuous Delivery) are getting more popular in the tech industry.

In this article, I’ll explain how you can set up Continuous Integration for your Angular projects on GitHub using TravisCI. This works for Angular applications as well as any angular libraries/plugins you create.

But WHY?

Before jumping into HOW, we’ll go through WHY. Why do we actually need to implement CI into our projects? Here are a few advantages of doing so:

1. It saves time for all the developers who run tests manually and makes sure everything works smoothly.
2. Developers find it difficult to remember which branches to test on and which they should ignore. No need to remember that any more.
3. No more ‘It works on my machine. Duh!’. With CI set up correctly, you can run the tests in environments of your choice.
4. To elaborate on #3, it makes it easier to replicate the production environment in your CI integration so you’ll know how it’ll work in production.
5. It’s just cool to implement CI.

So how do we do that?

I’ll be using this sample app to demonstrate the integration of TravisCI. I already added some Unit tests and End-to-End tests in the app. Here’s the code repository for the app. After we are done implementing the CI, we will have the ability to:.

1. Run Unit Tests
2. Run E2E Tests
3. Generate a production build
4. Deploy the production build on gh-pages for demo.

So let’s get started. First of all, I’ll create a branch named travis-ci in my project by executing the following:

git checkout -b travis-ci master

Now, we’ll go to https://travis-ci.org. Since I already have a Github account set up, I can quickly log in. You can sign up or login with your GitHub account. We will then enable the repository under my account from there. See the snapshot below:

Turning on TravisCI for our app

So we’ve got TravisCI turned on for our GitHub repo but it doesn’t actually do anything right now. We need to add a .travis.yml file at the root of our project. That file will tell TravisCI what to do. (i.e. which environment to work on, OS, language, version, branches to consider for CI, etc.)Here’s the YAML file we’re going to use (remember we switched to the branch travis-ci in our git repo). Let’s go through the contents of this file real quick.

• language: tells travis which environment is to be used for the pipeline. We’re using a node_js container for our tests.
• node_js: specifies which version of node_js to use. We could specify stable which would get the latest stable release and so on.
• The branches step configures which branches should execute the pipelines. For our configuration, we’re only interested in building for the master branch. See more options regarding branches here.
• The before_script phase executes before the run scripts and we’re actually installing a bunch of things for our testing environment, such as Google Chrome stable for running unit and E2E tests over it.
• The script phase contains the actual steps where we run our unit tests, e2e tests and then we generate a prod build which saves the build at dist folder.

After that, we use the pages service from GitHub to deploy our code by pushing the dist folder to gh-pages branch. We configured this only for the master branch for deployment. Notice the skip_cleanup flag set to true? It ensures that the build generated in the script phase and saved to dist doesn’t get wiped out.Lastly, for deployment, we’re setting github_token to $GITHUB_TOKEN which should be an ENV variable that we have to provide to TravisCI. But before that, we need to generate the token from our GitHub profile.I’ll do that by going to my GitHub Settings > Personal Access Tokens > Generate New Token as shown in below images.Note: Make sure to allow repo access in the scopes and to copy and save your generated token for later usage:

We have generated the token and copied to the clipboard, so we’ll go to the project’s settings page on travis-ci.org.

1. Turn on Build only if .travis.yml is present
2. Enter copied token and assign to variable GITHUB_TOKEN

Now since that’s taken care of, we can commit & push our .travis.yml to our GitHub repo. From there, we’ll create a Pull Request to master branch because we’ve configured TravisCI to execute the scripts and deploy only on master. See the snapshots below for that:

As soon as this PR is created, you will see that the TravisCI build is triggered for this PR.

The deployment will be skipped because this is a merge request. But upon merging, the deployment will be done. You can still see that the TravisCI build passed and updated the status on the PR’s page.

I’ve now merged the PR and the final code of the app is deployed here. Check it out, it is pretty cool 😉Last but not the least, you can add the build badge from TravisCI in your README or your website. You’ll see right from your repo’s page whether the current build is passing or not. Here’s how you can get the badge URL:

You can refer to my project’s README to see how I embedded the TravisCI build badge there.

Conclusion

TravisCI is a great tool for integrating CI into your projects (whether Angular or not). It is really simple to set up and implementing CI into plugins/projects adds an extra plus into your work. Everyone is doing it!Please show your support in any way you can! Feedbacks, claps, GitHub stars, anything is welcome. Thanks for reading