The Report Development Lifecycle
Ship reports like software, not favors
Reports are software now: requirements, development, testing, review, release, and maintenance in an environment ladder — source-controlled, reviewed, and deployed with the model.
What you will learn
- Run a report through dev → test → prod
- Gate releases with review and QA
- Manage report versions and environments
What is this?
The report development lifecycle runs reports through the same discipline as models: gather the requirement, develop against a test environment, review data and layout, approve, release via a pipeline, then maintain (refreshes, adoption, retirement). Environment ladders (dev/test/prod) and source control catch breakage before stakeholders do.
Why do you need it?
- Unreviewed report changes burn trust that took months to build.
- Env parity prevents 'works in my Desktop' failures.
- Lifecycle discipline makes late changes cheap and disasters small.
- Maintenance is routine retirement that keeps the catalog honest.
Mental model
Restaurant kitchen tasting before service
Report lifecycle
The head chef (reviewer) tastes every plate before it leaves the pass (release). A dish isn't 'done' because it's plated — it must be tasted, matched to the menu, and any bad plate recalled before it hits tables. Reports get the same taste gate.
How it works
- Requirements: the decision, audience, cadence — scoped, one page.
- Development in a dev workspace against the test environment.
- Data + layout review (taste passes): correct numbers, readable, tested filters.
- Release pipeline moves the report through environments with a review gate.
- Maintenance: refresh/error monitoring, adoption review, retirement cadence.
The report lifecycle ladder.
Examples
A release gate checklist
RELEASE GATE (block if any): [ ] Numbers reconcile vs control total [ ] Filters tested as a consumer, not just author [ ] Performance within SLA on the target audience set [ ] Owner + decision + cadence documented [ ] Approved in review (data + design) [ ] Deploy pipeline green; dev/test parity checked [ ] Rollback path pinned (previous version still servable)A concrete gate turns 'looks fine' into a checklist that any reviewer can enforce.
In production
- A weekly board report flows dev→test→prod with a Tuesday review gate.
- A consumer role user runs the report pre-release to catch filter drift.
- Quarterly catalog sweep retires three unadopted reports, documented and archived.
Best practices
- Test as the least-privileged consumer, not the author.
- Release via pipeline (workspaces → app), not copy-paste.
- Put every release through a data + design review.
- Schedule retirement: adoption, freshness and accuracy on a quarterly sweep.
Common mistakes
- Building straight into prod (no parity, no gate).
- Review collapses to a glance — no checklist, no consumer test.
- Perfect-in-dev, broken-in-prod because environments diverged.
- Retiring nothing: the catalog rots with 200 dashboards nobody opens.
Debugging tips
- “Works then breaks at release” → environment parity; check data source and refresh config.
- Review bits late → get a written decision + owner before work begins.
- Nobody reads a new report → the cadence/audience was guessed; re-run discovery.
Interview checkpoint
Hands-on lab
- Stand up dev vs prod environments with a parity check
- Automate a reconciliation gate in SQL
- Simulate a blocked release and roll back
Run a Report Through a Review Gate
45 min · intermediate
Quick quiz
The release gate is best described as:
Retiring unused reports is part of the lifecycle.