DevOps, Infrastructure as Code and Platform Engineering

Introduction and Context

Cloud computing has changed the economics and architecture of software delivery. Infrastructure can be provisioned through APIs, applications can be deployed globally, and capacity can be adjusted programmatically. However, the technical availability of cloud resources does not automatically produce reliable delivery. Organisations may still experience slow release cycles, configuration drift, security weaknesses, inconsistent environments, and unclear operational ownership.

DevOps addresses these problems by treating software delivery and operation as a connected socio-technical system. It combines collaboration, automation, measurement, and shared responsibility. Infrastructure as Code (IaC) extends software-engineering practices to infrastructure, while platform engineering creates reusable internal capabilities that allow development teams to deliver safely without mastering every underlying cloud service.

This chapter examines continuous integration and continuous delivery, GitOps, IaC, configuration management, testing, policy as code, artifact security, and internal developer platforms. The emphasis is not on one vendor or tool but on principles, architectural choices, governance, and trade-offs.

Learning Objectives

By the end of this chapter, students should be able to:

1. Explain the relationship among DevOps, CI/CD, IaC, GitOps, and platform engineering.

2. Design a secure and observable delivery pipeline.

3. Compare declarative IaC with imperative automation and configuration management.

4. Apply testing and policy controls across the software supply chain.

5. Evaluate internal developer platforms using technical and organisational criteria.

6. Analyse governance, security, cost, reliability, and team implications of automation.

1. DevOps as a Socio-Technical Operating Model

DevOps is best understood as an operating model rather than a product or job title. It integrates development, operations, security, quality engineering, and business stakeholders around the flow of value from an idea to a reliable service. Its central assumptions are that teams should receive rapid feedback, repetitive work should be automated, and those who build services should retain meaningful responsibility for their operation.

A useful model is the delivery lifecycle:

Plan → Code → Build → Test → Release → Deploy → Operate → Observe → Learn

This is a feedback loop rather than a one-way sequence. Operational data should influence design; security findings should influence coding; and deployment outcomes should influence automation and capacity decisions.

DevOps commonly seeks improvements in four dimensions:

• Delivery speed: how quickly a validated change reaches users.
• Stability: the reliability of services and deployments.
• Recovery: the speed with which service is restored after failure.
• Learning: the quality and speed of feedback from production.

These dimensions must be balanced. Maximising deployment frequency while increasing change failure is not necessarily progress. Similarly, eliminating all change may improve short-term stability while reducing innovation and creating technical debt.

Continuous Integration, Continuous Delivery, and Continuous Deployment

Continuous integration (CI) means that developers integrate changes into a shared repository frequently, with automated compilation, testing, and analysis. CI reduces the cost of integration by identifying conflicts and defects near the time they are introduced.

Continuous delivery means that software is maintained in a deployable state and can be released through a controlled, usually automated process. A production release may still require a human approval or a business decision.

Continuous deployment goes further: every change that passes the defined controls is automatically released to production. It is appropriate only when testing, observability, rollback, organisational confidence, and risk controls are sufficiently mature.

A pipeline should be viewed as a sequence of evidence-producing controls, not simply a chain of scripts. Typical stages include:

1. Source validation, code review, and secret detection.

2. Dependency resolution and reproducible build.

3. Unit, integration, contract, security, and policy tests.

4. Creation and signing of immutable artifacts.

5. Deployment to an isolated environment.

6. Verification using health checks, smoke tests, and telemetry.

7. Progressive production release, such as canary or blue-green deployment.

8. Monitoring, rollback, and post-deployment analysis.

Pipeline design should make the secure path the easiest path. Manual exceptions may be necessary, but they should be visible, time-limited, and audited.

2. Delivery Architecture and Operational Metrics

A mature delivery system separates the application source, build process, artifact repository, deployment configuration, and runtime environment while preserving traceability among them. A production system should be able to answer: which source revision produced this artifact, which dependencies were included, who approved it, which infrastructure version deployed it, and what happened after deployment?

Useful delivery metrics include:

