TravisCI: Overview and Working

      Travis CI is a hosted, distributed continuous integration service used to build and test software projects hosted at GitHub. It is basically a tool that helps you deploy software with confidence. It is like a middleman that protects you from breaking your code. 

      TravisCI easily integrates with popular Travis CI cloud repositories such as Bitbucket and GitHub. Without the need for a dedicated server, they offer many automated CI options that are hosted in the cloud. On different computers with different operating systems, this allows for testing in different environments.

      Now Let’s say you have created a project and published it on GitHub publicly and people all around the world are downloading, using, forking, and contributing. The community is thrilled. But what if there are massive amount of Pull Requests coming in that repository? Is your system is ready to take the load?
      CI/CD, which stands for continuous integration (CI) and continuous delivery (CD), creates a faster and more precise way of combining the work of different people into one cohesive product. In application development and operations (DevOps), CI/CD streamlines application coding, testing and deployment by giving teams a single repository for storing work and automation tools to consistently combine and test the code to ensure it works.

How does it work?

Continuous Integration

A CI process is a process in which the product is developed in any programming language and is automatically built using a set of instructions that are specified in the CI scripts. The flow might go something like this:

1.        Developers write code and commit changes to the repository

2.        CI server monitors the repository and evaluates all the changes

3.        CI builds the system and conduct required tests and scans

4.        The server releases deployable artifacts

5.        Build tag to the version assignment

6.        CI server reports the team about the successful build. If the scans fail, the server alerts about the event to the development team.

If all scans are passed, it means the code can be merged into the main branch.

Continuous Deployment

A CD process is a process that includes deployment of the artefacts on the server of any required environment. It takes the newly updated version artefacts and usually does the following:

1.        Creates an artifact and stores it.

2.        Deploys artifacts to the desired environment.

3.        Once the deployment is done post checks can be done.

What is Travis CI?

      Travis CI is an integration tool which allows the user to execute any important operations like scans on their specific branch before merging to the master branch of that repository .

      Travis CI tool can easily integrate with the common cloud repositories like GitHub and Bitbucket. This allows you to test on different environments, on various machines, running on different Operating Systems.

What does Travis do?

      Travis CI works by pulling the code you have written and committed to GitHub, and then running a series of tests that you’ve defined. Once the tests are done, and the builds are complete, it can push the updates to your servers for you. Instead of running all these tests by hand and then deploying your code, you can focus almost entirely on your code. More time building, less time checking for structural integrity.

Benefits:

• Monitoring GitHub projects
• Runs Test and generate results quickly.
• Build artifacts
• Checking code quality
• Easy Deployment to cloud services
• Developers can use Travis CI to watch the tests when they are running.
• The tool integrates with Slack, Jira, Vault, etc.

Travis CI Features:

• Integration with GitHub
• Repository access to build pull requests
• Multi languages support
• Pre-installed build & test tools
• Deployment to multiple cloud services
• Encrypt secure environment variables or files
• Virtual machines recreated after every build
• CLI client and API for scripting

How can it help?

      Take for example a repository which internally reads some json files from the same repository to fetch the values for the execution. You’re writing default values for the parameters that are required by the system on runtime. You make sure the values are correct and cross-checked with the release notes. You upload it, and all of a sudden you hear a report that json file is not readable and the code is no longer working. You track it down and it turns out that this is happening because of a formatting issue like extra space , special characters, Missing curly braces, etc.

      While correcting the format of file usually challenging work or as it might take a longer to identify even the smallest human mistake, but it’s usually not the most interesting way to spend your time. This is even more true if the values in these files doesn’t often get updated.

      Contrast with a CI implementation that’s set up to look for json file formatter: You write your update, save and commit, and then go about your business. A few moments later, you get an email saying there was a problem with the build. A quick look tells you what the problem is, and you fix it. Save, commit, and once more, you go on your way. A few moments later you once more get an email, but this time, it’s a success! You’re now confident that all the files are properly formatted and system is not having any issues reading those, and not just that, you can also set Travis up to upload to your result (through many, many methods) when all tests are successful. You don’t even need to spend time.

Connecting TravisCI with GitHub

      To connect your Travis CI and GitHub accounts together you need to sign into Travis with your GitHub account, you’ll be automatically brought to your most recent builds.

      Here you should be able to see all the repositories from your account, as well as a list of all the organizations you belong to on GitHub. To use Travis, you’ll first need to activate it on the repository you’d like to work on by checking the button next to it. Once you activate a repository, Travis will start listening for changes.

This requires a .travis.yml configuration file to run. When you push a commit to GitHub, travis looks for the .yml file and executes the commands written in that file. Below is the simple example of the travis.yml file:

      As per the above travis example- by default, all Travis builds run in our container-based macOS build infrastructure as there is ‘osx’ specified as operating system. However, the build is required the use ‘python‘ as a language with the specified version as ‘3.9’.

      All the build environments in TravisCI comes with some pre-installed packages by default, but if in case anyone needs a dependency that the default build images doesn’t have. In this case - with the before_install command, the required packages can be installed or any task can be executed.

      The script section is where the scripting part of that build is written. In the above example as we can see there are 3 commands are getting executed in which the script is calling an external shell script which internally execute the scanning in the repository files

      Once the .travis.yml file is finished setting up in your repository, from then onwards when you push changes to GitHub, Travis CI should pick it automatically and test the project, so the developer can be sure that their code has gone through all the tests you intended and ready to merge with the master branch.

Summary

In this article, we learned about CI/CD automation process and how it saves you a lot of time and money, and increases the productivity and value you can provide your end-users. We also learned how to integrate a CI/CD process using travis CI into a project on GitHub.

This is the first blog in the series of the blogs that will be published for TravisCI. More blogs will be published over next few months. If you have any further queries on TravisCI, do feel free to email ashish.sonawane@ibm.com 

Author Details:     Ashish Sonawane (ashish.sonawane@ibm.com)

Reviewer Details:  Ashish Kothekar (ashish.kothekar@in.ibm.com)
                              Boudhayan Chakrabarty (bochakra@in.ibm.com)