A safe place to test every feature
A two-repository pilot for isolated preview environments, tested image promotion and automated cleanup.
Two-repository pilot: promote the tested image, then remove preview resources when the PR closes.
Contribution at a glance
- My responsibility
- CI workflows, ArgoCD ApplicationSets, Helm configuration and preview lifecycle.
- Scope
- A two-repository Go/Node pilot; broader company adoption is outside the delivered scope.
- Collaboration & boundaries
- I built the platform integration connecting related repositories; the case does not claim organization-wide developer adoption.
- Outcome
- 34 checks before builds, verified same-image promotion and cleanup when the pull request closes.
The problem
QA depended on shared development and staging environments. Features often met each other only after merging, making it difficult to test a backend/frontend change in isolation and coordinate work across teams.
My contribution
I built a preview-environment pilot across a Go backend and a Node frontend. The work covered CI workflows, ArgoCD ApplicationSets, Helm configuration, namespace lifecycle, TLS, integration between the two applications and the cleanup path when a pull request closed.
The decisions
A shared branch-name convention lets related repositories land in the same preview namespace. That allows a frontend to reach its matching backend through an internal service without treating every repository as an isolated demonstration.
I separated build/test workflows from deployment workflows. Production and sandbox promotion reused the tested staging image rather than rebuilding it. The image digest was checked across environments, so promotion meant moving the tested binary rather than reproducing a build and assuming equivalence.
Previews used a deliberately smaller runtime configuration than persistent environments. Creation was only half the feature: closing or merging the pull request also had to remove the application, namespace and preview images.
Validation
The pilot ran 34 automated checks before builds: 16 for Go and 18 for Node. Cleanup was exercised end to end, and application health and synchronization were checked in ArgoCD. Separate tests verified image promotion without rebuilding.
Results and measurement
The completion record documents both pilot repositories working through the preview flow, eight ArgoCD applications synchronized and healthy, and identical image digests during promotion. One observed push-to-deploy path took approximately 2 minutes 14 seconds; it is a pilot observation, not a fleet-wide deployment-time guarantee.
The scope was two pilot repositories. Wider adoption, aggregate developer time saved and changes in defect escape rate were not measured in this record. A completed pilot does not establish company-wide adoption or a production-hardening outcome.
What I learned
A platform feature becomes useful when it connects to the team's workflow. Shared preview namespaces, reliable promotion and explicit cleanup mattered as much as creating the initial deployment.
Decisions and next steps
A retrospective view of the approach and its limits. The next improvement is a proposal, not a delivered result.
Alternative and rationale
Shared staging uses fewer environments; isolated previews reduce feature collisions but require lifecycle and cross-repository conventions.
Trade-off
An environment that is easy to create still needs safe promotion and dependable cleanup to avoid stale resources and spend.
What I would improve next
Next improvement: measure adoption, preview readiness time and orphaned-resource cost before expanding beyond the pilot.