How to Use Travis CI to Automate CI/CD

You hear about companies like Amazon and Google deploying code thousands of times a day. While your organization may not require that level of frequency, you no doubt need the ability to innovate rapidly. And thanks to cloud and DevOps, these privileges aren’t available only to the unicorns.

Here at nClouds, as part of every transformation initiative, we use continuous integration (CI) and continuous delivery (CD) processes and tools – CI/CD pipelines – to enable customer teams to deliver code changes more frequently and reliably. CI provides a consistent and automated way to build, package, and test applications. CD automates the delivery of applications to infrastructure environments. We consider CI/CD pipelines the cost of entry for optimizing your AWS cloud infrastructure.

One of the decisions you need to make is which CI/CD tool to use—and there are many good ones. In this blog post, we’ll talk briefly about the benefits of CI/CD as well as some of the popular tools available. And we’ll drill into Travis CI to show you how to build a CI/CD pipeline. Watch for future posts on other tools, including AWS CodePipeline and CircleCI.

Why is CI/CD important to your company’s success?

In today’s competitive market, your success depends on how quickly you can innovate. From our experience, many organizations waste time battling with deployment-related issues – time that could be spent delivering value to end customers.

The foundation of innovation is a CI/CD pipeline that enables development teams to deliver code changes more frequently and reliably in a sustainable way. It’s all about speeding time to market by shortening the development lifecycle while keeping software deployable throughout the cycle.

How do you achieve this speed? By applying automation to delivery and testing of builds, to integration tests for new commits, as well as to deployment and release of software versions. CI/CD enables rapid feedback on code issues, which not only speeds your process but also results in improved software quality.

For example, a startup can use rapid prototyping to try out a technology stack against the existing infrastructure and see how a system will perform without actually having to build it. In this way, you can quickly validate your features and avoid possible bottlenecks and risks.

Why should every developer care about CI/CD?

Here are some reasons you should care:

• Spend less time finding bugs or the location of the bugs if they exist.
• Get alerts as soon as you break the build.
• Develop and iterate faster.
• No need to spend days preparing for a release – deploy-release is automated and replicable.
• No longer sit waiting for a build to finish only to find that it failed at the end.
• Spend less time testing, so more time is available to focus on improving quality.

What tools are important for CI/CD?

At nClouds, we use a variety of CI tools such as Travis CI, CircleCI, and Jenkins. We also use release orchestration/analytics tools like AWS CodePipeline, deployment tools like AWS CodeDeploy, and configuration tools like Ansible, Chef, and Terraform.

As a result, our customers can:

• Build and test code changes more quickly.
• Obtain immediate feedback on the success of code changes.
• Ship code to production faster and with confidence.
• Have secure keys and builds.

How do we decide which tool to use? It depends on the needs of the development team for a project. There are a number of factors to consider – here are a few:

• Are you working on an open-source project that needs to be tested in different virtualization environments and operating systems, e.g., Ubuntu Precise, Ubuntu Trusty, OS X, and Windows? Travis CI is designed to do this.
• Want release orchestration? AWS CodePipeline builds, tests, and deploys your code whenever there is a code change, based on your release process models.
• Looking to automate code deployments to any instance? Use AWS CodePipeline.
• Need a continuous integration server? CircleCI supports Ruby on Rails, Sinatra, Node, Python, PHP, Java, and Clojure.
• Are you working on a big project where you need to do a lot of customization using plugins? Jenkins has over 400 plugins to support building and testing.
• Do you have a small project or static site? With Ansible, you can deploy without needing to build/test.

What we like about Travis CI

Some of the key capabilities of Travis CI that we particularly like:

• Quick start: Get set up in seconds.
• Easily customize your build configuration.
• Auto-deploy passing builds.
• Auto-cancel jobs when new ones are triggered.
• Excellent dashboards that are easy to use, and live build views.
• Out-of-the-box build matrix.
• Pre-installed database services.
• No dedicated server required.