• Deployment frequency: number of successful production deployments in a period.
• Lead time for changes: elapsed time from code committed to code running in production.
• Change failure rate: proportion of deployments causing a failure requiring remediation, rollback, or urgent intervention.
• Time to restore service: elapsed time from an incident or failure to restoration of acceptable service.

Metrics need precise definitions. For example, if a period has 40 production deployments and 4 require rollback or urgent remediation, the change failure rate is 4/40 = 10 percent. A team must define whether partial degradation, security remediation, or planned rollback counts as failure. Metrics should support learning rather than employee punishment; otherwise teams may conceal failures or avoid valuable changes.

3. Infrastructure as Code

Infrastructure as Code represents infrastructure resources, relationships, and configuration in machine-readable definitions maintained through version control. Resources may include networks, identity policies, databases, compute instances, containers, queues, and monitoring rules.

Declarative and Imperative Approaches

An imperative approach specifies the steps to perform: create a network, then create a subnet, then attach a route. A declarative approach specifies the desired state: a network with particular subnets, routes, and policies must exist. The IaC engine determines the actions required to converge actual state toward desired state.

Declarative systems offer several benefits:

• repeatability across environments;
• reviewable change history;
• dependency modelling;
• drift detection;
• automated planning;
• consistent destruction and recreation procedures.

They do not eliminate risk. A declarative change can still delete production data, expose a service, or create excessive cost. Plans must be reviewed, tested, and subject to access controls.

State, Drift, and Idempotence

Many IaC tools maintain state describing resource identities and attributes. State permits the tool to compare desired configuration with known infrastructure. It is sensitive and may contain identifiers or secrets; it therefore requires encryption, access control, versioning, locking, and backup.

Drift occurs when actual infrastructure differs from the declared or recorded state. Causes include console changes, emergency interventions, provider-side changes, and incomplete automation. Drift can be detected by refresh operations, cloud inventory comparison, configuration scanners, or periodic reconciliation. A mature organisation treats manual changes as exceptional and records them as code as soon as possible.

An operation is idempotent when applying it repeatedly produces the same intended result after the first successful application. Idempotence is important for safe retries, but it does not mean that every execution is risk-free. A resource replacement can be idempotently planned while still causing downtime or data loss.

IaC Design Principles

1. Modularity: package reusable networks, identities, clusters, or service templates with clear interfaces.

2. Versioning: pin provider and module versions where reproducibility matters.

3. Small changes: use focused pull requests and inspect execution plans.

4. Environment separation: isolate development, test, and production accounts or projects where practical.

5. Secure defaults: deny unnecessary network access, encrypt data, and require logging.

6. Explicit ownership: identify the team responsible for each module and resource.

7. Controlled state: use remote, encrypted, locked state with restricted access.

8. Lifecycle awareness: model backups, retention, replacement, and decommissioning.

IaC should not become a large collection of copied templates. Abstraction is valuable only when it reduces cognitive load without hiding important consequences.

4. Configuration Management and Runtime Consistency

IaC usually provisions infrastructure; configuration management establishes software and operational settings on that infrastructure. Examples include operating-system packages, users, service configuration, certificates, agents, and hardening controls.

Configuration management may be agent-based, agentless, image-based, or container-based. In immutable infrastructure, a new machine image or container is built with the required configuration and replaced rather than modified extensively in place. In mutable infrastructure, a running system is updated through automation. Immutable approaches often improve reproducibility, while mutable approaches may be practical for legacy systems or stateful environments.

Configuration should be externalised from application code when it varies by environment, but secrets must not be stored as ordinary configuration. Secret managers, short-lived credentials, workload identity, rotation, and audit logging are preferable to static credentials in repositories or pipeline variables.

5. GitOps and Reconciliation

GitOps uses a version-controlled repository as the authoritative source for desired operational state. An agent in or near the target environment continuously compares the desired state with the actual state and reconciles differences. This creates a pull-based operational model: the environment retrieves approved changes rather than exposing broad deployment credentials to an external pipeline.

