The Releases module of Portail ZAPP groups approved changes into a release, checks that it is ready to go out, then tracks its deployment instance by instance: each environment (production, staging, a customer's instance…) follows its own schedule. Release Managers and administrators drive it; Service Desk agents can view it.
Target instances
Releases → Target instances declares the environments you deploy to. Add an instance: Name (unique), Kind (for example Production, Staging), Description and Alerted team (the group notified at each deployment step). Move up and Move down set the display order. An instance is never deleted: when Inactive, it is no longer offered for a new release but stays in the history.
The exit checklist template
Releases → Exit checklist template holds the items copied into every new release. Four items are provided, one per Category (Tests, Communication, Documentation, Approvals), shown in each person's language. You can add, reorder or disable items; entering a Label replaces the translation (leave it empty to keep it). Existing releases keep their own copy.
Create a release
From Releases → Release list, click New release:
- Title and Type (Major, Minor, Emergency);
- Release manager (a member of that group, or — To be assigned —);
- Window start and Window end of the deployment;
- Release notes;
- Target instances: tick those where it will be deployed; deployment will be tracked for each one.
It receives a number such as REL-2026.01, whose sequence restarts every year.
The lifecycle
Planning → Build → Deployment → Early life support → Closed. You can go Back to planning from build, and Cancel the release as long as it is not closed (its changes are then released for another one).
Exit conditions:
- Move to build requires at least one grouped change (when the Changes module is installed);
- Start deployment and Close require a complete Exit checklist; an empty checklist never counts as complete;
- Close also requires every instance to be deployed, or postponed with a reason.
A banner on the record shows what is missing, with a link (Go to the checklist, Go to the changes).
Grouped changes
In the Grouped changes card, Add an approved change: search by number or title among approved or scheduled changes. A change belongs to only one release, and its record shows the release that contains it. The content is built during planning and build, then it is locked from deployment onwards. If the release window falls within a freeze window that concerns it, the record shows a warning.
The exit checklist
Each item can be checked or unchecked (Check, Uncheck), with the author and date. An Item to add for this release can complete the list. Adding or unchecking an item afterwards reopens the exit condition.
Deployment per instance
The Deployment per instance card tracks each instance: Pending → In progress → Deployed, or Failed, or Postponed. The actions are Start deployment, Mark as deployed, Report a failure, Postpone and Back to pending, with a Comment (optional).
- A failure or postponement on one instance blocks no other;
- Postpone requires a Postponement reason;
- before deployment (planning, build), only postponement is possible;
- each instance has its own Planned date and its Instance history; an instance whose planned date has passed without being deployed or postponed is flagged Late;
- an instance can be added (Add the instance) as long as the release is not closed, and removed (Remove the instance) during planning or build if it was never declared.
Each time an instance moves to in progress, deployed, failed or postponed, the Release Manager and the instance's alerted team are notified.
Escalate to a major incident: on a failed instance, when the Major incidents module is installed and you have the right, one click creates the incident and the major incident, pre-filled with the release, the instance and the cause entered. The same failure always leads to the same major incident; a new failure creates a new one.
Health check: during deployment and early life support, on an instance in progress, deployed or failed, you can run an approved Check script from the script execution module. The result (Passed or Failed) is kept on the row (Last health check). The button only appears if such scripts exist and you can run them.
The Release × instance matrix gives the overall view: a colored cell per release and per instance, delays and open major incidents.
Early life support (hypercare)
When an instance is Deployed, it enters hypercare for 14 days by default (the administrator sets this duration); Change the end of hypercare adjusts it instance by instance. The Early life support card tracks the tickets related to the release:
- Suggested tickets: tickets opened during hypercare on the CIs of the included changes, each with an Attach button;
- Other ticket: search for a ticket by number or text, describe the Finding, then Attach;
- follow each ticket (To analyze, Handled, Not related), or Detach.
The attachment also appears on the ticket. From a ticket's record, the Attach to the release action is offered to Release Managers during hypercare. Without the Service Desk, tickets already attached remain readable, but none can be added.
Release notes
In the Release notes card, Write opens the Markdown editor with a Preview. Headings, lists, bold, links and tables are rendered; raw HTML is not interpreted. Notes can be exported as Markdown or PDF.
When the AI assistant is configured, Draft from the changes proposes a text written from the included changes. It replaces the current text after confirmation and is only saved with Save. When AI is disabled, this button does not appear; manual writing remains possible.
Overviews
- Release calendar: deployment windows and freeze periods; Show changes adds planned changes for those who can read them.
- Release Kanban: one column per status; dragging a card applies the transition with the same conditions as the record. Closing and cancelling are done from the record; the Closed column shows the last 30 days.
- The dashboard's Release manager widget shows ongoing releases, late instances, and failure and rollback rates over 90 days.
If the calendar or the Kanban is not available on your instance, a message invites you to use the list.