# Continuous Integration

## Continuous Integration (CI) vs Continuous Delivery (CD)

![CI/CD process](/files/XSRH6SIyJO72ac0wbZIe)

**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](/files/5qckWUhNoy5g573xA7k8)

## 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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://notes.dizy.cc/devops/continuous-integration.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.