This is a ready-to-use release record for promoting an increment into a validated GxP production environment. Under a standing Agile change framework, the release record is the change record, so this form is what authorizes and evidences the validated-state change for each increment. Replace every <<FILL: ...>> placeholder, complete one per production release, and retain it as a controlled record. A filled specimen follows. This is general educational content to adapt, not regulatory advice.
Purpose
To record, for each increment promoted to the validated production environment: what changed, which stories and versions, that the pipeline gates passed, that the definition of done was met for each GxP story, and that QA authorized the release. Completed and approved before promotion, it is the release evidence and the change record in one artifact.
Header
| Field | Entry |
|---|---|
| System / product | <<FILL: system name, GxP use>> |
| Release / version | <<FILL: version, e.g. v2.7.0>> |
| Environment promoted to | <<FILL: validated production env ID>> |
| Change framework reference | <<FILL: standing change/validation framework ID>> |
| Release date/time | <<FILL: timestamp>> |
| Release manager | <<FILL: name>> |
Field definitions
| Field | Format | Required | Who | When |
|---|---|---|---|---|
| Stories in this release | List of story IDs + GxP tier | Yes | Release manager | Before release |
| Version / commit deployed | Version and commit hash | Yes | Release manager | Before release |
| Prior version (for rollback) | Version | Yes | Release manager | Before release |
| Pipeline run reference | CI run ID | Yes | Automation | At build |
| Regression result | Pass / Fail + run ref | Yes | Automation | At build |
| DoD met for each GxP story | Yes + reference | Yes | Validation lead | Before release |
| Traceability complete | Yes + reference | Yes | Validation lead | Before release |
| Test evidence retained | Yes + location | Yes | Validation lead | Before release |
| Quality events linked (deviation/CAPA) | IDs or None | Yes | QA | Before release |
| Emergency change? | Yes / No + procedure ref | Yes | Release manager | Before release |
| QA release approval | Signature + date | Yes | QA | At release |
Release content
| Story ID | GxP tier | Summary | DoD met (ref) |
|---|---|---|---|
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
Gate evidence
| Gate | Result | Evidence reference |
|---|---|---|
| Unit + integration tests | <<FILL: Pass>> | <<FILL: CI run>> |
| Regression suite | <<FILL: Pass>> | <<FILL: CI run>> |
| Code review / peer approval | <<FILL: recorded>> | <<FILL>> |
| Acceptance tests (high-risk stories) | <<FILL: Pass>> | <<FILL>> |
| Deployment to production | <<FILL: success>> | <<FILL: deploy log>> |
Rollback plan
| Field | Entry |
|---|---|
| Rollback target version | <<FILL: prior known-good version>> |
| Rollback tested/available | <<FILL: Yes/No>> |
| Who authorizes rollback | <<FILL: role>> |
Approvals
| Role | Name | Signature | Date |
|---|---|---|---|
| Release manager | <<FILL>> | ||
| Validation lead | <<FILL>> | ||
| QA (release authorization) | <<FILL>> |
Retention
Retain the release record with the CI evidence, DoD records, and test results under the records retention schedule, for not less than <<FILL: retention period>>. As the change record for the increment, it is subject to the same integrity expectations as any GxP record and must be retrievable for inspection.
Filled specimen
The following shows a completed release record for one increment, so you can see the level of detail expected. Illustrative.
Header: LIMS (GxP: QC result management and release); v2.7.0; env PROD-1; framework CHG-FRW-004; released 2026-03-07 14:20; release manager D. Fowler.
| Story ID | Tier | Summary | DoD met |
|---|---|---|---|
| US-1042 | High GxP | OOS result flag blocks silent release | Yes, DoD-1042 |
| US-1051 | Low | Dashboard tile color | Yes, DoD-1051 |
Gate evidence: unit/integration Pass (CI 8842); regression Pass (CI 8842, all green); code review recorded (PR 611); acceptance AT-1042-01 Pass; deploy success (deploy log 2026-03-07). Traceability: URS-07 to AT-1042-01 to OOS-flag-001. Quality events: None. Emergency change: No. Rollback target: v2.6.3, available. QA approval: R. Nayar, signed 2026-03-07.
This single record ties the increment to its stories, the passing gates, the retained test evidence, the traceability thread, and a recorded QA authorization, and it names the version to roll back to. When an inspector asks how this production change was controlled and validated, this record is the answer, and it doubles as the change record so there is no separate multi-week change form to reconcile.
Common inspection findings this form prevents
- No record of what was deployed, so nobody can say which version is running in the validated environment.
- A production release with no recorded QA authorization.
- Test evidence not retained for the released version.
- An emergency change slipped in with no procedure reference and no linked quality event.
- No named rollback target, so recovery from a bad release is improvised.
How to adapt this form
- Reference your standing change/validation framework in the header, so this record is explicitly the change record under it.
- Keep the version and commit fields mandatory; “latest” is not a version.
- Require the DoD reference for every GxP story before the QA approval line can be signed.
- Record the rollback target on every release, and confirm the retention period against your records schedule.