A common GitOps structure separates:

• application source repositories;
• artifact repositories containing immutable images or packages;
• environment repositories containing deployment manifests and policies;
• controllers that reconcile those manifests with clusters or services.

GitOps provides auditable change history, repeatability, and automatic recovery from some forms of drift. It is particularly common with Kubernetes, although the principles can apply to other platforms.

GitOps has limitations. Git is not a replacement for an observability system, a secrets manager, or an incident process. High-frequency runtime data should not be committed to Git. Emergency changes need a controlled break-glass process, and reconciliation must not overwrite legitimate operational actions without understanding their purpose. Repository compromise is also a serious supply-chain risk, so branch protection, signed commits or tags, least-privilege deploy keys, and review controls are important.

6. Testing the Delivery and Infrastructure System

Testing must cover both software behaviour and the delivery system itself. Important categories include:

• Unit tests: verify small program components in isolation.
• Integration tests: verify interactions with databases, queues, APIs, or cloud services.
• Contract tests: verify that service interfaces remain compatible.
• End-to-end tests: validate representative user journeys, although they are often slower and more fragile.
• Infrastructure validation: check resource topology, syntax, dependency relationships, and expected plans.
• Policy tests: verify security, compliance, cost, and organisational rules.
• Resilience tests: examine failure of dependencies, zones, credentials, or network paths.
• Deployment tests: verify health, readiness, migration behaviour, and rollback.

Testing strategy involves trade-offs. Fast tests should run early and frequently. More expensive tests can run in later stages or periodically. A green pipeline does not prove correctness; it proves only that the defined checks passed. Test suites must be maintained, flaky tests investigated, and test environments designed to resemble production where the tested property depends on infrastructure behaviour.

Database migrations illustrate the importance of deployment design. A destructive schema change may not be compatible with older application instances during a rolling deployment. A safer pattern is expand-and-contract: add a compatible field or table, deploy code that can use both versions, migrate data, then remove the old structure in a later controlled change.

7. Policy as Code and Governance

Policy as code expresses organisational or regulatory rules in machine-evaluable form. Examples include:

• storage must be encrypted;
• public network exposure requires an approved exception;
• production resources require an owner and cost centre;
• container images must originate from an approved registry;
• workloads must run without privileged access unless explicitly authorised.

Policies may be evaluated before deployment, during IaC planning, at admission to a platform, or continuously against running resources. Preventive controls stop non-compliant changes; detective controls identify violations; corrective controls attempt remediation. No single control is sufficient.

Good policy is specific, testable, explainable, and proportionate. A policy that rejects every unusual configuration may drive unsafe workarounds. Exceptions should include a reason, owner, expiry date, compensating controls, and review trail. Governance should distinguish genuine risk from mere deviation from a preferred implementation.

8. Artifact Security and Software Supply Chains

A software artifact is a versioned output such as a container image, package, binary, or deployment bundle. Artifact security begins with provenance: knowing how, where, and from which source an artifact was produced.

Important controls include:

• trusted and minimal base images;
• dependency pinning and vulnerability scanning;
• software bills of materials (SBOMs);
• isolated and reproducible builds;
• artifact signing and signature verification;
• protected registries and immutable tags;
• malware and secret scanning;
• rapid revocation and rebuild processes;
• provenance attestations linking artifacts to source and build instructions.

Vulnerability scanning is not equivalent to security. A scanner may report a vulnerability that is not exploitable in the deployed context, or miss a newly disclosed issue. Risk-based triage should consider exploitability, exposure, data sensitivity, available mitigations, and remediation time. Organisations should also plan for compromised dependencies and build systems, not only vulnerable application code.

9. Internal Developer Platforms and Platform Engineering

Platform engineering creates a product-oriented internal platform for application teams. The platform may provide service templates, deployment workflows, identity integration, observability, databases, queues, secrets access, security controls, and cost information through consistent interfaces.

