Development / FIELD GUIDE

Git history. Release clarity.

A repository records source changes. Your operating process should also explain which artifact was reviewed, where it was published, and what happened afterward.

Connect revision to artifact

Build an identifiable package and run relevant checks against the result. For a static site, inspect generated links and assets. For an application, include the runtime and integration tests your release needs. Preserve the relationship between test evidence and the exact artifact.

Name environments and their purpose

GitLab documents environments as deployment destinations. Keep preview, staging, and production roles clear, with appropriate credentials and ownership. Document differences that limit what a successful staging test can prove about production.

Make promotion accountable

An approval should refer to a specific release, target, and recovery plan. Scope the deployment identity to its job. Verify the public result after publication and retain the preceding artifact without assuming that it alone can reverse changes to live data.

Official reference: GitLab environments documentation ↗. Check version-specific details before applying changes.