# Continuous Integration

## Summary


Continuous Integration (CI) is the practice of routinely integrating code changes into the main branch of a repository, and testing the changes, as early and often as possible. Ideally, developers will integrate their code daily, if not multiple times a day. 

Martin Fowler, Chief Scientist at ThoughtWorks, has stated that, 

> Continuous Integration doesn't get rid of bugs, but it does make them dramatically easier to find and remove.

## Discussion

### Why do we need Continuous Integration?

In the past, developers on a team might work in isolation for an extended period of time and only merge their changes to the master branch once their work was completed. This made merging code changes difficult and time consuming, and also resulted in bugs accumulating for a long time without correction. These factors made it harder to deliver updates to customers quickly. 

With CI, each code change can potentially trigger a build-and-test process. Testing becomes an essential part of the build process. Bugs, if any, are highlighted early before they get a chance to grow or become hard to trace. Essentially, CI breaks down the development process into smaller pieces while also employing a repeatable process of build and test. 


### What are the benefits of Continuous Integration?

Among the many benefits of CI are the following: 

    + Shorter integration cycles
    + Better visibility of what others are doing leading to greater communication
    + Issues are caught and resolved early
    + Better use of time for development rather than debugging
    + Early knowledge that your code works along with others' changes
    + Ultimately, enabling the team to release software faster

### How does Continuous Integration work?

With continuous integration, developers frequently commit to a shared repository using a version control system such as Git. Prior to each commit, developers may choose to run local unit tests on their code as an extra verification layer before integrating. A continuous integration service automatically builds and runs unit tests on the new code changes to immediately surface any errors. 

Continuous integration refers to the build and unit testing stages of the software release process. Every revision that is committed triggers an automated build and test. 


### What are some CI tools and to choose among them?

There are many solutions out there. Some of them include Codeship, TravisCI, SemaphoreCI, CircleCI, Jenkins, Bamboo, and Teamcity.

Some factors to consider when selecting a tool include price (commercial or free), features, ease of use, integration (with other tools and frameworks), support (commercial or community) and more. 


### What are the challenges to Continuous Integration?

To improve and perfect your CI, you need to overcome 3 major challenges: 

    + **No Standalone Fresh Checkout**: The single biggest hurdle to a smooth CI build is ensuring that your application's tests can be run from a fresh code checkout (e.g. a git clone). This means that all of your app's dependencies are either included in the checkout, or they're specified and can be pulled in by a script in the checkout.
    + **Unreliable Tests**: Now that your app sets up with a single command, you've built a foundation for effective CI. The next challenge is to ensure that your test results are repeatable and reliable. Intermittent or "expected" failures that persist for too long are pernicious. Once the habit of treating failures as intermittent takes hold, legitimate errors often get ignored.
    + **Obscure Build Results**: Once you've produced a reliable test suite, the next challenge is to get results quickly, take appropriate action on them, and distribute information to the people who matter.

### How are Continuous Integration, Continuous Delivery, and Continuous Deployment practices related to one another?

Continuous integration leads to both continuous delivery and continuous deployment. Continuous deployment is like continuous delivery, except that releases happen automatically. 

More specifically, continuous integration requires automated testing to ensure that nothing is broken when new commits are made. Continuous delivery takes this to the next step by automating the release process so that your customers get regular fixes and upgrades.

Continuous delivery still requires manual intervention to initiate the final deployment to production. Continuous deployment automates this last step too. There's no "Release Day" as such. Customers see a steady stream of improvements and this enables early feedback. Since releases are small, they're less risky and easier to fix. Jeff Humble, author of the book *Continuous Delivery*, says this about Continuous Deployment, 

> Essentially, it is the practice of releasing every good build to users.

## Milestones

1991

Grady Booch first proposes the term **Continuous Integration (CI)**. In 1994, he uses the term in his book *Object-Oriented Analysis and Design with Applications*. 

1997

Kent Beck and Ron Jeffries invent **Extreme Programming (XP)** while on the Chrysler Comprehensive Compensation System project. Beck publishes about continuous integration in 1998. Extreme Programming embraces the practice of CI. 

2001

**CruiseControl**, one of the first open-source CI tools, is released.