Bicep
Overview
Bicep artifacts enable you to manage Azure infrastructure using native Bicep templates while taking full advantage of Bluebricks’ orchestration, environment management, and deployment automation. With a Bicep artifact, you can describe Azure resources declaratively using the Bicep language, then execute and track deployments consistently across all environments through Bluebricks.
Defining your Bicep module as an artifact allows you to centralize configuration, apply environment-specific parameters, and integrate infrastructure changes directly into your deployment pipelines. Bluebricks enhances the Bicep workflow with capabilities designed to simplify and standardize Azure provisioning, including:
Built-in orchestration for plan and deploy operations, with full visibility into diffs and applied changes
Managed handling of parameters and secrets, enabling secure and dynamic configuration
Consistent environment workflows, ensuring repeatable deployments across multiple Azure subscriptions or resource groups
Versioning and deployment history tracking, giving teams clear auditability for all infrastructure changes
Native integration with Azure authentication, reducing the operational burden of managing credentials
Optional built-in destroy mechanism, by combining Bluebricks’ modular architecture with Bicep’s complete mode, you can break complex infrastructure into granular components that are simple to deploy, update, and destroy.
Package Dependencies and Data Flow
Packages expose inputs (properties) and outputs, enabling them to participate in flexible, modular dependency chains orchestrated through a directed acyclic graph (DAG).
Inputs define the parameters a package requires and can be statically defined or dynamically derived using expressions that reference other packages, blueprint properties, or secrets. These expressions create explicit dependencies between packages, allowing the orchestrator to determine the correct execution order. Inputs also support conditional expressions, enabling packages to be included or excluded based on runtime context.
Outputs represent values produced during package execution—such as resource identifiers, endpoints, or computed configurations—and become available for consumption by downstream packages. This creates a bidirectional dependency flow where packages can safely reference one another’s results.
This design enables unified orchestration across multiple infrastructure-as-code technologies—Terraform, Helm, Bicep, and CloudFormation can coexist within a single blueprint, sharing data and dependencies seamlessly. The orchestrator provides a single plan, single execution flow, and unified state management regardless of the underlying IaC tool. Packages can be sourced from artifacts or directly from Git repositories, allowing complex systems to be built from small, reusable, independently versionable units. The dependency graph is calculated at plan time, ensuring deterministic execution order and enabling parallel execution where dependencies allow.
Last updated
Was this helpful?

