Test your Continuous Integration knowledge with a free interactive quiz — 20 questions with answers and explanations. No signup needed to play.
Question 1/12Score 0
What is a "trunk-based development" workflow, and how does it relate to (and support) effective Continuous Integration practice?
In this round
What is a "trunk-based development" workflow, and how does it relate to (and support) effective Continuous Integration practice?
What is a "test pyramid," and how does its shape relate to a reasonable strategy for keeping a CI pipeline's test suite both comprehensive AND reasonably fast?
What is a "CI server" (or "CI/CD pipeline tool," like Jenkins, CircleCI, GitHub Actions, or GitLab CI), and what role does it play in a Continuous Integration workflow?
What is a "linting" step commonly included as part of a CI pipeline, alongside automated tests, and what kind of issues does it typically catch?
What is a "flaky test," and why is it considered a significant, specific problem for a Continuous Integration pipeline's effectiveness/trustworthiness?
What does it mean for a CI pipeline to "fail the build," and what is the typical expected response when this happens?
What is "code coverage" (as a metric sometimes tracked as part of a CI pipeline), and what does it measure?
What is the general relationship between "automated testing" (unit tests, integration tests) and Continuous Integration — why is CI generally considered most valuable/effective when paired with a solid automated test suite?
What is a reasonable way to think about the relationship between Continuous Integration and the broader goal of enabling Continuous Delivery/Deployment (CD)?
What is the purpose of running a CI pipeline against a "pull request" (or "merge request") BEFORE it's actually merged into the main branch, rather than only running CI after the merge has already happened?
What problem did Continuous Integration originally emerge to solve, particularly around the historical practice of "merge hell" or "integration hell"?
What is a general reason a team might specifically configure their CI pipeline to run different sets of checks depending on context — e.g. a fast subset of tests on every single commit, versus a fuller, more comprehensive (and slower) test suite run less frequently (like nightly, or only before a release)?