Chapter 27 — Deployment and validation | Technologist Security architecture and engineering

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 27 — Deployment and validation

Lesson map

Lesson 27 published. Map, example, EX079.

flowchart TD
  N0["Learning outcomes"]
  N1["27.1 Planning the deployment"]
  N2["27.2 Validating"]
  N3["27.3 Rollback"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX079"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["27.1 Planning the deployment"]
  N2["27.2 Validating"]
  N3["27.3 Rollback"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX079"]

[Learning outcomes]
    |
    v
[27.1 Planning the deployment]
    |
    v
[27.2 Validating]
    |
    v
[27.3 Rollback]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX079]

Learning outcomes

You will (1) deploy a configuration change across depots safely; (2) validate it against requirements; (3) roll back if needed.

27.1 Planning the deployment

Brightwater decides to enforce individual badge sign-in on all handhelds across four depots, replacing shared crew PINs as designed in chapter 7. Tomás plans a staged deployment: one depot first, then two, then the last. Each stage has entry criteria, such as badges issued to all staff, and exit criteria, such as fewer than five sign-in help calls per shift. He schedules changes at the start of the quietest shift. Staged deployment limits the impact of mistakes to one site at a time.

27.2 Validating

For each depot, Tomás checks requirements: every handheld requires a badge and PIN, scans record the individual driver, shared PINs no longer work and locked accounts can be reset by supervisors. He tests each requirement with a test badge and records results. At the second depot, one model of handheld still accepts the old shared PIN because of an older firmware version. The firmware is updated and the test repeated. Validation catches gaps that the configuration screen alone would never show.

27.3 Rollback

Tomás prepares a rollback plan: if more than ten percent of drivers cannot sign in at shift start, the depot reverts to shared PINs for that day while badges are fixed. The plan is never used, but having it lets supervisors agree to the change with confidence. After all four depots, sign-in help calls settle to two per shift. He records deployment results, the firmware issue and lessons learned. A clear rollback plan is a sign of a professional deployment, not of doubt about the change.

Worked example

Tomás deploys badge sign-in in three stages, validates four requirements per depot, catches a firmware gap and prepares an unused rollback plan.

Synthetic case. Depots and figures are synthetic.

Errors and limits

Staged rollouts extend mixed states. Rollback can reintroduce weak controls temporarily.

Exercises

EX079 — Exit criterion. What was the exit criterion for each stage? Rubric: 3 = fewer than five sign-in help calls per shift;; 2 = help calls;; 1 = vague;; 0 = none.
EX080 — Firmware gap. What did validation catch at the second depot? Rubric: 3 = an older firmware model still accepted the shared PIN;; 2 = firmware;; 1 = vague;; 0 = none.
EX081 — Rollback trigger. What would trigger rollback? Rubric: 3 = more than ten percent of drivers unable to sign in at shift start;; 2 = ten percent;; 1 = vague;; 0 = none.

Synthesis

Staged deployment, requirement validation and a ready rollback plan make changes safe.

Continue studying — chapter 27 of 30

← Chapter 26 (draft) · Course chapter index · Chapter 28 (draft) →