Components connect source code repositories to platform features and enable software delivery workflows. This page explains component architecture, capabilities, and how components serve as the foundation for CI/CD automation.
Component fundamentals
Components serve as the key link between source code and the downstream features of CloudBees Unify, enabling secure, robust, and efficient software delivery. As the foundational element of the platform, a component represents the connection point where source code repositories integrate with workflow automation, security analysis, artifact management, and deployment orchestration.
Components can range from simple software projects built and deployed from source code to complex elements of multi-component applications. This flexibility allows the platform to accommodate diverse software delivery scenarios, from individual microservices to sophisticated distributed systems composed of many interconnected parts.
The component model enables users to create and manage complex CI/CD workflows by providing a consistent abstraction layer over source code repositories. Rather than working directly with repository-specific APIs and webhook systems, users interact with components that normalize these differences and provide a unified interface for workflow automation.
Components also serve as the organizational unit for security analysis, artifact tracking, and deployment management. When security scans execute, artifacts are generated, or deployments occur, these activities are organized and tracked within the context of their associated component.
| Linking components to an application along with a repository enables CloudBees Unify to scan source code and display feature flag code references, which track where feature flags are used across different components and services in your application. For setup instructions, refer to Set up code references. |
Repository integration model
Each component connects to exactly one source code repository through an SCM integration. This one-to-one mapping ensures unambiguous ownership of workflow triggers, security analysis, and artifact generation, preventing scenarios where multiple components claim the same repository, or a repository lacks clear component association.
SCM integrations provide the technical bridge between repository events and platform workflows. When commits are pushed, pull requests are created, or branches are merged, the SCM integration translates these repository events into platform triggers that can initiate workflows, security scans, or other automated processes.
The repository integration model supports various source code management systems while presenting a consistent interface to component features. Whether using GitHub, GitLab, Bitbucket, or other SCM systems, components provide the same capabilities and workflow patterns, abstracting away platform-specific differences.
Component capabilities and features
Components provide access to a comprehensive suite of software delivery capabilities through a tabbed interface that organizes functionality by domain. This organization reflects the different phases and aspects of software delivery, from initial development through production deployment and ongoing monitoring.
The Summary tab provides a dashboard view of component activity, including commit history, build status, deployment tracking, and security scan results. This centralized view enables teams to quickly assess the current state of their component and identify any issues requiring attention.
Workflow execution capabilities through the Runs and Workflows tabs enable teams to define, execute, and monitor automated processes triggered by repository events. These workflows can encompass building, testing, security scanning, artifact generation, and deployment orchestration, providing end-to-end automation for software delivery pipelines.
Security analysis integration through Security Overview and Security Center tabs provides continuous monitoring of security posture. Components automatically trigger security scans when created or when code changes are committed, enabling teams to identify and address security issues early in the development cycle.
Artifact management through the Artifacts tab tracks build outputs, deployment packages, and other generated assets throughout their lifecycle. This tracking includes version history, labeling, deployment status, and relationships between different artifact versions.
Environment inventory capabilities provide visibility into where different artifact versions are currently deployed across various environments. This deployment tracking helps teams understand the current state of their software across development, staging, and production environments.
Properties management enables components to define and inherit configuration values that can be used within workflows and other platform features. Properties can be defined at the component level or inherited from parent organizations, providing flexible configuration management patterns.
Component identity and workflow integration
Every component receives a unique component ID in the form of a universally unique identifier (UUID) that serves as its canonical identifier within the platform. This component ID appears in URLs, API calls, and configuration files where programmatic access requires unambiguous component identification.
Component IDs enable external systems and automated processes to target specific components for workflow triggers, API operations, and integration scenarios. Features like remote workflow triggering and multi-component orchestration rely on component IDs to ensure that operations target the correct component context.
The component context affects how workflows execute and what resources they can access. Workflows running within a component context have access to that component’s properties, can generate artifacts associated with the component, and operate within the component’s organizational and security boundaries.
External systems integrate with CloudBees Unify components by referencing component IDs to maintain clear separation between different codebases and their automation. For example, external monitoring tools use component IDs to associate performance metrics with specific components, while deployment systems reference component IDs to track which artifacts belong to which codebase.
The workflow integration model enables components to participate in complex automation scenarios while maintaining clear ownership and organizational boundaries. Whether components operate independently or as part of larger application releases, their identity and context ensure that automation activities remain properly associated and organized.