Deploying Into the Customer's Environment
Kavitha Rao's rule is short: carrier invoices never leave Harbourline's cloud account. So Loomwork's invoice checker has to run inside that account, on infrastructure Harbourline owns and will keep running long after you leave. A deployment done by hand one afternoon will not survive that.
The rule
If it can't be rebuilt from code, watched and rolled back, it isn't deployed.
A real deployment has four properties:
- Rebuilt from code. The application is a versioned container image, and the servers, network rules and storage are described in infrastructure-as-code files. A fresh environment takes one command, not a week of clicking through a web console.
- Configured, not hard-coded. Settings that differ between environments, such as the database host or mailbox name, live in config files. Secrets such as passwords live in Harbourline's secret manager, never in the code, the repository or a chat message.
- Watched. Logs, a health check, and a few measures that matter to the business, such as invoices processed per hour and failures. Alerts go to someone at Harbourline who will act on them.
- Rolled back. Every release has a version number, so returning to the last good one is a small change. Database changes only add things, so the previous version still works against the new database.
# deploy/harbourline.yaml: environment settings, no secrets
image: loomwork/invoice-checker:1.4.2
tms_host: tms-replica.harbourline.internal
mailbox: ap-invoices
secrets: harbourline-vault/loomwork # read at start-up
alerts_to: it-oncall@harbourline.exampleDeployments also follow the customer's rules: their approval process, their change windows, their naming conventions. You are working in their house.
The shortcut
Run the stranger test: could a Harbourline engineer who has never met you redeploy the system, tell whether it is healthy and roll it back, using only the repository and the runbook?
Redeploy
One documented command deploys version 1.4.2 from the repository. Pass.
The trap is the quiet hand edit: fixing a setting over SSH on the live server. The next deploy wipes it out, and nobody knew it existed.
Drills
Answer fast — trust the rule.
Where should the TMS database password live?
Why deploy invoice-checker:1.4.2 rather than invoice-checker:latest?
Which alert is most useful for the pilot?
You fix a setting by editing a file on the live server over SSH. What is the main problem?
What does the stranger test check?
Remember
- If it can't be rebuilt from code, watched and rolled back, it isn't deployed.
- Shortcut: the stranger test. Redeploy, check health, roll back, all without you.
- Trap: hand edits on the live server, and secrets in files or chat.