CloudBees Unify has five main configuration areas that work together to support your workflows. Understanding how these areas connect helps you make better administrative decisions and avoid configuration problems.
The five areas are:
-
Properties store secrets and configuration values that workflows need. You can set properties at the organization level or override them for specific environments. This keeps sensitive data out of your code while making it available to workflows.
-
Environments represent deployment targets like development, staging, and production. Each environment can have its own properties, approval requirements, and access controls. Environments help you control how code moves from development to production.
-
Containers define the runtime environment for your workflow jobs. You configure which container images to use, what software is installed, and resource limits. Container configuration affects whether your workflows run consistently and reliably.
-
Preconfigured actions let you create approved libraries of workflow actions. Instead of letting developers use any action from the internet, you can provide curated, secure actions. This improves security while making it easier for developers to build workflows.
-
Notifications send alerts about workflow results, security events, and system issues. You can configure different notification rules for different types of events and different environments.
How configuration affects security
Configuration controls security across your platform:
-
Properties control who can access secrets and sensitive values. You can set permissions so only specific users or teams can read or modify certain properties. This prevents secrets from being exposed in code or logs.
-
Preconfigured actions limit what external code can run in your workflows. Instead of allowing any action from GitHub or other sources, you approve specific actions that your security team has reviewed. This reduces supply chain security risks.
-
Environments enforce different security requirements for different deployment stages. You might allow automatic deployments to development but require manual approval for production. You can also restrict which teams can deploy to which environments.
-
Containers control the runtime security of your workflows. You choose which base images to use, what software is available, and what system resources workflows can access. These decisions affect the security of every workflow that runs.
Configuration inheritance
Configuration works in layers, from broad organizational settings down to specific environments:
-
Organization level sets the defaults for everything. You define base container images, approved actions, default properties, and basic security policies. These settings apply to all teams unless overridden.
-
Team level can customize settings for specific teams. Teams might use different container images for their technology stack or have their own notification preferences. Teams can only override settings that organizational policy allows.
-
Environment level provides the most specific configuration. You can override properties for specific environments, require different approvals for production deployments, or send different notifications based on environment criticality.
This hierarchy lets you balance control with flexibility. You can set secure defaults at the organization level while letting teams customize what they need for their specific workflows.
How configuration affects workflows
Your configuration choices directly affect how well workflows run:
-
Properties make workflows flexible or rigid. If you provide the right properties, workflows can adapt to different environments automatically. If properties are missing or misconfigured, workflows fail or get hardcoded with specific values.
-
Containers determine workflow reliability. If your container images have the right software installed and adequate resources, workflows run consistently. If containers are misconfigured, workflows fail with missing dependencies or resource limits.
-
Environments control deployment speed and safety. Simple approval requirements let code deploy quickly. Complex approval workflows add safety but slow down deployments.
-
Notifications determine how quickly you find and fix problems. Good notification rules alert the right people when workflows fail. Poor notification setup means problems go unnoticed until users complain.
Planning configuration changes
Configuration areas are connected, so changes in one area can affect others. When you add environments, you also need to set up properties, notification rules, and possibly container configurations for that environment. Updating container images can break workflows that depend on specific software versions. Changing property permissions affects which workflows can run successfully.
Because of these connections, configuration changes can have unexpected consequences. A simple container update might break dozens of workflows. A property permission change might stop deployments to production. This is why you need to plan changes carefully and test them first.
The inheritance hierarchy also creates trade-offs between control and flexibility. If you centralize too much control at the organization level, teams can’t adapt configuration to their needs and you become a bottleneck. If you give teams too much autonomy, you lose consistency and create security risks. The right balance depends on your organization’s size, security requirements, and team maturity.