The platform team is not merely an infrastructure ticket queue. It should discover developer needs, publish a clear product catalogue, define supported paths, measure user experience, and retire capabilities that no longer provide value. A platform should offer a golden path: a well-supported route for common workloads. Golden paths should be recommended and easily accessible, not necessarily mandatory for every unusual workload.

A platform commonly has four layers:

1. Underlying cloud and cluster layer: networks, compute, storage, identity, and availability.

2. Operational capabilities: deployment, scaling, secrets, logs, metrics, traces, backup, and recovery.

3. Developer interfaces: templates, command-line tools, portals, APIs, and documentation.

4. Governance and guardrails: policies, cost controls, security checks, and auditability.

The platform must balance standardisation and autonomy. Excessive standardisation suppresses legitimate architectural diversity; excessive autonomy recreates fragmented operations. Product usability is a reliability concern: confusing interfaces and hidden defaults lead to misconfiguration.

Artificial intelligence can assist platform engineering by generating templates, summarising pipeline failures, suggesting policy fixes, and correlating telemetry. Such systems require human review, protection against secret disclosure, provenance for generated code, and controls against confidently incorrect recommendations. AI should accelerate engineering judgement, not replace accountability.

10. Integrated Case: Illustrative Online Retail Platform

Background

Consider an illustrative online retailer operating a web application, product catalogue, payment service, and order-processing system across multiple cloud regions. Development teams deploy irregularly. Production changes are often made manually, infrastructure differs between environments, and a failed release once caused several hours of order delays.

Problem Analysis

An assessment identifies four root causes. First, infrastructure is created through undocumented console actions. Second, deployment packages are rebuilt during release, so the tested artifact is not always the deployed artifact. Third, security checks occur after production deployment. Fourth, platform knowledge is concentrated in a small operations group, creating a queue for routine changes.

The organisation also measures success primarily by deployment count. This encourages frequent but poorly controlled changes and provides little insight into recovery or customer impact.

Approach

The retailer establishes a product-oriented platform team and introduces the following design:

• application code is reviewed through protected Git repositories;
• CI builds immutable container images once and records provenance;
• unit, integration, dependency, and secret scans run before publication;
• images are signed and stored in a protected registry;
• IaC defines networks, identities, databases, and observability resources;
• environment configuration is held in separate, reviewed repositories;
• a GitOps controller reconciles approved deployment state;
• policy checks reject public storage, missing ownership metadata, and unsigned images;
• progressive deployment releases a small traffic percentage first;
• logs, metrics, traces, business transactions, and deployment events are correlated;
• teams receive templates for standard web services, workers, and scheduled jobs.

Emergency access remains available but requires strong authentication, time limitation, logging, and subsequent reconciliation into code.

Outcome

The new system improves traceability and reduces environment inconsistency. Developers can create a standard service without waiting for a bespoke infrastructure request. Operators gain a consistent audit trail and can detect drift. The retailer does not claim that automation eliminates incidents; instead, it reduces the probability and impact of common failures and improves recovery.

Learning Points

The case demonstrates that tools alone do not produce DevOps. The improvement comes from connecting version control, artifact identity, policy, infrastructure, deployment, observability, and team ownership. It also illustrates why platform engineering must be treated as an internal product and why metrics should include stability and recovery, not only speed.

11. Challenges, Limitations, and Trade-offs

Complexity and tool proliferation: Numerous tools can create fragmented credentials, inconsistent user interfaces, and maintenance burden. Tool selection should begin with capabilities and operating constraints rather than popularity.

State and destructive change: IaC state, database migrations, and resource replacement can create irreversible outcomes. Backups, plans, approvals, and tested recovery procedures remain essential.

Cloud-provider dependence: Managed services accelerate delivery but may create portability, pricing, and operational dependencies. Portability should be evaluated according to business risk, not treated as an absolute goal.

False confidence in automation: Automation reliably repeats both good and bad decisions. Controls need meaningful tests, review, monitoring, and periodic reassessment.

Organisational resistance: DevOps changes incentives and boundaries. Teams may resist shared ownership if on-call demands are unreasonable or platform interfaces are poor. Workload, skills, and service-level expectations must be designed together.

