CI/CD for Angular projects using Travis CI and GitHub Pages.
Automation can make our lives much easier, especially if you are embracing the constant testing and delivery of the software in your team. I this tutorial you will learn how to set up such Continuous Integration and Continuous Deployment pipeline for Angular projects, 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 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 node_js: - "10" branches: only: - develop - master notifications: email: false addons: apt: sources: - google-chrome packages: - google-chrome-stable cache: directories: - ./node_modules install: - npm install script: - npm run test -- --watch=false --no-progress --browsers=ChromeHeadlessNoSandbox before_deploy: - npm run build -- --prod --base-href /IP3/ - cp dist/IP3/index.html dist/IP3/404.html deploy: provider: pages skip_cleanup: true github_token: $GITHUB_TOKEN local_dir: dist/IP3 on: 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 (https://travis-ci.com/). 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
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 (https://help.github.com/en/articles/creating-a-personal-access-token-for-the-command-line). 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.
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
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.