How do you manage CI/CD across enterprise environments?

One straightforward setup is a single end-to-end pipeline with trunk-based development. Run the relevant checks on pushes, build a preview environment for a proposed change, then deploy after review and merge. A staging step can sit before production when you need another place to validate changes.

Tool choice depends on constraints. GitLab CI, for example, can be useful where a self-managed installation is required. Keeping pipeline definitions in version control also lets engineers review changes alongside the code.

Build the artifact once and promote that exact image through the environments. If you rebuild for production, a changed dependency or build input can mean you're shipping something different from what passed staging.

Keep environment-specific configuration and secrets outside the image. That way the artifact stays the same while each environment supplies what it needs.

CI and deployment don't have to be the same system. One option is to use GitLab to build images without giving the build system access to the environments, then use Argo CD to sync deployments from a repository. Sync can be automatic or manual.

That separation gives you a different access boundary, though it also means managing the deployment configuration and permissions for another tool.

For some setups, staging to production is enough for routine changes, with temporary development environments reserved for heavier or experimental testing. Those temporary environments can resemble staging and production while using smaller compute resources. An end-to-end pipeline can create them when needed, rather than keeping every test environment running all the time.