GISI ADO Level key terms

A way of organizing software work that joins development and operations teams around shared goals, automation, and fast feedback so changes reach users quickly and safely.

A model describing DevOps across five areas: Culture, Automation, Lean flow, Measurement, and Sharing. It is used to assess how far an organization has moved beyond tool adoption.

The continuous loop of plan, build, test, release, deploy, operate, and monitor activities. Each stage feeds information back into the next, replacing a one-time handover from development to operations.

A technique that charts every step a change passes through, from request to production, and measures waiting time versus work time to expose bottlenecks and waste.

The elapsed time between a code change being committed and that change running in production. It is one of the four DORA metrics and reflects pipeline and review efficiency.

How often an organization successfully releases to production. A DORA metric that tends to rise when batch sizes shrink and deployment is automated and repeatable.

The share of production deployments that cause degraded service and require a hotfix, rollback, or incident response. It measures release quality rather than release speed.

The average time needed to recover service after an incident or failed deployment. Short values usually indicate good observability, automated rollback, and rehearsed response procedures.

A structured review after an incident that documents the timeline and contributing causes without punishing individuals, so people report honestly and systemic fixes are identified.

A distributed version control system that stores project history as an immutable graph of commits, letting every clone hold the full history and branch cheaply.

A snapshot of the tracked files plus metadata such as author, timestamp, message, and parent commit identifiers. Each commit is content-addressed, so identical content yields the same identifier.

A movable pointer to a commit that lets work proceed independently of other lines of development. Branches are cheap in Git because only the reference moves, not the history.

A state where two branches changed the same lines of a file and Git cannot choose automatically. A developer must edit the marked regions and commit the resolution.

A hosted-repository request to merge one branch into another, providing a place for diff review, automated checks, and approval before the change lands.

A repository setting that blocks direct pushes to a branch and can require passing status checks, signed commits, or a set number of approvals before merging.

A named reference to a specific commit, commonly used to mark release versions. Annotated tags carry a message, author, and date and are preferred for releases.

A branching model where developers integrate small changes into a single shared mainline at least daily, using short-lived branches and feature flags instead of long-lived divergent branches.

A practice where every pushed change triggers an automated build and test run, so integration problems surface within minutes rather than at the end of a release cycle.

An ordered set of automated stages, such as compile, unit test, scan, and package, that runs on each change and reports a single pass or fail result.

A worker machine or container that executes pipeline jobs assigned by a central server. Agents are often pooled and ephemeral so each run starts from a clean environment.

Using scripts and frameworks to run repeatable checks, from unit to end-to-end, without manual steps. Reliable automated tests are the safety net that makes frequent integration possible.

A fast, shallow check that a newly built or deployed system starts and its critical paths respond. It is used as a gate before deeper testing or wider rollout.

A versioned store for build outputs such as packages, container images, and binaries, so the exact tested artifact can be promoted unchanged into later environments.

A build output that is never modified after creation. Any change produces a new version, which guarantees that what was tested is exactly what gets deployed.

A numbering convention of major, minor, and patch versions where each part signals backward-incompatible, additive, or fix-only changes respectively, letting consumers judge upgrade risk.

A practice where every change that passes automated checks is kept in a deployable state and can be released to production at any time with a manual approval decision.

An extension of continuous delivery in which every change passing all automated gates is released to production without human intervention, relying on strong tests and fast rollback.

The automated path a change travels through successive environments, with quality gates at each stage, from build to production, making releases repeatable and auditable.

A release technique that runs two identical environments and switches traffic from the live one to the newly deployed one, enabling near-instant rollback by switching back.

Sending a small share of live traffic to a new version first and comparing error rates and latency before widening exposure, limiting the blast radius of a bad release.

A runtime switch that enables or disables functionality without redeploying code, allowing decoupling of deployment from release and rapid disabling of a faulty feature.

Returning a system to a previously known-good version or configuration after a faulty change, ideally automated and fast enough to keep outages brief.

Keeping development, test, staging, and production environments similar in runtime versions, dependencies, and configuration so behavior observed in testing predicts production behavior.

Defining servers, networks, and cloud resources in versioned text files that tools apply automatically, making environments reproducible, reviewable, and auditable like application code.

A style of describing the desired end state of a system rather than the commands to reach it, letting the tool work out and apply whatever changes are needed.

The property that applying the same operation repeatedly produces the same result as applying it once, which makes automated provisioning and configuration safe to re-run.

A file mapping declared resources to real infrastructure identifiers. It lets the tool plan changes against actual resources and must be stored securely and shared through a remote backend.

A two-step workflow where the tool first shows the difference between declared and actual infrastructure, then executes only the approved changes.

A model where servers or containers are replaced rather than patched in place. New versions are built from images, which removes configuration drift and simplifies rollback.

The gradual divergence of real systems from their declared or expected configuration due to manual edits and partial updates, which causes inconsistent behavior across environments.

The discipline and tooling used to define, apply, and enforce consistent settings across many machines, such as packages, files, and services, from a central source of truth.

Storing, distributing, and rotating credentials such as passwords, tokens, and keys in a controlled vault rather than in code or plain configuration files.

A documented procedure for a recurring operational task or alert response, giving on-call engineers concrete steps and reducing recovery time under pressure.

The ability to understand a system's internal state from its outputs, typically by correlating metrics, logs, and traces so unexpected questions can be answered without new code.

Recording a request's path across services with shared trace and span identifiers, which reveals where latency accumulates in a multi-service call chain.

Emitting log records as machine-parsable key-value data, usually JSON, so entries can be filtered, aggregated, and correlated reliably instead of parsed from free text.

A target range for a measured reliability indicator, such as the percentage of requests served under a latency threshold, used to decide when to slow or halt releases.

The amount of unreliability a service-level objective permits over a period. Spending it justifies pausing risky changes; leaving it unused justifies shipping faster.

Desensitization caused by too many low-value alerts, leading responders to ignore or delay action on real incidents. It is reduced by alerting on symptoms and tuning thresholds.

Granting identities and automation only the permissions strictly needed for their task, which limits the damage a compromised account or misconfigured pipeline can cause.

A token, key, or role assumed by automation to deploy or access resources. It should be scoped narrowly, short-lived where possible, and never committed to source control.

A commit whose authorship is cryptographically verified with a key, letting branch rules and reviewers confirm that the change came from the claimed identity.

Scanning a project's third-party dependencies for known vulnerabilities and license issues, usually run in the pipeline and gated against a severity threshold.