Blueprint Developer Guide - Getting Started
Blueprint Developer Guide - Getting Started​
This guide is for developers who want to create custom deployment blueprints by combining existing components. Blueprints define complete deployment scenarios for specific use cases.
🎯 Become an Expert Blueprint Developer: Accelerate your learning with our Learning Platform. Explore the Edge-to-Cloud Systems Track for comprehensive training on AI-assisted composition of multi-component system architectures and blueprint creation.
Understanding Blueprint Architecture​
What are Blueprints?​
Blueprints are deployment templates that:
- Combine multiple components into cohesive solutions
- Define infrastructure for specific scenarios (single-node, multi-node, etc.)
- Provide consistent interfaces across Terraform and Bicep implementations
- Include validation and testing procedures
Blueprint Structure​
blueprints/
├── {blueprint-name}/
│ ├── README.md # Blueprint documentation
│ ├── terraform/
│ │ ├── main.tf # Main Terraform configuration
│ │ ├── variables.tf # Input parameters
│ │ ├── outputs.tf # Output values
│ │ ├── terraform.tfvars.example # Example configuration
│ │ └── modules/ # Local modules (if needed)
│ └── bicep/
│ ├── main.bicep # Main Bicep template
│ ├── parameters.json # Example parameters
│ └── modules/ # Local modules (if needed)
Component Integration​
Blueprints reference components from the src/ directory:
src/
├── 000-cloud/
│ ├── 010-security-identity/ # Identity and security
│ ├── 020-networking/ # Network infrastructure
│ └── 030-storage/ # Storage solutions
└── 100-edge/
├── 110-iot-ops/ # IoT Operations
├── 120-kubernetes/ # Kubernetes cluster
└── 130-monitoring/ # Monitoring and observability
Development Environment Setup​
Dev Container Configuration​
Note: The Dev Container auto-installs the HVE Core extension, which provides AI prompts, agents, and coding instructions for this project.
-
Open the repository in VS Code:
git clone {{CLONE_URL}}cd edge-aicode . -
Reopen in Dev Container:
- Click "Reopen in Container" when prompted
- Or use Command Palette:
Remote-Containers: Reopen in Container
-
Verify development tools:
# Infrastructure toolsterraform versionaz version# Development toolsgit --versionnpm --version# Linting toolsnpm run lint --help
Git Configuration​
Configure Git for blueprint development:
# Set your identity
git config --global user.name "Your Name"
git config --global user.email "your.email@domain.com"
# Configure commit template for conventional commits
git config --global commit.template .github/.gitmessage
# Set up SSH (if using SSH authentication)
ssh-keygen -t ed25519 -C "your.email@domain.com"
Creating a New Blueprint​
Step 1: Plan Your Blueprint​
Before coding, define:
- Target scenario: What problem does this blueprint solve?
- Required components: Which components from
src/do you need? - Dependencies: What order should components be deployed?
- Parameters: What should be configurable by users?
Step 2: Create Blueprint Structure​
-
Create blueprint directory:
mkdir -p blueprints/my-custom-blueprint/{terraform,bicep}cd blueprints/my-custom-blueprint -
Create README.md:
# Create from templatecp ../full-single-node-cluster/README.md ./README.md# Edit to describe your blueprintcode README.md
Step 3: Implement Terraform Version​
-
Create main.tf:
# blueprints/my-custom-blueprint/terraform/main.tfterraform {required_version = ">= 1.0"required_providers {azurerm = {source = "hashicorp/azurerm"version = "~> 3.0"}}}provider "azurerm" {features {}}# Reference existing componentsmodule "identity" {source = "../../../src/000-cloud/010-security-identity/terraform"location = var.locationresource_group_name = var.resource_group_nameenvironment = var.environment}module "networking" {source = "../../../src/000-cloud/020-networking/terraform"location = var.locationresource_group_name = var.resource_group_nameenvironment = var.environmentdepends_on = [module.identity]} -
Create variables.tf:
# blueprints/my-custom-blueprint/terraform/variables.tfvariable "location" {description = "Azure region for resources"type = stringdefault = "East US"}variable "resource_group_name" {description = "Name of the resource group"type = string}variable "environment" {description = "Environment name (dev, test, prod)"type = stringdefault = "dev"} -
Create outputs.tf:
# blueprints/my-custom-blueprint/terraform/outputs.tfoutput "resource_group_name" {description = "Name of the created resource group"value = var.resource_group_name}output "identity_principal_id" {description = "Principal ID of the managed identity"value = module.identity.principal_id} -
Create terraform.tfvars.example:
# blueprints/my-custom-blueprint/terraform/terraform.tfvars.examplelocation = "East US"resource_group_name = "rg-my-custom-blueprint"environment = "dev"
Step 4: Implement Bicep Version​
-
Create main.bicep:
// blueprints/my-custom-blueprint/bicep/main.bicep@description('Azure region for resources')param location string = 'East US'@description('Name of the resource group')param resourceGroupName string@description('Environment name')@allowed(['dev', 'test', 'prod'])param environment string = 'dev'// Reference existing componentsmodule identity '../../../src/000-cloud/010-security-identity/bicep/main.bicep' = {name: 'identity-deployment'params: {location: locationresourceGroupName: resourceGroupNameenvironment: environment}}module networking '../../../src/000-cloud/020-networking/bicep/main.bicep' = {name: 'networking-deployment'params: {location: locationresourceGroupName: resourceGroupNameenvironment: environment}dependsOn: [identity]}// Outputsoutput resourceGroupName string = resourceGroupNameoutput identityPrincipalId string = identity.outputs.principalId -
Create parameters.json:
{"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#","contentVersion": "1.0.0.0","parameters": {"location": {"value": "East US"},"resourceGroupName": {"value": "rg-my-custom-blueprint"},"environment": {"value": "dev"}}}
Testing and Validation​
Blueprint Test Infrastructure​
Selected blueprints include comprehensive test suites using Go and the Terratest framework. Tests validate both infrastructure declarations and actual deployments.
Test Types:
- Contract Tests - Fast static validation ensuring output declarations match test expectations (runs in seconds, zero Azure cost)
- Deployment Tests - Full end-to-end validation creating real Azure resources and testing functionality (30-45 minutes, creates billable resources)
Available Test Infrastructure:
- Shared utilities: src/900-tools-utilities/904-test-utilities/ - Reusable test functions for all blueprints
- Reference implementation: blueprints/full-single-node-cluster/tests/ - Complete test suite example
Creating Tests for Your Blueprint​
-
Create test directory structure:
cd blueprints/my-custom-blueprintmkdir testscd tests -
Initialize Go module:
go mod init github.com/microsoft/edge-ai/blueprints/my-custom-blueprint/testsgo get github.com/microsoft/edge-ai/src/900-tools-utilities/904-test-utilitiesgo get github.com/gruntwork-io/terratest/modules/terraform -
Define output contract in
tests/outputs.go:Define a struct matching your blueprint's outputs with framework-specific tags.
See: full-single-node-cluster/tests/outputs.go for pattern
-
Create contract tests:
Create
contract_terraform_test.goandcontract_bicep_test.gothat validate declared outputs match your struct.See: full-single-node-cluster/tests/contract_terraform_test.go
-
Create deployment tests:
Create
deploy_terraform_test.goanddeploy_bicep_test.gofor end-to-end validation.See: full-single-node-cluster/tests/deploy_terraform_test.go
-
Add helper scripts:
Copy and adapt
run-contract-tests.shandrun-deployment-tests.shfrom the reference implementation.
Running Tests​
Contract tests (fast, run before every commit):
cd blueprints/my-custom-blueprint/tests
./run-contract-tests.sh both
Deployment tests (slow, run before PR):
# Set cleanup to auto-delete resources
export CLEANUP_RESOURCES=true
# Run tests
./run-deployment-tests.sh terraform # or bicep, or both
Documentation: See src/900-tools-utilities/904-test-utilities/README.md for complete testing guide and API reference
Linting and Code Quality​
Run validation tools before committing:
# Terraform validation
cd blueprints/my-custom-blueprint/terraform
terraform init
terraform validate
terraform fmt -check
# Bicep validation
cd ../bicep
az bicep build --file main.bicep
# Repository-wide linting
cd ../../..
npm run lint
Local Testing​
-
Test Terraform deployment:
cd blueprints/my-custom-blueprint/terraform# Initializeterraform init# Plan (dry-run)terraform plan -var-file="terraform.tfvars.example"# Apply for testingterraform apply -var-file="terraform.tfvars.example"# Cleanupterraform destroy -var-file="terraform.tfvars.example" -
Test Bicep deployment:
cd blueprints/my-custom-blueprint/bicep# Create resource groupaz group create --name "rg-test-blueprint" --location "East US"# Deploy templateaz deployment group create \--resource-group "rg-test-blueprint" \--template-file main.bicep \--parameters @parameters.json# Cleanupaz group delete --name "rg-test-blueprint" --yes
Best Practices​
Blueprint Integration Best Practices​
- Use component outputs as inputs: Pass outputs from one component as inputs to another
- Respect dependencies: Use
depends_on(Terraform) ordependsOn(Bicep) for proper ordering - Maintain consistency: Ensure Terraform and Bicep implementations produce equivalent results
- Follow naming conventions: Use consistent resource naming across components
- Include test coverage: Add contract and deployment tests for your blueprint
- Document test requirements: Update README with test setup and usage instructions
Testing Best Practices​
- Run contract tests first: Catch configuration errors before expensive deployments
- Use CLEANUP_RESOURCES: Enable automatic cleanup during development to avoid resource accumulation
- Test both frameworks: Ensure Terraform and Bicep produce equivalent results
- Update tests with changes: Keep output contracts and validation logic synchronized with blueprint changes
- Validate before PR: Run full deployment tests before submitting pull requests
Documentation Standards​
- Document parameters: Clearly describe all input parameters
- Provide examples: Include realistic example configurations
- Explain use cases: Document when to use this blueprint
- Include diagrams: Visual representations help users understand the architecture
Security Considerations​
- Principle of least privilege: Grant minimal required permissions
- Use managed identities: Avoid storing credentials in configurations
- Enable logging: Include monitoring and audit capabilities
- Network security: Implement proper network isolation and access controls
GitHub Copilot for Blueprint Development​
Effective Prompts​
Use these patterns when working with GitHub Copilot:
- "Create a Terraform module that references the identity component from src/000-cloud/010-security-identity/"
- "Generate Bicep parameters for a multi-node Kubernetes deployment"
- "Help me debug this component dependency error in my blueprint"
- "Explain the outputs I need from the networking component for IoT Operations"
Project-Specific Prompts​
Note: These prompts are provided by the HVE Core extension, which is auto-installed in the Dev Container.
Use repository-specific prompts for blueprint development:
- Pull Request Creation: Use
/pull-requestin Copilot Chat for automated PR generation - Task Planning: Use
/task-plannerfor complex blueprint development tasks - Component Analysis: Ask about specific components in the
src/directory
Conventional Commits and PR Process​
Commit Message Format​
Follow conventional commit format for blueprint changes:
feat(blueprints): add custom IoT edge deployment blueprint
- Combines identity, networking, and IoT Operations components
- Supports both single and multi-node configurations
- Includes comprehensive testing and validation
- Provides Terraform and Bicep implementations
Closes #123
Pull Request Process​
-
Create feature branch:
git checkout -b feature/custom-iot-blueprint -
Make your changes following the guidelines above
-
Test thoroughly:
npm run lint./tests/blueprints/my-custom-blueprint/test.sh -
Commit with conventional format:
git add .git commit -m "feat(blueprints): add custom IoT edge deployment blueprint" -
Create pull request using the GitHub CLI or UI:
gh pr create --title "feat(blueprints): add custom IoT edge deployment blueprint" --body "Description of changes" -
Use PR prompt in GitHub Copilot for automated PR description generation
Next Steps​
After creating your blueprint:
- Update CI/CD: Add your blueprint to automated testing pipelines
- Create documentation: Write comprehensive usage guides
- Share with community: Present your blueprint for review and feedback
- Iterate based on feedback: Improve based on user testing and suggestions
Additional Resources​
- Feature Developer Guide - Contribute new components
- Component Documentation - Understanding existing components
- AI-Assisted Engineering - Using GitHub Copilot for blueprint development
- Terraform Best Practices - Official Terraform guidelines
- Bicep Best Practices - Official Bicep guidelines
- Azure IoT Operations Documentation - Platform-specific guidance
This guide is part of the AI on Edge Flagship Accelerator project. For the latest updates and comprehensive resources, visit our project repository.
🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers.