What is Continuous Integration (CI)?

Continuous Integration (CI) is the practice of merging code changes into a shared branch frequently, where each change automatically triggers a build and an automated test suite so integration problems are caught within minutes instead of at the end of a release.

Start a Free Mock Interview

Free to start · 7-day trial on paid plans

IN DEPTH

In depth.

Before CI, developers worked in isolation for days or weeks and then suffered "integration hell" when merging. CI fixes this by making integration continuous: every push triggers a pipeline that builds the code and runs automated tests (unit, integration, often a fast subset of end-to-end), and a broken build is meant to be fixed immediately, before anyone moves on.

For QA, CI is where most automated testing lives. The fast feedback loop only works if the tests are fast and reliable, so flaky tests are especially damaging in CI (they erode trust in the signal). QA engineers design the test stages, decide what runs on every commit versus nightly, and keep the suite green. Test selection, parallelization, and flake management are core CI skills.

CI is the foundation the rest of the pipeline builds on. Continuous Delivery adds automated release-readiness on top of CI, and Continuous Deployment adds automatic release to production. You cannot meaningfully do either without solid CI first.

WHY IT MATTERS

Why interviewers ask about this.

CI is fundamental to modern QA and a near-guaranteed interview topic. Interviewers want to see that you understand fast, reliable automated testing as the heart of CI, and why flaky tests are so corrosive to it.

EXAMPLE

Example scenario.

A team adopts CI: every pull request triggers a build and runs unit and API tests in under eight minutes, blocking merge on failure. A regression that used to surface days later in QA now fails the PR within minutes, so the author fixes it while the context is fresh, and it never reaches the main branch.

TIP

Interview tip.

Define CI as frequent merges plus automated build and test on every change, then make the QA point: it only works with fast, reliable tests, which is why flake management is a CI-critical skill. Distinguish it cleanly from delivery and deployment.

FAQ

Frequently asked questions.

What is the difference between CI and CD?

CI (continuous integration) is merging and automatically building/testing code frequently. CD can mean continuous delivery (keeping code always release-ready, with the final release a manual click) or continuous deployment (automatically releasing every passing change to production). CI is the foundation both build on.

Why are flaky tests such a problem in CI?

CI depends on trusting the build signal. Flaky tests fail randomly on good code, so teams start ignoring or re-running failures, which masks real regressions and defeats the fast-feedback purpose of CI.