> For the complete documentation index, see [llms.txt](https://hanfak.gitbook.io/workspace/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hanfak.gitbook.io/workspace/devops1/ci-cd/continuous-integration.md).

# Continuous Integration (CI)

* [Continuous Integration (CI)](#continuous-integration-ci)
  * [What](#what)
  * [Why](#why)
  * [How](#how)
  * [Example workflow](#example-workflow)
  * [Team responsibilities](#team-responsibilities)
  * [Example](#example)

## What

* the practice of automating the integration of code changes from multiple contributors into a single software project.
* he CI process is comprised of automatic tools that assert the new code’s correctness before integration.
* A source code version control system is the crux of the CI process.
* The version control system is also supplemented with other checks like automated code quality tests, syntax style review tools, and more.
* development practice that requires developers to integrate code into a shared repository several times a day
* the process of automating the build and testing of code every time a team member commits changes to version control

## Why

* By integrating regularly, you can detect errors quickly, and locate them more easily.
* Because you’re integrating so frequently, there is significantly less back-tracking to discover where things went wrong
  * can spend more time building features.
* Continuous Integration is cheap
* No CI, leads to longer periods between integrations. This makes it exponentially more difficult to find and fix problems.
* Increase visibility enabling greater communication
* Catch issues early and nip them in the bud
* Stop waiting to find out if your code’s going to work
  * Especially just before deployment
* deliver software more rapidly
* Waiting days or weeks to integrate code creates many merge conflicts, hard to fix bugs, diverging code strategies, and duplicated efforts.
  * CI avoids this by integrating early and often
* CI keeps the master branch clean

## How

* Maintain a single source repository
* Automate the build
  * Use a CI tool that has a hook to your git repo on master branch
  * Tools like jenkins, teamcity, gocd
* Make your build self-testing
* Every commit should build on an integration machine
* Keep the build fast
* Test in a clone of the production environment
* Make it easy for anyone to get the latest executable version
* Everyone can see what’s happening
* Automate deployment

## Example workflow

* Developers check out code into their private workspaces
* When done, commit the changes to the repository
* The CI server monitors the repository and checks out changes when they occur
* The CI server builds the system and runs unit and integration tests
* The CI server assigns a build/binary label to the version of the code it just built
* The CI server releases deployable artefacts stored in an artefact repository for testing
* The CI server informs the team of the successful build
* If the build or tests fail, the CI server alerts the team
* The team fixes the issue at the earliest opportunity
* Continue to continually integrate and test throughout the project

## Team responsibilities

* Check in frequently
* Don’t check in broken code
* Don’t check in untested code
* Don’t check in when the build is broken
* Don’t go home after checking in until the system builds

## Example

![](/files/VU1NJCHRzHKMiYKk4xM3)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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://hanfak.gitbook.io/workspace/devops1/ci-cd/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.