How to Use Travis CI to Automate CI/CD

We often use Travis CI to automate deployment to the AWS account. In such a case, Travis CI is triggered to automate the ECS cluster update or trigger AWS CloudFormation templates. How do we do this? Here’s the step-by-step process:

1. Create a Travis CI Account.
   • Go to the Travis CI website and click Sign Up.
   • Click Authorize Travis CI to log in with your GitHub credentials, then enter your GitHub password.
   • When you’ve logged in, click your picture to go to profile settings.
   • Find the sfdx-travisci repository and turn on Travis CI for your repo.
2. Configure Travis CI parameters. Add the Travis file (.travis.yml) to the root directory of the repository to set the programming language used, determine the infrastructure that your environment is running on, and other parameters. A complete list of environments and operating systems is available in the Travis CI documentation.
3. Define the infrastructure in the Travis file by using different tags in the configuration. For the OS tag, select from the following values:
   • Linux: Can be Ubuntu Precise or Ubuntu Trusty, further defined by other tags such as sudo and dist, as shown in the Travis CI documentation.
   • Windows: Only Windows Server 2016 is currently supported. More detail on packages, tools, and settings available in the Travis Windows CI environment is shown in the Travis CI documentation.
   • OS X: Travis CI uses OS X 10.13 and Xcode 9.4.1 by default. The version of the operating system is defined by tags such as osx_image. You can use another version of OS X (and Xcode) by specifying the corresponding osx_image key.
4. Choose a programming language. Travis CI provides a default build environment and a default set of phases for each programming language. Travis CI works with:
   ANDROID, C, C#, C++, CLOJURE, CRYSTAL, D, DART, ERLANG, ELIXIR, F#, GO, GROOVY, HASKELL, HAXE, JAVA, JAVASCRIPT (WITH NODE.JS), JULIA, NIX, OBJECTIVE-C, PERL, PERL6, PHP, PYTHON, R, RUBY, RUST, SCALA, SMALLTALK, SWIFT, VISUAL BASIC
5. Customize the job lifecycle. A build can be composed of many jobs. A job is an automated process that clones your repository into a virtual environment and then carries out a series of phases such as compiling your code, running tests, etc. There are two main parts to a job:
   1. install: Install any dependencies required. Here are examples of optional tags you can use in the Travis file:
      • before_install:
        • execute all the commands that need to be executed before installing dependencies
        • i.e., composer self-update
      • install:
        • install all the dependencies you need here
        • i.e., composer install — prefer-dist
   2. script: Run the build script. Here are some examples of optional tags you can use in the Travis file:
      • before_script:
        • execute all the commands before running tests
        • i.e.,
          • mysql -u root -e ‘CREATE DATABASE test’
          • bin/doctrine-migrations migrations:migrate
        • script:
          • execute all the commands that should make the build pass or fail
          • i.e.,
            • vendor/bin/phpunit
            • vendor/bin/php-cs-fixer fix –verbose –diff –dry-run