Security concentration: A central platform may become a high-value target. Strong identity, separation of duties, credential minimisation, logging, and independent review are necessary.

Cost and environmental impact: Automatically provisioned resources can remain unused, while excessive telemetry and repeated builds consume money and energy. FinOps controls, lifecycle policies, rightsizing, and efficient build design should be integrated into the platform.

12. Best-Practice Decision Framework

When designing an automated delivery system, ask:

1. What is the smallest safe change that delivers the required value?

2. Is the desired state represented in version control and attributable to an owner?

3. Can the tested artifact be identified and verified at deployment time?

4. Which controls are preventive, detective, and corrective?

5. What happens when the pipeline, cloud provider, registry, or reconciliation controller fails?

6. Can the change be rolled back, rolled forward, or recovered from backup?

7. Are secrets, identities, state, and logs protected appropriately?

8. Does the platform improve developer experience without concealing operational consequences?

9. Which evidence demonstrates that reliability, security, compliance, and cost objectives are being met?

10. Are exceptions visible, justified, and eventually removed or institutionalised?

Chapter Summary

DevOps is a socio-technical approach that integrates development, operations, security, and learning through shared responsibility and automation. CI provides frequent integration and feedback; continuous delivery maintains deployable software; continuous deployment releases validated changes automatically when risk controls permit.

Infrastructure as Code represents infrastructure in version-controlled, reviewable definitions. Declarative IaC, controlled state, idempotent operations, drift detection, modularity, and secure defaults improve repeatability but do not remove the need for review and recovery planning. Configuration management establishes consistent runtime settings, while immutable approaches can reduce environmental variation.

GitOps extends declarative operations through repository-based desired state and continuous reconciliation. Testing must cover code, infrastructure, policies, deployment behaviour, resilience, and operational compatibility. Policy as code makes governance testable, while artifact security requires provenance, SBOMs, signing, protected registries, and risk-based vulnerability management.

Platform engineering provides internal developer platforms with golden paths, operational capabilities, interfaces, and guardrails. Effective platforms balance standardisation with autonomy and are managed as products. Across all these practices, success depends on traceability, least privilege, observability, recovery, appropriate metrics, and continuous organisational learning.

Key Terms

DevOps: An operating model integrating development, operations, security, automation, and feedback.

Continuous Integration: Frequent integration of code with automated build and validation.

Continuous Delivery: Maintaining software in a deployable state through an automated controlled process.

Continuous Deployment: Automatically releasing every change that passes required controls.

Infrastructure as Code: Managing infrastructure through machine-readable, version-controlled definitions.

Declarative Configuration: Describing the desired state while an engine determines implementation actions.

Imperative Automation: Specifying the procedural steps required to perform an operation.

Drift: Difference between declared or recorded infrastructure state and actual state.

Idempotence: Property whereby repeated application converges on the same intended result.

GitOps: Repository-centred, reconciliatory management of operational desired state.

Configuration Management: Automated establishment and maintenance of system settings.

Policy as Code: Machine-evaluable representation of security, compliance, cost, or operational rules.

Artifact: A versioned software output such as an image, package, or binary.

Software Bill of Materials: An inventory of components and dependencies in an artifact.

Provenance: Evidence describing an artifact’s source, build process, and origin.

Platform Engineering: Product-oriented development of internal platforms for engineering teams.

Golden Path: A well-supported, recommended route for delivering a common workload.

Progressive Delivery: Gradual release using techniques such as canary or blue-green deployment.

Change Failure Rate: Proportion of deployments requiring remediation, rollback, or urgent intervention.

Reconciliation: Repeated comparison and correction of actual state toward desired state.

Review Questions

Short Answer Questions

1. Distinguish continuous delivery from continuous deployment.

2. What is infrastructure drift, and how can it be detected?

3. Why must IaC state be protected?

4. What is the purpose of a software bill of materials?

5. Define a golden path in an internal developer platform.

Long Answer Questions

