Travis CI
Mar 25 2020Continuous Integration & Delivery is an important aspect of DevOps methodology. It is surely a process which comes as a part of the whole DevOps cycle and many people misunderstand it for a simple deployment procedure. I’ve seen lot of projects saving time by correctly and effectively implementing their CI/CD flow. In recent past, I got a chance to work on one such CI/CD tool Travis CI and here is my experience with it. Travis is not new into the market and possibly many organizations are migrating from Travis because of it’s limitations as well. In this blog, I’ll share my experience on learning Travis.
Travis is quite easy to start with unlike Jenkins or any other CI/CD tool. For starters, all we need is a Github account and owner permissions for a project on Github. Post that, we need to link our Github account with the Travis account by authorizing the same. Now, the Travis dashboard looks something like this:
For Travis to run, everything is dependent upon .travis.yml file. Whenever a Travis build is triggered from any of our Github repos, the first thing Travis search for is .travis.yml file. A usual .travis.yml file looks like this:
Once we push the above file in the root of our Github repo, Travis detects it and triggers a build which is visible on the Travis portal
Also, we can see the commands which are executed as part of this build process on the build console:
Apart from providing configuration settings from .travis.yml file, we can also configure few options using Travis console settings. Travis CI console has limited options available if compared to other tools like Jenkins, GitLab. But few options like passing environment variables onto build jobs, setting build triggers based on branch push or pull requests and creating Cron Jobs are pretty neat. Below is how console settings look like:
We can also use Travis CLI to interact with Travis and get more information related to build jobs, monitor jobs as well. More can be read about the CLI client here: https://github.com/travis-ci/travis.rb
While I was working with TravisCI, I did face quite a few problems. Like, the options available to configure a job through console aren’t that many. In other words, build jobs are not that much customizable specially when it comes to setting up an automation workflow by using cron based triggers. Even we can’t define a custom time for cron based triggers to come into work. The moment we create a cron based entry for our build job, a minute after that it records the time for cron based triggers. So to summarize, there is no way to define cron tabs for a particular time in order to run our build jobs.
Travis CI is an old tool but it’s still widely used as it’s quite easy to configure and ready to get started with. It’s still one of the best tools for CI builds triggered directly from Github PRs/merges.