Chapter 27 — Deployment and validation

Chapter 27 — Deployment and validation

Lesson map

Lesson 27 published. Map, example, EX079.

flowchart TD
  N0["Learning outcomes"]
  N1["27.1 Planning a deployment"]
  N2["27.2 Validating before and after"]
  N3["27.3 Rolling back if needed"]
  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 a deployment"]
  N2["27.2 Validating before and after"]
  N3["27.3 Rolling back if needed"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX079"]

[Learning outcomes]
    |
    v
[27.1 Planning a deployment]
    |
    v
[27.2 Validating before and after]
    |
    v
[27.3 Rolling back if needed]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX079]

Learning outcomes

You will (1) plan a safe deployment; (2) validate before and after release; (3) roll back if needed.

27.1 Planning a deployment

The developer prepares version 1.4 of the credit contract, adding a per-member identity check suggested by Lucas's evaluation. Lucas helps plan the deployment: test on the test ledger, external review of the change, approval through the change process, a timelocked upgrade on the live ledger and post-deployment checks. The plan names who does each step and when. The timelock gives members and staff 48 hours of notice. Planning deployments carefully matters because contract changes affect every member at once and can be hard to reverse once complete.

27.2 Validating before and after

Before release, Lucas runs the configuration check and confirms all tests pass, the compiler version is pinned and the code hash of the reviewed build matches the one proposed for upgrade. After release, he confirms the new code hash on the ledger, that roles and the cap are unchanged, that a small test grant works and that monitoring sees the expected events. He records each check. Validation before and after confirms both that the right thing was deployed and that it behaves as expected in the live environment, not just in testing.

27.3 Rolling back if needed

The plan includes a rollback: if post-deployment checks fail, signers pause grants and propose a timelocked return to version 1.3, with members informed. Lucas rehearses the rollback on the test ledger and measures the time needed. In the real deployment all checks pass and no rollback is needed. He records the deployment as complete. Ms Adebayo notes that a deployment plan without a rehearsed rollback assumes success, and that assumption is exactly what experienced technologists learn not to make when real members depend on the system.

Worked example

Version 1.4 deploys through a 48-hour timelock with code hash matching before and after, and a rehearsed rollback proves unnecessary.

Synthetic case. The deployment and versions are synthetic.

Errors and limits

Deploying without a rehearsed rollback assumes success that may not come.

Exercises

• EX079 — New contract feature. What does version 1.4 add? Rubric: 3 = a per-member identity check;; 2 = identity check;; 1 = higher cap;; 0 = none.
• EX080 — Hash check. What hash check is done before release? Rubric: 3 = reviewed build hash matches the proposed upgrade;; 2 = code hash;; 1 = vague;; 0 = none.
• EX081 — Rollback target. What would rollback return to? Rubric: 3 = version 1.3;; 2 = 1.3;; 1 = version 1.0;; 0 = none.

Synthesis

Planned, validated and reversible deployments protect members from change risk.

Continue studying — chapter 27 of 30

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