1. Explain how CI/CD, IaC, GitOps, and observability form an integrated delivery system.

2. Compare declarative IaC and imperative automation, including their advantages and limitations.

3. Discuss how policy as code can support security and regulatory governance without creating unsafe rigidity.

4. Explain the major controls required to secure a software artifact supply chain.

5. Evaluate the organisational and technical responsibilities of an internal platform team.

Analytical / Application Questions

1. A production team reports frequent deployments but also frequent rollbacks. Design a measurement and improvement plan using delivery, stability, and recovery metrics.

2. An organisation permits engineers to modify cloud resources through the console during emergencies. Design a governance process that preserves emergency response while controlling drift and audit risk.

3. Design a platform architecture for a financial-services application that requires strong identity, auditability, progressive delivery, policy enforcement, and data protection. Justify the major trade-offs.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes continuous delivery from continuous deployment?

A. Continuous delivery requires that every change be released automatically to production.

B. Continuous delivery keeps software deployable, while production release may still require approval.

C. Continuous delivery applies only to infrastructure and not application software.

D. Continuous delivery eliminates the need for automated testing.

Correct Answer: B. Continuous delivery keeps software deployable, while production release may still require approval.

Question 2

What is the primary purpose of declarative infrastructure as code?

A. To describe desired state so an engine can determine required actions

B. To require operators to execute every infrastructure step manually

C. To store production passwords in source repositories

D. To prevent infrastructure from being version controlled

Correct Answer: A. To describe desired state so an engine can determine required actions

Question 3

Which situation is an example of infrastructure drift?

A. A reviewed code change updates a version-controlled network definition

B. A deployment artifact is signed before entering a registry

C. An engineer changes a production firewall rule manually and the change is absent from IaC

D. A test environment is destroyed according to its approved configuration

Correct Answer: C. An engineer changes a production firewall rule manually and the change is absent from IaC

Question 4

In a GitOps model, what normally performs reconciliation?

A. A controller compares desired repository state with actual environment state

B. A developer manually edits every running container

C. A vulnerability scanner replaces the source repository

D. A billing system creates application deployment manifests

Correct Answer: A. A controller compares desired repository state with actual environment state

Question 5

Which control most directly helps establish an artifact’s build origin and contents?

A. Increasing the number of production servers

B. Using mutable image tags without version history

C. Disabling dependency scanning

D. Recording provenance and maintaining an SBOM

Correct Answer: D. Recording provenance and maintaining an SBOM

Question 6

What is the main purpose of policy as code?

A. To make organisational or regulatory rules machine-evaluable

B. To replace all human governance decisions permanently

C. To increase the number of undocumented exceptions

D. To prevent monitoring of deployed resources

Correct Answer: A. To make organisational or regulatory rules machine-evaluable

Question 7

Which practice best supports safe progressive delivery?

A. Releasing to all users before observing any health signal

B. Sending a small traffic percentage to the new version and evaluating telemetry

C. Deleting the previous version immediately after deployment

D. Rebuilding the artifact independently during production release

Correct Answer: B. Sending a small traffic percentage to the new version and evaluating telemetry

Question 8

If 5 of 50 deployments require rollback or urgent remediation, what is the change failure rate under that definition?

A. 5 percent

B. 10 percent

C. 45 percent

D. 55 percent

Correct Answer: B. 10 percent

Question 9

What is a principal responsibility of an internal developer platform?

A. Provide reusable delivery capabilities and guardrails through usable interfaces

B. Make every application use exactly the same business logic

C. Remove all application-team operational responsibility

D. Replace source control with manual ticket approvals

Correct Answer: A. Provide reusable delivery capabilities and guardrails through usable interfaces

Question 10

Why is expand-and-contract a useful database migration pattern?

A. It ensures that incompatible schema changes happen simultaneously with every deployment

B. It supports compatibility during rolling deployment before old structures are removed

C. It eliminates the need for backups and recovery testing

D. It requires all services to stop for the entire migration

Correct Answer: B. It supports compatibility during rolling deployment before old structures are removed