In this chapter
At our company, a change passes through DEV → QA → UAT → PROD. Each of these environments has its role. Separately, we have a deployment portal, a tool for orienting ourselves in deployment status.
DEV is the team’s shared environment
We join code changes prepared by the team in DEV. It is the shared development environment where results of our work meet. An AI Engineer’s local preview is an earlier place for work and demonstration; I do not call it DEV here.
This distinction matters: a working slice on one person’s machine still needs checking together with the other changes.
QA checks a change; UAT checks the whole release
| Environment | How we use it in our process |
|---|---|
| DEV — shared development environment | We join team changes in a shared application version. |
| QA — quality-assurance environment | Changes pass through test automation; our testing robots run. |
| UAT — user-acceptance-testing environment | We run the full test suite and robots. The Product Owner accepts the whole release. |
| PROD — production | After passing earlier environments and acceptance, the release reaches users. |
We have automated tests in every environment. In UAT, we run the full set and accept the entire release. Business acceptance by the PO remains part of this passage.
We collect tasks into one release
At present we have one collective release task in Jira. We add to it the tasks we want to deliver in a given version. We release on Wednesdays or Thursdays. This is our current rhythm, which I show as an example.
In UAT, the PO sees the whole release. This is broader acceptance than the earlier demo of one feature: several changes together must create a version we will give users. Only then do we proceed to production.
The deployment portal shows environment status
The portal is a separate part of this process. I distinguish the release task, which gathers the release scope, from information about which version actually runs in an environment.
If you are organizing such a view, start with simple questions: what is on DEV, what passed QA, what are you accepting in UAT right now, and what runs in production? For every version, it should be possible to reach test results and acceptance agreements. A planned release must be distinguished from confirmed deployment.
We can discuss portal-building details and its integration through Let’s talk. Here I show its place in the team’s work.
Move this flow to your release
Download · Text fileRelease card and message to the teamteam-wydanie-en.mdDownloadOpen the existing release task, change list and test results. Use the card to record your environment sequence, versions, acceptance result and what is still pending. Adapt environment names and the release rhythm to your own process.
Review release task [link] and allowed sources [links]. Show which tasks this version includes and what has actually passed through successive environments. Distinguish a local preview from the team’s shared environment. For every environment give confirmed version, automated-test results, and open problems. Identify the result of full tests and acceptance of the whole release in the acceptance environment. Do not enter PO acceptance without its confirmation. Use the attached card. Record gaps, a response method for a problem, and a rollback plan appropriate to this change. Prepare the message as a draft. Show the result for agreement; do not save to services, deploy, or send it.
Before production, also agree who will respond to a problem and how to safely restore the previous behaviour. If data changes, rolling back code alone may not be enough. After deployment, check the right version and the main action at the production address. The card has fields for these arrangements and the team message.
At our company, UptimeRobot is one observation tool. Application availability and correct feature operation are two separate checks.