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 Deployment"]
  N2["27.2 Validation"]
  N3["27.3 Rollback"]
  N4["27.4 Result"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX079"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["27.1 Deployment"]
  N2["27.2 Validation"]
  N3["27.3 Rollback"]
  N4["27.4 Result"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX079"]

[Learning outcomes]
    |
    v
[27.1 Deployment]
    |
    v
[27.2 Validation]
    |
    v
[27.3 Rollback]
    |
    v
[27.4 Result]
    |
    v
[Worked example] --> [Exercise EX079]

Learning outcomes

You will (1) deploy privacy changes; (2) validate them; (3) roll back safely.

27.1 Deployment

The new settings page and SDK removal deploy in stages. The new settings page and the app release without the ad SDK go first to five percent of members, then half, then everyone over two weeks. Staged deployment limits the impact of mistakes. The app team monitors crash reports and support contacts at each stage, and Aisha monitors network traffic from test devices for unexpected data flows. At the five percent stage she sees no ad network traffic from any test device.

27.2 Validation

Aisha validates with synthetic accounts and network inspection. Validation repeats the earlier flow tests on the new release using the same synthetic accounts and steps, so results can be compared with the earlier findings. She checks every domain contacted by the app and the fields sent. She also checks that the new default for heart-rate sharing is off for newly created accounts. A new test account created on release day confirms that the heart-rate sharing switch starts in the off position. All results match the plan.

27.3 Rollback

A rollback plan is ready if errors occur. The rollback plan describes how to return to the previous version if serious problems appear. Aisha points out a privacy issue with rollback: the previous version contained the ad SDK, so rolling back would restart the harmful flow. The team prepares a patched previous version without the SDK to use for any rollback instead. The patched version is tested in advance so that a rollback does not reintroduce the ad network flow under pressure.

27.4 Result

Validation confirms no heart-rate data to advertisers. Mr. Reilly notes that validation proves change, not intent. The release reaches all members without serious errors. Network tests show no traffic to the ad network and no heart-rate fields leaving to third parties other than the contracted strap provider. Aisha records the validation results with dates and versions, so the data protection officer can show evidence if a member or regulator asks. The record lists app version, date and test devices. Nothing is left undocumented.

Worked example

Aisha deploys in stages, validates with synthetic accounts and confirms no advertiser flows.

Synthetic case. The deployment is synthetic.

Errors and limits

Staged rollouts can mix versions.

Exercises

• EX079 — Validation. How is validation done? Rubric: 3 = synthetic accounts and network inspection;; 2 = one;; 1 = vague;; 0 = none.
• EX080 — Rollback. Why a rollback plan? Rubric: 3 = to recover from errors;; 2 = partly correct;; 1 = vague;; 0 = none.
• EX081 — Result. What did validation confirm? Rubric: 3 = no heart-rate data to advertisers;; 2 = partly correct;; 1 = vague;; 0 = none.

Continue studying — lesson 27 (chapter 27 of 30)

← Chapter 26 · Course chapter index · Chapter 28 →

Continue to the next authored lesson.