Deployment reporting is easy to automate badly.
A pipeline finishes and posts an event. A dashboard turns green. The central change system records another successful production deployment.
The package may still be waiting for approval.
The reporting system can no longer answer which change reached production.
A build is evidence of a build
A successful build proves that source produced an artifact. It does not prove that the artifact reached production.
A merge proves that a branch changed. Packaging proves that a PUB was generated. An approval proves that someone permitted a release. Each event matters, but none should impersonate the final deployment.
Register at the last system that knows the production operation succeeded.
For a platform deployment, that may be the orchestrator after rollout health checks. For an application copied to a managed server, it may be the server deployment service. For an Exstream PUB, it may be the workflow that packaged and installed the file in the production package location.
The deployment owner should report it
Upstream systems lack the final context.
They may know the repository and source SHA but not the selected target, the package digest, the operator confirmation, or the eventual outcome. If they register early, a later failure leaves a successful event attached to a deployment that never happened.
The deployment owner can report:
- the real target environment;
- the exact deployed artifact;
- the completion time;
- the initiating user;
- the successful result;
- the production deployment identifier.
That is enough to create an honest event. Source and package evidence can then enrich it.
Do not count the same deployment twice
Modern platform paths often register deployments already. Adding a second generic workflow across every repository creates duplicate events for the best-managed part of the estate while leaving legacy paths ambiguous.
Map the deployment paths first:
| Deployment path | Existing owner | New registration needed |
|---|---|---|
| Platform-managed application | Platform orchestrator | No, if already reported |
| Legacy server application | Server deployment service | Yes |
| Exstream resources | Resource deployment service | Yes |
| Exstream PUB package | Packaging and deployment workflow | Yes |
One reporting mechanism does not require one trigger location. It requires a consistent event contract at the point where each deployment becomes real.
Identity matters more than the event count
A report that names only CustomerLetters.pub is almost useless. The same filename may identify every release for ten years.
Tie the event to:
- the source repository and revision;
- the package SHA-256 digest and size;
- the deployment ID and time.
If a binary artifact cannot be resolved to a source revision, report the gap. Do not use the current branch head as a convenient replacement. That records a plausible source state, not the deployed one.
Mutable snapshot artifacts require particular care. Resolve metadata for the exact timestamped build that was selected, not only its shared version label.
Inspection makes the record useful to a reviewer
Identity tells an auditor which artifact moved. It does not tell a reviewer what changed inside it.
CCMForge Inspect can attach a package manifest and a comparison against the repository or previously deployed PUB. The reviewer can see object changes, formula edits, mappings, wording, and the fraction of the comparison that was possible.
This is evidence attached to the deployment. It should not take ownership of the deployment result.
If optional inspection fails after a successful deployment, record that failure separately. Do not erase the successful production event. If inspection is mandatory policy, run it as a gate before deployment.
Separate deployment from registration failure
The production operation and the reporting call need separate outcomes:
deployment: succeeded
registration: failed
That state is uncomfortable, but it is accurate. The operator can retry registration without redeploying the application or pretending production is unchanged.
Likewise:
deployment: failed
registration: not sent
should remain distinct from a change-registration API outage.
Keep every deployment event truthful
Central reporting works only when every event means the same thing.
Register the production change after it happens. Preserve the exact artifact identity. Add inspection evidence where it helps people understand the change. Keep failures visible instead of converting them into a more convenient state.
The dashboard may contain fewer deployment events, but each one will identify a real production change.
Read the practical guide to an audit-ready Exstream change record.