Skip to content

2.6 DevOps Practices

← 2.5 Technical Collaboration | Home | Next: 2.7 Language Theory & Low-Level →

Continuous Integration / Continuous Delivery / Continuous Deployment

The concept of Continuous Integration (CI) was originally proposed by Grady Booch in 1991. Its core proposition is associated with Version Control Systems: integrating developers' work to the mainline at least once a day to reduce integration problems.

The definition was soon broadened. Now, CI implies the existence of a CI Server (such as Jenkins) that, once a new change is made to the mainline, executes a pipeline that verifies every integration with an automated build to detect errors as quickly as possible. This quick detection of problems makes fixing them much cheaper than in traditional approaches.

Concept Meaning
Continuous Integration (CI) Frequently merge code to trunk; each merge automatically triggers a build pipeline (compile + unit tests + static analysis) to detect issues quickly.
Continuous Delivery (CDelivery) On top of CI, code is always in a deployable state, but deployment to production requires human approval. Suitable for B2B and government projects.
Continuous Deployment (CDeployment) No human intervention—every passing change is automatically deployed to production. Suitable for B2C products (Facebook and Netflix deploy hundreds of times per day).

CI is the essential practice that serves as a basis for the other two. The more frequent the integration, the smaller the merge conflicts.

Build Automation

Build automation refers to scripting the manual steps of compiling, packaging, and testing so that they can be executed automatically by a CI system without human intervention after each commit. Core elements: - Build tools (Maven, Gradle, npm, Make, Cargo, etc.). - Artifact repositories and image registries (Artifactory, Nexus, Docker Registry) for storing build outputs. - Configure once, execute repeatedly—eliminates the "works on my machine" problem.

Test Pyramid

       /\
      /E2E\         Few end-to-end tests: validate critical user flows
     /------\
    /Integration\   Mid-layer integration tests: verify interactions between modules
   /----------\
  /  Unit Tests  \   Broad base of unit tests: verify individual functions/methods
 /--------------\
  • Unit tests: The broadest base. Test individual functions/methods; run extremely fast; no external dependencies. Should cover all core logic.
  • Integration tests: Test multiple modules working together (database access, API calls). Slower than unit tests but catch interface mismatches.
  • End-to-end (E2E) tests: Simulate real user operations through complete flows. Slowest, most fragile, but validate the most critical user paths. Cover only core scenarios.

The pyramid shape: the lower the level, the more tests, the more stable, the faster. The higher the level, the fewer tests, the more fragile, the slower.

Feature Flags / Feature Toggles

Dynamically enable or disable features in production via configuration, without requiring redeployment. Core value: - Decouple deployment from release—code is live but the feature is invisible to users. - Support canary releases: open to 5% of users first, then gradually expand. - Support instant rollback: turn off the flag instead of rolling back the deployment. - Support A/B testing. - Enable Trunk-Based Development: unfinished features stay hidden behind flags.

Sources

  • Romen Rodriguez-Gil — Continuous Integration, Delivery and Deployment: Key Differences: https://www.romenrg.com/blog/2017/12/31/continuous-integration-delivery-deployment/

← 2.5 Technical Collaboration | Home | Next: 2.7 Language Theory & Low-Level →