Continuous Integration

Continuous Integration with Travis CI

Continuous Integration (CI) vs Continuous Delivery (CD)

CI/CD process
Continuous Integration is the process of continuously integrating every developer's change into the master branch after a set of tests have passed, resulting in potentially deployable code.
Continuous Delivery is a series of practices designed to ensure that code can be rapidly and safely deployed to production by delivering every change to a production-like environment.

Traditional Development

  • Developers work in long lived development branches
  • Branches are periodically merged into a release (with lots of breakage)
  • Build are run periodically (e.g., nightly) on release candidate branch
  • Developers continue to add to the development branch which drifts further and further from the master branch

Continuous Integration

  • A development practice that requires developers to integrate code into a shared repository often (e.g., daily)
  • Developers work in short lived feature branches that are merged into master
  • Each check-in is then verified by an automated build, allowing teams to detect problems early and often

Changes are kept small

  • Committing regularly, every developer can reduce the number of conflicting changes: Checking in a week's worth of work runs the risk of conflicting with other features and can be very difficult to resolve
  • Using Pull Requests allows team members to communicate about the change they are making
  • Committing all changes at least once a day (once per feature built) is generally considered part of the definition of Continuous Integration

Every Pull Request should be built and tested

  • The system should build commits to the current working version to verify that they integrate correctly
  • A common practice is to use automated Continuous Integration where a continuous integration server or daemon monitors the revision control system for changes, then automatically runs the build process
  • Once the code is built, all tests should run to confirm that it behaves as the developers expect it to behave (i.e., make the build self-testing)

Benefits of CI/CD

  • Faster reaction times to changes
  • Reduced code integration risk
  • Higher code quality
  • The code in version control works
  • Less deployment time

Five Key Principles at the heart of Continuous Delivery

  • Build quality in
  • Work in small batches
  • Computers perform repetitive tasks, people solve problems
  • Relentlessly pursue continuous improvement
  • Everyone is responsible

A CI/CD Pipeline needs...

  • A code repository to host and manage all your source code
  • A build server to build the application from source code
  • An integration server/orchestrator to automate the build and run test code
  • A repository to store all the binaries and artifacts of the application
  • Tools for automatic configuration and deployment

CI/CD + Continuous Deployment

CI/CD + Continuous Deployment

Automation is key but insufficient on it's own

For business to take advantage of continuous integration and continuous delivery, they must:
  • Have an application design that allows services to be deployed quickly and independently
  • Have automated all of their testing
  • Have organizational trust that allows autonomy and shared responsibility
  • Have fast feedback loops with minimal Mean Time to Recovery

What is Travis CI?

  • Travis CI is a Continuous Integration tool
  • It allows you to treat your CI pipeline as code
  • It can also do deployments for Continuous Delivery

Continuous Delivery Goals

"Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time" — Martin Fowler.
That means:
  • The Master branch should always be ready to deploy
  • You need a way to know if something will "break the build"
Travis CI gives you a way to achieve this.

Know if the Build is Broken

  • Automated Testing is CRITICAL to Continuous Integration
  • Travis CI can work with any language and any test suite
  • Lots of languages and test suite support is built-in
  • Database support is built-in
  • Webhooks allow Travis-CI to run on every Pull Request
  • Status is delivered to the Pull Request before a merge