# Release card: plan and confirmed state

A release means deploying a specific version to a specific environment. Record the intent separately from what was actually verified after deployment.

## Planned release

- Application or service: **[known: … / to be determined]**
- Environment: **[known: … / to be determined]**
- Planned version: **[known: … / to be determined]**
- Umbrella release task and tasks in scope: **[links / to be determined]**
- Date and person accepting the entire release: **[to be determined]**
- Approval for release: **[known: … / absent / to be determined]**
- Checks before deployment: **[to be determined]**
- Rollback plan and authorized person: **[to be determined]**

## Moving through environments

Adapt the names to your own process. DEV below means the shared environment where you combine the team’s code. The author’s local preview is a separate workspace.

| Environment | Confirmed version | Automated tests | Acceptance / open issues |
| --- | --- | --- | --- |
| DEV — shared team version | [not confirmed] | [result and evidence] | [to be completed] |
| QA — quality assurance | [not confirmed] | [automated-test result and evidence] | [to be completed] |
| UAT — user acceptance testing | [not confirmed] | [full test suite: result and evidence] | [acceptance of the whole release by the PO] |
| PROD — production | [not confirmed] | [result of checks planned for production] | [confirmation that it works / issue] |

The release task gathers the scope. The portal shows deployment status. Complete results from sources; being listed in a planned release does not confirm presence in an environment.

## Actually deployed and verified

| Field | Confirmed state |
| --- | --- |
| Date and time | [not confirmed] |
| Environment | [not confirmed] |
| Version actually deployed | [not confirmed] |
| Deployment result | [not confirmed] |
| Post-deployment check and result | [not confirmed] |
| Monitoring / observation | [not confirmed] |
| Limitation or open issue | [not confirmed] |

## Complete the card from your release

Open the deployment portal, the tasks covered by the release, and the check results. The agent should collect data from those places without adding confirmations based on the plan alone.

| Field | Where to obtain confirmation |
| --- | --- |
| Version in the test environment | Read the running application’s version and the deployment record |
| Version used by users | Read it from the relevant environment; the release plan is not confirmation |
| What changed | Tasks and code changes belonging to this version |
| Post-deployment result | User action performed, result received, time, and the person who checked it |
| Limitations | Open issues and checks that were not performed |
| Response to a problem | Responding person, backup, and repair or rollback instructions |

If the portal does not show where confirmation comes from, record the gap and establish how to read it. Do not copy the planned version into the “working” field.

## Message draft — complete the facts, then approve sending it

```text
[Application] • [environment] • [confirmed version]
Change for the user: [what they can now do or what was fixed].
Tasks: [links]. Application address: [the correct address].
Post-deployment check: [action, result, time, and link to evidence].
Open issues or checks not performed: [specific scope].
Responds: [person or role]. Backup: [person or role].
Rollback instruction: [link; include the impact on data].
```

## When an alert arrives

1. The responding person checks the environment, version, and symptom. They determine whether the whole application or a particular action is failing.
2. They compare the symptom with the latest release and logs. In the agreed channel, they record what is known and what they are checking now. They do not guess the cause.
3. An authorized person decides on a repair or the prepared rollback. After the action, repeat the same scenario and record the result.

Do not put secrets or customer data in the message. Sending a message and changing an environment require the appropriate authorization.

## Prompt for completing the card

```text
Read the card and permitted sources: [links]. Separate the planned release
from facts confirmed after deployment. For every confirmed row, give the
source, version, and time; mark an absence as “not confirmed”.
Connect tasks with the release and successive environments. Do not confuse a local preview
with shared DEV. Give results of tests, full UAT tests, and acceptance of
the entire release; do not add PO approval without confirmation.
Give the post-release check, monitoring, and a safe next step for an alert.
Prepare the message only as a draft for approval. Do not deploy, roll back,
send messages, or change environments, accounts, or permissions.
```