DEV Community

Cover image for Deploying Angular App to GitHub Pages using Travis CI.

Deploying Angular App to GitHub Pages using Travis CI.

Bartosz Gajda
Passionate and growth-minded Big Data Developer and Machine Learning enthusiast.
Originally published at ・5 min read

Travis CI can make your live much easier, especially if you are trying to continuously deploy and Angular app to GitHub Pages. I this tutorial you will learn how to set up such Continuous Integration and Continuous Deployment pipeline for Angular using Travis CI and GitHub Pages.

The goal of this tutorial is to set up the mentioned tools so that every pull request will result in automated testing which will reveal any errors in the code. In this case the Travis CI will configured so that any pull request to master or develop branch will result in firing such tests, although this can be configured to any branch as needed. The second automated job will be the deployment to GitHub Pages server. This part will include building our Angular application in production mode, and setting in on server to ensure that everything runs smoothly.


  • GitHub account — we will use it as code repository and deployment server (GitHub Pages)

  • Angular app — any app will do, you can generate a fresh one if not feeling to confident. I have used Angular 7 app for this tutorial.

  • About 10 minutes of your time

1. Creating the travis.yml file

Let’s start off by creating a configuration file for the our automation software. In the Angular project directory create a file called .travis.yml. Next add the following config into it:

dist: trusty
sudo: false

language: node_js
  - "10"

    - develop
    - master

  email: false

      - google-chrome
      - google-chrome-stable

    - ./node_modules

  - npm install

  - npm run test -- --watch=false --no-progress --browsers=ChromeHeadlessNoSandbox

  - npm run build -- --prod --base-href /IP3/
  - cp dist/IP3/index.html dist/IP3/404.html

  provider: pages
  skip_cleanup: true
  github_token: $GITHUB_TOKEN
  local_dir: dist/IP3
    branch: master

Now let’s analyze what is actually happening over there. Important — the IP3 name you see in the configuration file is just the name of my Angular project. You should change it to yours project name ( unless your project is also called IP3 :) ).

  • branches - here we specify code from which branches should be tested. In this case I have specified to use only master and develop branches, although there are more options available.

  • notifications - this is just a small add on that will prevent Travis from spamming your email account with messages about finished builds.

  • addons - the extra applications that will be necessary to run the tests. In our case it will be the latest stable build of Google Chrome.

  • cache - a directory that is supposed to be cached, which will increase the performance significantly.

  • install - the installation command to be used when setting up the dependencies. You can also use *yarn *if your prefer it.

  • script - the command that will fire the test for us. It is important to add the --watch=false flag, so that the command exits after running the tests and doesn't stay in the loop.

  • before_deploy - script run before the deployment process. In our case it is building the Angular app in production mode (and setting the base-href which is optional). The second thing is duplicating the index.html file and renaming it to 404.html, which will intercept any 404s being thrown by GitHub Pages server.

  • deploy - here we specify the information about our deployment server. In our case its the GitHub Pages, so we configure it as provider: pages. The github_token is the unique token that we will set on Travis website which will allow it to access our deployment server on our behalf. The last this is the on line where we say which branch should be used as build source. Any code pushed to this branch will also trigger the deployment process in Travis.

2. Configuring Travis CI

We have set everything up in the code, now it’s time to jump to Travis CI’s configuration panel. Start of by signing in to the Travis website. You can use your GitHub account which is probably much easier and faster to use. Then select the appropriate project, in my case it’s the IP3, and then go to settings tab.

Over there, what interests us is the Environment Variables section. Over there we need to provide the GitHub access token that will allow Travis to access our repository. To do this its best to use the official GitHub's guide. After generating one, paste it into value input and type in the token's name, in our case GITHUB_TOKEN.

And that’s it for the configuring Travis in the settings panel. There is also couple more options you can change but for the simplicity of this tutorial we will not dive too deep into that.

3. Setting up GitHub

The last part of this tutorial will be setting up our GitHub repository to actually make use of Pages service. To do this go to your project repository, and then to Settings tab. Over there you will find the configuration for Pages service looking similar to this:

The crucial part is selecting the right Source branch. I recommend using the default gh-pages. Disclaimer: Travis CI will always force push the changes done during the deployment phase, so if you don't want to loose all your Git history, do not use any of the main branches, like master or develop.

4. Testing

Now let’s create a new branch, push some changes to it and open a pull request so that Travis will run the tests. After merging the pull request the build will run and deploy our app into GitHub Pages. The steps are:

  • In the command line create a new branch: git checkout -b new-branch master

  • Make some change to any file. You can change something in app.component.html if you are not sure what to do.

  • Commit the changes with git add . and then git commit -m "Update the app template"

  • Push to the repository: git push origin new-branch

  • Using the GitHub, create a new Pull Request to master branch.

The last thing is to wait for Travis to successfully execute our tests and after that, merge the new-branch to master to trigger deploy build. After that our deployed app should be available at the address shown in the GitHub’s Settings tab.


I hope you have found this post useful. If so, don’t hesitate to like or share this post. Additionally you can follow me on my social media if you fancy so :)

Discussion (0)