Understanding environments

CloudBees Unify environments pause workflow execution when approvals are required, rather than failing or queuing the deployment. This design keeps your workflow context alive while waiting for human intervention.

The approval happens at the job level, not the workflow level. If your workflow has multiple jobs, only jobs that reference approval-required environments pause. Other jobs in the same workflow continue running normally. This granular control lets you design workflows where some steps run automatically while deployment steps wait for approval.

Approval permissions tie into component-level RBAC. You need Admin role on the component to approve deployments, not just environment access. This design ensures that approval authority matches component responsibility.

The approval creates an audit trail linked to the specific workflow run. You can trace who approved what deployment and when, which supports both troubleshooting and compliance requirements.

Environment properties override component and organization properties through runtime binding, not build-time substitution. Your workflow expressions resolve property values when the job runs, not when you commit the workflow.

This runtime binding has important implications:

The inheritance order is:

If the same property exists at multiple levels, the most specific level wins. Missing properties at the environment level fall back to component level, then organization level.

Environment properties only affect jobs that explicitly reference that environment. Jobs without environment references use component and organization properties normally. This scoping prevents environment-specific configuration from affecting unrelated workflow steps.

CloudBees Unify automatically updates the environment inventory when deployments complete successfully. The inventory tracks artifact versions, not just "what’s deployed" generically.

This tracking happens through workflow instrumentation, not external deployment detection. Your workflow must explicitly use deployment actions that report to the environment inventory. Simple shell commands or custom deployment scripts won’t update the inventory automatically.

The inventory design makes some important trade-offs:

Failed deployments don’t update inventory, so the inventory shows the last known successful state. This design prevents inventory pollution from partial deployments, but means you need deployment monitoring to track failure states.

The inventory supports rollback workflows by showing previous versions deployed to each environment. However, the rollback logic is up to your workflows: the inventory provides data, not automated rollback capabilities.

CloudBees Unify environments can be organization-owned (inherited by all components) or component-specific. This inheritance model affects both access controls and configuration management.

Organization-owned environments appear in all components automatically. You can’t modify or delete inherited environments at the component level - changes must happen at the organization level. This design enforces consistent governance policies across all teams.

Component-specific environments give teams local control but limit reusability. A component-specific "staging" environment only exists for that component, even if other components need similar staging environments.

The inheritance model offers two approaches, each with different benefits: * Inherited environments provide consistency and reduce administrative overhead, with less customization flexibility. * Component environments provide team flexibility and ownership, with more administrative overhead.

Environment access follows component RBAC boundaries. Your component permissions determine whether you can deploy to environments, regardless of whether the environment is inherited or component-specific. This design keeps environment access aligned with code ownership and component responsibility.