Travis-CI
Last updated
Last updated
I’m pretty sure that you must have heard those two terms(CI & CD). But sometimes you might not know exactly what CI & CD is. So here I’m gonna give you that brief introduction.
When we are developing applications first we need to build the application. Sometimes we may need to run unit tests before making the build to make sure that they are passing. Likewise there could be several other tasks that need to be done after a developer pushes a new commit to the version controlled repository. After every commit a new build of the application should be created.After building the application now it’s ready to be deployed to a hosting platform(Github Pages, Firebase or any custom platform).
Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.
By integrating regularly, you can detect errors quickly, and locate them more easily.
As mentioned early those tasks(running unit tests, creating the build, deploying the application, etc.) become crucial when several developers work and commit their work to a shared repository. A commit made by a developer with a change in the code should be integrated with the base code and should reflect in the deployed instance without wasting time of the developer. That’s where continuous integration and continuous deployment comes in.
You’ve created something amazing. You’ve published on GitHub. People are downloading, using, forking, and contributing. The community is thrilled. But are you ready for the oncoming glut of Pull Requests?
Continuous Integration/Continuous Delivery (“CI/CD”), two terms so frequently mentioned together they’ve been fused into one concept, refers to the automation of such repetitive tasks as testing, building, and deploying software. Over time, it has become an invaluable tool in maintaining a productive and functional team.
A CI process is a process in which software is developed by multiple sources and is automatically integrated via an established procedure. The flow might go something like this:
Push to Git;
A process is triggered;
The relevant branch is pulled, the app is built, and tests are run;
The results of this process are sent to whom it concerns.
If all tests pass, it means the code can be safely (well, safely in the areas the tests cover) be merged into the main branch.
A CD process is a process that usually follows the merge process. It takes the newly merged version and usually does the following:
Runs tests (usually longer and more end-to-end (“E2E”)-type tests than those run during CI processes);
Creates an artifact and stores it;
Deploys to production (or pre-production);
Runs post-production E2E tests. You’d usually set up a rollback trigger using the pre-made artifacts folder in case of failures during post production.
Many tools can help you create a CI/CD process. One shiny and easy to use tool is Travis CI. In the sections that follow, I’ll show you step-by-step how to integrate an existing project with Travis CI and set up a simple CI/CD process.
The project is a web component library that currently only features a modal window. Here’s the GitHub link.
It currently has a test and build flow (via npm run test:prod and npm run build). It has a demo that is deployed manually to Firebase Hosting. You can see the demo here.
Most CI tools integrate seamlessly with Git services — especially GitHub. Go to travis-ci.com and sign up. I suggest logging in with your GitHub account — it’ll make things easier at later stages.
Inside Travis CI, there is a search bar on the left side of the screen; Click the + sign below it.
If you connected your GitHub account, you should see a list of your existing repositories, from which you can add:
A list of your projects. Well… mine. I guess React users would leave this article now ;)
Search for the relevant project (in my case, web-components-ui-elements) and click the nearby switch.
Red is the switch, blue is the settings :)
After it is enabled, click on the settings button (indicated by a blue arrow above). Now you should see several settings. I encourage you to read about each option in the Travis CI documentation and choose the setup that suits you. We will use the default settings for this tutorial.
Now that the backend is setup, let’s connect the project from the code end to Travis CI.
Most CI tools expect a configuration file to exist in the project. Travis CI expects a .travis.yml file to exist in the project root.
Let’s see how we build a file in Travis CI:
Let’s go over the parts:
language — We use JavaScript, but Travis calls it “node_js” (fine by me);
node_js — Pretty straight forward as well; we just state the version we want to use;
script — That’s just a set of bash commands to run. In our case, we echo some useful comments, install our dependencies (using Yarn) and then run our tests.
As mentioned above, the CI process mainly makes sure we didn’t break anything and that we are ready to merge/integrate. So this phase will include the following process: Clone -> yarn/npm install -> test
We also want to speed up our builds, so we‘ll tell Travis to cache our npm or Yarn folder (or any other package manager you are using — Travis supports many).
We’re using Yarn; let’s tell Travis to cache the Yarn folder:
You can read more about caching here.
The moment you push a change, Travis will trigger the build process.
Process started — Yarn, cache and tests are now running.
Click here to see the results.
On the results page, you can see the summary (the process passed or failed) at the top. Below, you can view the job’s log and see our echos and the whole output of the CI process.
In this case, I pushed to a pull request. On GitHub, you can see the results in the Pull Request (“PR”) page like this:
Tests are running.
Once the process passes, you will see the change on GitHub:
Yahoo! We can merge to master now!
Testing is just one step in the CI process. You can add more lines to the script stage, including processes like linting, E2E tests, performance tests and whatever metric you can think of to test new code before you merge it to the main code base
