EXIN DevOps Foundation cheat sheet

DevOps is a cultural and organizational movement that unifies software development (Dev) and IT operations (Ops) around shared goals, shared tooling, and shared responsibility for the full service lifecycle.

DevOps is not a role, a team name, or a single tool; EXIN treats it as a mindset plus a set of practices that can be adopted incrementally by any organization.

The Three Ways (Gene Kim): (1) flow/systems thinking from Dev to Ops to the customer, (2) amplify feedback loops, (3) culture of continual experimentation and learning.

CALMS model: Culture, Automation, Lean, Measurement, Sharing - used as a checklist for assessing DevOps maturity in an organization.

Historical drivers: gap between business demand and IT delivery speed, high failure rates of large releases, siloed Dev and Ops with conflicting incentives (change vs stability).

DevOps sits inside the broader Agile/Lean family: Agile addresses planning and development cadence; DevOps extends the same thinking through deployment, operations, and feedback.

Key terminology: lead time (request to production), deployment frequency, MTTR (mean time to restore), change failure rate - the four DORA metrics.

Common misconceptions: DevOps means no operations staff, no documentation, or only CI/CD tooling; all three are false - operations expertise and documentation remain essential.

Benefit categories: faster time to market, lower release risk, higher deployment frequency, improved recovery, better employee satisfaction and cross-team trust.

The First Way (flow): optimize the whole value stream, make work visible, limit work in progress, reduce batch size, and never pass defects downstream.

The Second Way (feedback): shorten and amplify feedback loops so problems are detected and fixed close to their source; fast feedback beats perfect forecasting.

The Third Way (learning): allow experimentation, treat failure as information, and institutionalize improvement through blameless retrospectives.

Shift left: move quality, security, and testing activities earlier in the lifecycle; defects found earlier cost less to fix.

Shift right: extend monitoring, observability, and resilience testing into production, since real user behavior is the ultimate test.

Cross-functional autonomous teams own 'you build it, you run it' - the team that writes the code is accountable for its operation.

Systems thinking: local optimization (e.g., maximizing one team's utilization) usually degrades overall throughput; measure the whole value stream.

Small batch size and continuous flow reduce risk per change and shorten lead time; large infrequent releases increase both risk and coordination cost.

Blameless culture: post-incident reviews focus on systemic causes and process fixes, not individual punishment, so information is not hidden.

Continuous Integration: every change is merged to a shared mainline frequently and verified by an automated build plus automated tests.

Continuous Delivery: every change is kept in a deployable state and can be released on demand; Continuous Deployment goes one step further and releases automatically.

Infrastructure as Code: environments are defined in version-controlled, reviewable, repeatable files; immutable infrastructure replaces in-place mutation.

Version control is the single source of truth for code, configuration, and pipeline definitions; trunk-based development with short-lived branches reduces merge pain.

Automated testing pyramid: many fast unit tests, fewer service/API tests, few end-to-end UI tests; test automation gates the pipeline.

CI/CD pipeline stages typically: build, unit test, static analysis, package artifact, deploy to test environment, integration/acceptance test, deploy to production, verify.

Monitoring and observability: metrics, logs, and traces; alerting on symptoms (SLOs) rather than on every internal cause; dashboards visible to the team.

Containers and orchestration package applications with their dependencies for consistent behavior across environments; they do not by themselves constitute DevOps.

DevSecOps: security checks (dependency scanning, secrets management, policy as code) automated inside the pipeline rather than as a separate late gate.

Start with a value-stream map of one real service to identify wait time, handoffs, and the largest bottleneck; improve that constraint first.

Choose a pilot with a small, cross-functional team and a service that matters but is not business-critical; expand after demonstrable results.

Define outcome metrics before changing tools: lead time, deployment frequency, MTTR, change failure rate, plus a customer-facing measure.

Toolchain selection rule: pick tools that integrate with existing version control and CI, and prefer one well-adopted tool over many overlapping ones.

Automate the most painful, most repeated manual step first (often environment provisioning or deployment), not the most technically interesting one.

Adoption barriers: siloed incentives and reward structures, fear of blame after incidents, legacy architecture, and compliance interpreted as a ban on frequent change.

Governance fit: auditability can be preserved through pipeline logs, peer-reviewed infrastructure code, and automated policy checks rather than manual approval boards.

Change management: communicate the 'why', train teams, make improvement part of normal work, and expect resistance from middle management whose role shifts.

Anti-patterns: renaming an Ops team 'DevOps team' without changing behavior; buying a tool suite before defining the problem; measuring individual utilization instead of flow.