6. Deploy to AWS. When the build has passed the script of the job, it is marked as a pass/fail job and you can act in each of the cases using the following tags:
   • after_success, after_failure, after_script or after_deploy: A non-zero exit code in this phase does not affect the status of the build.¹
   • Before_deploy: A non-zero exit code in this phase will mark the build as errored.
   • Deploy: An optional phase in the job lifecycle is deployment. This phase is defined by using a continuous deployment provider to deploy code to Heroku, Amazon, or a different supported platform. The deploy steps are skipped if the build is broken.

     Sources: Breaking the build and Deploying your code in Travis CI documentation.

   To deploy on Amazon ECS using secure keys and environment variables, use the AWS Command Line Interface (CLI) to assign an AWS Identity and Access Management (AWS IAM) policy to an IAM user. For this setup, we need to add some secrets on Travis CI, which are the access keys to the AWS account for our Travis CI user. Travis CI will always hide the values of secret variables even if you attempt to show them in the output.

    

   

   Source: Travis CI documentation, “Defining variables in repository settings.”

   Once we have the environment variables set on Travis CI, we can continue with the AWS CLI commands as follows:

   aws ecs list-tasks --cluster $CLUSTER_NAME --service-name $SERVICE_NAME --query 'taskArns' --output text
   aws ecs describe-services --region $AWS_DEFAULT_REGION --cluster ${CLUSTER_NAME} --service $SERVICE_NAME
   aws ecs describe-task-definition --task-definition $TASK_NAME --region $AWS_DEFAULT_REGION
   aws ecs register-task-definition --region $AWS_DEFAULT_REGION --family $TASK_NAME --container-definitions "$CONTAINER_DEFINITIONS" --task-role-arn "$TASK_ROLE_NAME"
   aws ecs update-service --region $AWS_DEFAULT_REGION --cluster ${CLUSTER_NAME} --service $SERVICE_NAME --task-definition $TASK_ARN
   aws ecs run-task --cluster $CLUSTER_NAME --task-definition $TASK_NAME
   

   We can configure this script in one executable file in the Travis file as follows:

   before_deploy: "echo 'ready?'"
   deploy:
     - 'if [ "$TRAVIS_PULL_REQUEST" = "false" ]; then ./deploy.sh; fi'
   after_deploy:
     - ./after_deploy_1.sh

   Source: Running commands before and after deploy in Travis CI documentation.

7. Integrate notifications with Slack. Go into Settings on Travis CI and add the account_id and access token to interact with the Travis API. We can manage this by using the following syntax on the Travis CI file:

   notifications:
     slack:
       rooms:
         - :#development
         - :#general
       on_success: change # default: always
       on_failure: always # default: always

   Source: Configuring slack notifications in Travis CI documentation.

8. Use stages on your jobs to build more quickly. A stage is a group of jobs that run in parallel as part of a sequential build process composed of multiple stages.Let’s say that you need to build two separate applications. If your two builds are independent but the deployment of them is the push of the output of each build to S3, you will save time by doing the deployment in stages, as illustrated below:

   jobs:
     include:
       - stage: run tests
         script:
         - exec_ios_test.sh
       - stage: run tests
         script:
         - exec_webgl_test.sh 
       - stage: build app
         script: ./build-app-for-webgl.sh

   Source: How to define build stages in Travis CI documentation.

9. Use a build matrix to specify multiple parallel jobs with a single .travis.yml configuration file. You can define names for specific jobs within a matrix, as illustrated below:

   language: python
   matrix:
     include:
     - name: "3.5 Unit Test"
       python: "3.5"
       env: TEST_SUITE=suite_3_5_unit
     - name: "3.5 Integration Tests"
       python: "3.5"
       env: TEST_SUITE=suite_3_5_integration
     - name: "pypy Unit Tests"
       python: "pypy"
       env: TEST_SUITE=suite_pypy_unit
     script: ./test.py $TEST_SUITE

   Source: Naming jobs within matrices in Travis CI documentation.

To learn more about how nClouds collaborates with our customers using CI/CD pipelines to build sustainable systems for delivering quality software faster, take a look at our DevOps Consulting Services page and nClouds customer cases studies.

We’d love to hear from you…

What tools are you using to automate CI/CD? How have those tools helped your company innovate? Share your thoughts and tips in the Comments section below.

Reference sources:

https://docs.travis-ci.com/user/reference/overview/#virtualisation-environment-vs-operating-system
https://docs.travis-ci.com/user/reference/windows/
https://docs.travis-ci.com/user/languages/
https://docs.travis-ci.com/user/reference/osx/#os-x-version
https://docs.travis-ci.com/user/job-lifecycle/#the-job-lifecycle
https://docs.travis-ci.com/user/job-lifecycle/#breaking-the-build
https://docs.travis-ci.com/user/notifications/