Unit 7: Implementation & DevOps
Learning Objectives
- Compare branching strategies and justify a choice for a given team and delivery context
- Describe the stages of a CI/CD pipeline and explain what each stage verifies
- Distinguish continuous integration, continuous delivery, and continuous deployment
- Evaluate the professional responsibilities that arise when using AI-assisted coding tools
Core Input
Read through each tab before working through the key concepts.
Version control is the practice of tracking every change to a codebase, together with who made it, when, and why. It is non-negotiable in any professional software development context. Version control enables: parallel development by multiple engineers, safe experimentation (changes can be reverted), audit trails for compliance, and the ability to understand how and why the system reached its current state.
Branching strategies define how teams structure their version control workflow to manage parallel development and integration risk.
-
Git Flow — uses long-lived branches:
main(production),develop(integration), feature branches, release branches, and hotfix branches. Provides clear separation between environments but requires significant merge overhead and can create long-lived divergence. - Trunk-based development — all developers integrate frequently (at least daily) to a single trunk branch. Feature flags hide incomplete features in production. Reduces merge conflicts and integration risk; requires high test automation to be safe at pace.
- Feature branch workflow — each feature is developed on a short-lived branch, reviewed, and merged. A practical middle ground: isolation during development, integration on merge. Merge frequency determines integration risk.
A CI/CD pipeline is an automated sequence of steps that transforms a code commit into a deployed system, with verification at each stage. The goal is to make deployment a routine, low-risk activity rather than a high-stakes manual event.
Typical pipeline stages:
- Source — a commit triggers the pipeline. The code is checked out.
- Build — the code is compiled or bundled. A build failure means the code cannot be assembled into a runnable artefact.
- Unit tests — fast automated tests verify individual functions and components. Failures indicate regressions at the code level.
- Static analysis / linting — code quality, security vulnerability scanning, and style enforcement are automated.
- Integration tests — tests verify that components work together correctly with real dependencies (databases, APIs).
- Staging deployment — the build is deployed to a production-like environment for end-to-end and performance testing.
- Acceptance tests — automated or manual verification that the system meets its acceptance criteria.
- Production deployment — the verified build is deployed to production. In continuous deployment, this is automatic; in continuous delivery, a human approves it.
The critical discipline: a failed pipeline stage stops all subsequent stages. A build that fails its unit tests does not proceed to staging. A pipeline that allows failing stages to proceed is not a pipeline — it is documentation that the system may or may not work.
DevOps is both a set of practices and a cultural shift. The practices — CI/CD, infrastructure as code, automated testing, monitoring — are well-defined. The culture is harder: shared ownership of the full software lifecycle, across what were traditionally separate "development" and "operations" organisations.
Core cultural principles:
- You build it, you run it — development teams are responsible for the systems they deploy in production. This accountability drives quality: the engineer who is paged at 3am for an incident they caused has a strong incentive to prevent the next one.
- Fast feedback loops — every stage of the pipeline is a feedback loop. The shorter the loop, the cheaper the fix.
- Blameless post-mortems — when incidents occur, the goal is to understand systemic causes, not assign individual blame. Blame cultures suppress incident reporting and prevent learning.
- Continuous improvement — teams regularly review their own processes (retrospectives) and make small, measurable improvements.
The DORA (DevOps Research and Assessment) research programme has identified four metrics that distinguish high-performing from low-performing software delivery organisations: deployment frequency, lead time for changes, change failure rate, and time to restore service. These metrics are measurable, actionable, and correlated with organisational performance outcomes beyond software delivery.
Key Concepts: Version Control & Branching
Branching strategy is a consequential engineering choice. Work through these items to understand what drives the decision.
Long-lived branches — branches that exist for days or weeks — accumulate divergence from the main trunk. When they are eventually merged, the result is a merge conflict: the two versions have changed independently in ways that cannot be automatically reconciled.
More subtly, long-lived branches create integration risk: the assumption that two independently developed features will combine correctly is never tested until the merge. A feature that works on its own branch may break something on main.
Trunk-based development eliminates long-lived branches entirely. Feature flags allow incomplete features to be merged without being visible to users — code is integrated but not activated. This reduces integration risk at the cost of requiring discipline to manage feature flag lifecycle.
A code review is the process of having one or more engineers read and evaluate a proposed change before it is merged. Done well, it serves multiple functions: catching defects the author missed, sharing knowledge across the team, maintaining consistency with the codebase's style and patterns, and providing a second opinion on design decisions.
A code review should assess:
- Correctness — does the code do what it is supposed to do?
- Test coverage — are there sufficient tests to verify the change?
- Design quality — does the change maintain or improve the codebase's cohesion and coupling?
- Security — does the change introduce any input validation, authentication, or authorisation concerns?
- Readability — can a future maintainer understand what this code does and why?
A code review that only checks "does this work?" is not using the full value of the practice. Reviewing for design quality and security requires the reviewer to read the change with these dimensions explicitly in mind.
Refactoring is the process of improving the internal structure of code without changing its external behaviour. It addresses technical debt at the code level: extracting duplicated code into shared functions, renaming for clarity, splitting large methods into smaller focused ones, and removing dead code.
Refactoring is safe when there is sufficient test coverage — tests verify that behaviour has not changed. Without tests, refactoring is risky: there is no way to confirm that the change did not introduce a regression.
Refactoring should happen continuously — as part of implementing every feature and fixing every bug — not as a deferred "cleanup sprint" that never arrives. The principle (from Extreme Programming) is leave the campsite cleaner than you found it: every code change should leave the immediate area of the codebase slightly better than before.
Key Concepts: CI/CD and DevOps
The pipeline is the mechanism; the culture is what makes it work.
These three terms are often confused:
- Continuous Integration (CI) — developers integrate code into the shared repository frequently (at least daily). Every integration triggers an automated build and test run. The goal: detect integration problems early, while they are cheap to fix. CI is about integration frequency and automated verification.
- Continuous Delivery (CD) — every build that passes all automated tests is deployable to production. The deployment itself requires a human decision. The goal: always have a production-ready build available; make deployment a business decision, not an engineering event.
- Continuous Deployment — every build that passes all automated tests is automatically deployed to production, without human approval. Requires very high confidence in the test suite. Used by organisations deploying hundreds of times per day.
These are a progression: CI is the prerequisite for CD, which is the prerequisite for continuous deployment. A team that cannot integrate without manual effort cannot deliver continuously.
A pipeline gate is a stage in a CI/CD pipeline that the build must pass before proceeding. If the gate fails, the pipeline stops. Gates operationalise quality standards: the organisation's stated requirements for test coverage, security scanning, or performance are not optional — they are enforced automatically on every change.
Gates matter because software quality without enforcement is an aspiration. A standard that says "all code must have 80% test coverage" means nothing if a developer can merge code with 20% coverage and deploy it. A gate that fails builds with below-threshold coverage makes the standard real.
The danger: gates set too strictly slow delivery; gates set too loosely provide false assurance. Calibrating gates requires understanding both what the quality standards are and what the cost of enforcing them is at the current stage of the pipeline.
A post-mortem (or incident review) is a structured analysis conducted after a production incident — a deployment failure, a system outage, or a data loss event. Its goal is to understand what happened and prevent recurrence.
A blameless post-mortem operates on the principle that complex system failures are rarely caused by a single individual's error — they are caused by systemic conditions (inadequate monitoring, insufficient testing, unclear procedures, time pressure) that made the failure possible. Assigning blame to an individual resolves nothing; it suppresses reporting and prevents the systemic conditions from being addressed.
The output of a blameless post-mortem is not a list of guilty parties but a list of systemic improvements: monitoring thresholds to add, pipeline gates to tighten, runbooks to create, deployment procedures to improve.
Watch
Video coming soon
Check Your Understanding
Select the best answer for each question.
In a CI/CD pipeline, the unit test stage fails. What should happen next?
Trunk-based development reduces integration risk by:
AI coding assistants are now widely used during implementation — suggesting completions, explaining unfamiliar code, drafting boilerplate, and generating initial test stubs. This unit is where the AI Dimension is most directly felt by working engineers.
- Assist: AI coding assistants reduce the time cost of writing repetitive code, navigating unfamiliar APIs, and generating test scaffolding. For experienced engineers, they amplify productivity on well-understood tasks.
- Risk: AI-generated code reflects patterns in training data — which includes a great deal of insecure, outdated, and poorly designed code. An AI assistant is, in effect, a very fast junior developer: confident, fluent, and sometimes wrong. AI-generated code may introduce subtle vulnerabilities (SQL injection, missing input validation, hardcoded credentials) that pass a superficial review. Without adequate test coverage, these defects reach production.
- Principle: Every line of AI-generated code that ships is the engineer's code. It must be read, understood, and reviewed with the same scrutiny applied to code written by a human colleague — including security review, design quality, and test coverage. "The AI generated it" is not a defence when a vulnerability is found in production. Reviewing AI-generated code for security concerns must be an explicit step in the code review process, not an assumption that the AI has handled it.
Activities
Individual task
Design a CI/CD pipeline for the hospital appointment booking system. Map out the stages of the pipeline in sequence, and for each stage specify:
- What triggers the stage
- What the stage verifies or produces
- What happens if the stage fails
- Whether this stage requires human approval to proceed
Your pipeline must include at least: source trigger, build, unit tests, security scan, integration tests, staging deployment, and production deployment. Justify why any stage that requires human approval does so — not all stages should.
Pair task
Review your partner's pipeline design:
- Are there any gaps — scenarios the pipeline would not catch before they reach production?
- Is there a rollback mechanism? What happens when a production deployment fails?
- Which stages could introduce bottlenecks that slow delivery? How would you address them?
- Does the pipeline address the security NFRs from the Unit 3 requirements baseline?
Identify one specific improvement to the pipeline's security coverage and one improvement to its speed.
Group task — DevOps workflow design
As a group, design a complete DevOps workflow for the case study system, combining your branching strategy (from the Unit 2 methodology decision) with the CI/CD pipeline. Document:
- The chosen branching strategy and why it suits the team size and delivery pace you assumed in Unit 2
- The full pipeline stages with gates, approval gates, and rollback triggers
- How you would handle a critical security patch that needs to be deployed outside the normal sprint cycle — what process does the team follow?
- Three DORA metrics the team should track, and what thresholds you would set for the first six months of operation
Review
- CI — frequent integration; automated build and test on every commit; detects problems early
- Continuous delivery — every passing build is deployable; deployment requires human approval
- Continuous deployment — every passing build is automatically deployed; no human approval gate
These are a progression: each requires the previous. High-performing teams use all three where appropriate — and understand that continuous deployment requires correspondingly high confidence in automated testing.
AI coding assistants accelerate writing code — they do not transfer the engineer's responsibility for the code. Every line of AI-generated code that is merged and deployed is the engineer's code: it must be reviewed for correctness, security, design quality, and test coverage. The code review process must include AI-generated code as a first-class concern, with explicit attention to security vulnerabilities that AI is known to introduce. "The AI wrote it" is not a justification for skipping review.
Proceed to Unit 8: Testing & Quality when ready.