66 lines
1.6 KiB
Markdown
66 lines
1.6 KiB
Markdown
# Haskell Writer for Audit Trails
|
|
|
|
This note covers `31-haskell-writer-audit/`, which simulates a rollout while accumulating ordered audit lines with `Writer`.
|
|
|
|
---
|
|
|
|
## 1. What `Writer` Adds Here
|
|
|
|
The example does two things at once:
|
|
|
|
- compute a final `RolloutReport`, and
|
|
- collect human-readable audit lines in execution order.
|
|
|
|
That is the shape `Writer` is good at:
|
|
|
|
```haskell
|
|
simulateRollout :: ReleaseJob -> Writer [String] RolloutReport
|
|
```
|
|
|
|
The result and the log are produced together, but the rollout code stays direct and readable.
|
|
|
|
---
|
|
|
|
## 2. Why the Log Is Worth Teaching
|
|
|
|
The audit trail is not decorative. It captures meaningful rollout steps:
|
|
|
|
- rollout start,
|
|
- target scaling,
|
|
- schema migration,
|
|
- traffic shifting, and
|
|
- rollout completion.
|
|
|
|
For canary rollouts, the example records extra milestones and observation points. That makes the logged structure richer than a toy "hello logger"
|
|
example.
|
|
|
|
---
|
|
|
|
## 3. Why This Stays Separate from Error Handling
|
|
|
|
`Writer` is used here only for logging.
|
|
|
|
The example does not mix in failure handling or configuration lookup, because that would blur the concept. Parsing still happens before the writer run,
|
|
and the rollout simulation itself is deterministic.
|
|
|
|
That keeps the example focused on one question: how do you accumulate ordered auxiliary output while computing a result?
|
|
|
|
---
|
|
|
|
## 4. Commands to Try
|
|
|
|
```bash
|
|
cd 31-haskell-writer-audit
|
|
|
|
nix develop
|
|
cabal run
|
|
cabal run -- api:production:canary:20:3 worker:staging:rolling:0:2
|
|
cabal test
|
|
|
|
nix build
|
|
./result/bin/mini-audit api:production:canary:20:3 worker:staging:rolling:0:2
|
|
|
|
nix run . -- api:production:canary:20:3 worker:staging:rolling:0:2
|
|
nix flake check
|
|
```
|