| title | Feature Developer Guide - Getting Started | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| description | Comprehensive guide for contributors developing new features and components in the AI on Edge Flagship Accelerator, covering development environment, processes, and coding standards | |||||||||||
| author | Edge AI Team | |||||||||||
| ms.date | 2025-06-15 | |||||||||||
| ms.topic | how-to | |||||||||||
| estimated_reading_time | 10 | |||||||||||
| keywords |
|
This guide is for contributors who want to add new features, components, or improve existing functionality in the AI on Edge Flagship Accelerator. It provides comprehensive guidance on the development environment, processes, and standards.
🚀 Boost Your Development Velocity: Build proficiency in AI-assisted engineering with our Learning Platform. Start with the AI-Assisted Engineering Track to learn advanced GitHub Copilot techniques and hyper-velocity development practices.
The repository follows a structured component-based architecture:
edge-ai/
├── src/ # Source components
│ ├── 000-cloud/ # Cloud infrastructure components
│ │ ├── 000-resource-group/ # Resource group provisioning
│ │ ├── 010-security-identity/ # Identity and security
│ │ ├── 020-observability/ # Cloud-side monitoring and logging
│ │ ├── 030-data/ # Data storage and management
│ │ ├── 031-fabric/ # Microsoft Fabric resources
│ │ ├── 032-fabric-rti/ # Microsoft Fabric Real-Time Intelligence
│ │ ├── 040-messaging/ # Event Grid, Event Hubs, Service Bus
│ │ ├── 050-networking/ # Virtual networks and network security
│ │ ├── 051-vm-host/ # Virtual machine provisioning
│ │ ├── 060-acr/ # Azure Container Registry
│ │ └── 070-kubernetes/ # Kubernetes cluster configuration
│ └── 100-edge/ # Edge infrastructure components
│ ├── 100-cncf-cluster/ # CNCF-compliant cluster (K3s) with Arc
│ ├── 110-iot-ops/ # Azure IoT Operations infrastructure
│ ├── 111-assets/ # Asset management for IoT Operations
│ ├── 120-observability/ # Edge-specific observability
│ └── 130-messaging/ # Edge messaging and data routing
├── blueprints/ # Deployment templates
├── docs/ # Documentation
├── scripts/ # Automation scripts
└── tests/ # Test suites
Components follow a decimal naming pattern for deployment order:
- Grouping:
{000}-{grouping_name}(e.g.,000-cloud,100-edge) - Components:
{000}-{component_name}(e.g.,010-security-identity) - Frameworks: Each component supports both
terraform/andbicep/implementations
Components can contain internal modules:
- Location:
src/{grouping}/{component}/{framework}/modules/{internal_module} - Scope: Internal modules are ONLY referenced from their parent component
- Rule: Never reference internal modules from outside the component
The Dev Container provides a fully configured development environment with all necessary tools and dependencies.
-
Prerequisites:
- Docker Desktop installed and running
- Visual Studio Code with Dev Containers extension
- HVE Core extension — provides AI prompts and agents (auto-installed in Dev Container)
- Git configured with your credentials
-
Clone and open repository:
git clone {{CLONE_URL}} cd edge-ai code . -
Launch Dev Container:
- When prompted, click "Reopen in Container"
- Or use Command Palette:
Remote-Containers: Reopen in Container
Configure Git for development work:
# Set your identity
git config --global user.name "Your Name"
git config --global user.email "your.email@domain.com"
# Set default branch
git config --global init.defaultBranch main
# Configure pull behavior
git config --global pull.rebase falseFor SSH authentication with GitHub:
-
Generate SSH key (if you don't have one):
ssh-keygen -t ed25519 -C "your.email@domain.com" -
Add to SSH agent:
eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_ed25519
-
Add public key to GitHub: Copy
~/.ssh/id_ed25519.pubto your GitHub SSH keys
The project uses package.json for standardized development tasks:
# Development and linting
npm install # Install dependencies
npm run lint # Run all linters
npm run lint-fix # Fix common linting issues
npm run lint-devcontainer # Run linters (Dev Container optimized)
npm run lint-fix-devcontainer # Fix linters (Dev Container optimized)
# Markdown and documentation
npm run mdlint # Run markdown linting
npm run mdlint-fix # Fix markdown issues
npm run cspell # Run spell check
# Security and compliance
npm run checkov-changes # Security scan on changed folders
npm run checkov-all # Security scan on all folders
# Language and link checking
npm run link-lang-check # Check for language-specific links
npm run link-lang-fix # Fix language-specific linksThe Dev Container includes comprehensive linting and quality tools:
-
MegaLinter: Comprehensive multi-language linting
- Configuration:
.mega-linter.yml - Runs automatically in CI/CD
- Documentation:
docs/build-cicd/azure-pipelines/templates/megalinter-template.md
- Configuration:
-
Terraform Tools:
terraform fmt- Code formattingterraform validate- Configuration validationtflint- Advanced Terraform lintingcheckov- Security scanning
-
Bicep Tools:
az bicep build- Template compilationaz bicep lint- Template validation
-
Markdown Tools:
markdownlint- Markdown lintingmarkdown-table-formatter- Table formattingcspell- Spell checking
-
Security Tools:
checkov- IaC security scanninggitleaks- Secret detectiongrype- Vulnerability scanning
Keep your development environment updated:
# Update Dev Container
# Use Command Palette: "Remote-Containers: Rebuild Container"
# Update npm dependencies
npm update
# Update Azure CLI extensions
az extension update --name azure-iot
# Update Terraform providers
terraform init -upgradeBefore coding, define:
- Purpose: What problem does this component solve?
- Grouping: Does it belong in
000-cloudor100-edge? - Dependencies: What other components does it depend on?
- Interfaces: What inputs and outputs will it provide?
-
Create component directory:
# Choose appropriate grouping and number (use next available number) # Check existing components first: ls src/000-cloud/ # Use the next available number (e.g., 080, 090, etc.) mkdir -p src/000-cloud/{next-number}-{component-name}/{terraform,bicep} cd src/000-cloud/{next-number}-{component-name} # Example with actual numbers: # mkdir -p src/000-cloud/080-storage/{terraform,bicep} # cd src/000-cloud/080-storage
-
Create main README.md:
Create the main component README.md with YAML front matter and comprehensive documentation:
--- title: My Component Name description: Brief description of what this component does and its role in the Edge AI Accelerator author: Edge AI Team ms.date: YYYY-MM-DD ms.topic: reference keywords: - relevant - keywords - for - search estimated_reading_time: 3 --- ## My Component Name Detailed description of the component's purpose and role within the Edge AI Accelerator architecture. ## Purpose and Role - What problems this component solves - How it integrates with other components - Its position in the deployment sequence ## Dependencies - Component A (010-security-identity) - Component B (050-networking) ## Usage See framework-specific README.md files for detailed usage instructions: - [Terraform Implementation](./terraform/README.md) - [Bicep Implementation](./bicep/README.md) --- <!-- markdownlint-disable MD036 --> *🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers.* <!-- markdownlint-enable MD036 -->
Important: Framework-specific README.md files (in
./terraform/and./bicep/directories) are automatically generated bynpm run tf-docsandnpm run bicep-docsscripts. Never edit these files manually.
-
Create main.tf:
# src/000-cloud/{next-number}-{component-name}/terraform/main.tf terraform { required_version = ">= 1.0" required_providers { azurerm = { source = "hashicorp/azurerm" version = "~> 3.0" } } } # Component implementation resource "azurerm_resource_group" "main" { name = var.resource_group_name location = var.location tags = var.tags }
-
Create variables.tf:
# src/000-cloud/{next-number}-{component-name}/terraform/variables.tf variable "location" { description = "Azure region for resources" type = string } variable "resource_group_name" { description = "Name of the resource group" type = string } variable "tags" { description = "Tags to apply to resources" type = map(string) default = {} }
-
Create outputs.tf:
# src/000-cloud/{next-number}-{component-name}/terraform/outputs.tf output "resource_group_name" { description = "Name of the created resource group" value = azurerm_resource_group.main.name } output "location" { description = "Azure region of the resource group" value = azurerm_resource_group.main.location }
-
Generate framework documentation:
After implementing both frameworks, generate the framework-specific README.md files:
# Generate Terraform documentation npm run tf-docs # Generate Bicep documentation npm run bicep-docs # Fix any markdown linting issues npm run mdlint-fix
Critical: The
./terraform/README.mdand./bicep/README.mdfiles are auto-generated and should NEVER be edited manually. They are generated from:- Terraform: Comments in
.tffiles and the.terraform-docs.ymlconfiguration - Bicep: Parameter descriptions and the
generate-bicep-docs.pyscript
- Terraform: Comments in
-
Create main.bicep:
// src/000-cloud/{next-number}-{component-name}/bicep/main.bicep @description('Azure region for resources') param location string @description('Name of the resource group') param resourceGroupName string @description('Tags to apply to resources') param tags object = {} // Component implementation resource resourceGroup 'Microsoft.Resources/resourceGroups@2021-04-01' = { name: resourceGroupName location: location tags: tags } // Outputs output resourceGroupName string = resourceGroup.name output location string = resourceGroup.location
Before committing, run comprehensive tests:
# Navigate to your component
cd src/000-cloud/{next-number}-{component-name}
# Test Terraform
cd terraform
terraform init
terraform validate
terraform fmt -check
terraform plan
# Test Bicep
cd ../bicep
az bicep build --file main.bicep
az bicep lint --file main.bicep
# Run repository-wide linting
cd ../../..
npm run lint-devcontainerCreate automated tests for your component:
# Create test directory
mkdir -p tests/components/{next-number}-{component-name}
# Create test script
cat > tests/components/{next-number}-{component-name}/test.sh << 'EOF'
#!/bin/bash
set -e
echo "Testing {next-number}-{component-name}..."
# Test Terraform
cd src/000-cloud/{next-number}-{component-name}/terraform
terraform init
terraform validate
terraform fmt -check
# Test Bicep
cd ../bicep
az bicep build --file main.bicep
echo "Component tests passed!"
EOF
chmod +x tests/components/{next-number}-{component-name}/test.shTest your component with dependent components:
# Create integration test blueprint
mkdir -p tests/integration/my-component-test/{terraform,bicep}
# Test component integration in a minimal blueprint
# This ensures your component works with othersAll commits must follow the conventional commit format. Use the GitHub Copilot /git-commit prompt to automatically stage and commit changes, or /git-commit-message to generate a commit message for manual use.
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
- feat: New feature or component
- fix: Bug fix
- docs: Documentation changes
- style: Code style changes (formatting, etc.)
- refactor: Code refactoring without functionality changes
- test: Adding or modifying tests
- chore: Build process or auxiliary tool changes
- ci: CI/CD configuration changes
The project includes custom Copilot prompts for commit workflows:
# Type in Copilot Chat: /git-commit
# This will stage all changes and create a conventional commit automatically# Stage your changes first
git add .
# Type in Copilot Chat: /git-commit-message
# This will generate a commit message for you to copy and use manually# Adding a new component
git commit -m "feat(components): add storage component with Terraform and Bicep implementations"
# Fixing a bug
git commit -m "fix(networking): resolve subnet configuration issue in multi-node deployments"
# Documentation update
git commit -m "docs(components): add usage examples for identity component"
# Refactoring
git commit -m "refactor(terraform): standardize variable naming across components"# Create and switch to feature branch
git checkout -b feature/storage-component
git checkout -b fix/networking-subnet-issue
git checkout -b docs/component-examplesBefore creating a PR, ensure quality:
# Run all linting and validation
npm run lint-devcontainer
# Run component-specific tests
./tests/components/{next-number}-{component-name}/test.sh
# Check conventional commit format
git log --oneline -5 # Verify recent commits follow format-
Using GitHub CLI:
# Create PR with conventional commit title gh pr create \ --title "feat(components): add storage component with dual implementation" \ --body "Adds new storage component with Terraform and Bicep implementations"
-
Using GitHub Copilot PR Prompt:
- Use
/pull-requestin Copilot Chat - Automatically generates PR title and description
- Follows conventional commit format
- Includes security and compliance analysis
- Use
Every PR must include:
- Clear description of changes and motivation
- Conventional commit format in PR title
- Documentation updates if adding new features
- Test coverage for new components
- Linting compliance (no failures)
- Security scan results (if applicable)
Note: These prompts are provided by the HVE Core extension, which is auto-installed in the Dev Container.
-
Task Planner (
/task-planner):- Creates structured plan files in
.copilot-tracking/plans/ - Breaks down complex features into phases
- Maintains notes files for tracking progress
- Creates structured plan files in
-
Task Implementer (
/task-implementer):- Implements tasks according to plan files
- Updates progress tracking
- Follows structured implementation approach
# Start a new feature development
# 1. Use /task-planner in Copilot Chat
# 2. Describe your feature requirements
# 3. Review generated plan file
# 4. Use /task-implementer to execute the plan- Formatting: Use
terraform fmtconsistently - Variables: Include descriptions and appropriate types
- Outputs: Document all outputs with descriptions
- Providers: Pin provider versions using
~>constraints - Documentation: Use Terraform-docs for automated documentation
- Parameters: Use appropriate decorators (@description, @allowed)
- Resources: Use latest stable API versions
- Modules: Prefer modules over individual resources
- Outputs: Clearly document output purposes
- Validation: Use parameter validation where appropriate
- README files: Every component needs comprehensive documentation
- Code comments: Explain complex logic and decisions
- Examples: Provide realistic usage examples
- Docsify compliance: Follow repository documentation standards
-
State conflicts:
# Refresh state terraform refresh # Import existing resources terraform import azurerm_resource_group.main /subscriptions/.../resourceGroups/name
-
Provider version conflicts:
# Upgrade providers terraform init -upgrade # Lock provider versions terraform providers lock
-
Template compilation errors:
# Build with verbose output az bicep build --file main.bicep --verbose # Lint for best practices az bicep lint --file main.bicep
-
Parameter validation:
# Test parameter files az deployment group validate \ --resource-group test \ --template-file main.bicep \ --parameters @parameters.json
-
Container rebuild:
# Rebuild container completely # Command Palette: "Remote-Containers: Rebuild Container"
-
Docker issues:
# Clean Docker system docker system prune -a # Restart Docker Desktop
- GitHub Copilot: Ask specific questions about errors and code
- Repository issues: Create issues with detailed error information
- Documentation: Check component README files and docs/
- Community: Engage with other contributors for guidance
Components use semantic versioning principles:
- Major: Breaking changes to interfaces
- Minor: New features, backward compatible
- Patch: Bug fixes, no interface changes
Design consistent interfaces across Terraform and Bicep:
- Input parameters: Use same names and types
- Output values: Provide equivalent outputs
- Resource naming: Follow consistent patterns
- Tagging: Support standard tagging strategies
- Least privilege: Grant minimal required permissions
- Managed identities: Use Azure managed identities where possible
- Secrets management: Never hard-code secrets
- Network security: Implement proper network isolation
- Compliance: Follow organizational security policies
After contributing your first component:
- Monitor usage: See how your component is used in blueprints
- Gather feedback: Listen to user experiences and suggestions
- Iterate and improve: Make enhancements based on real-world usage
- Mentor others: Help new contributors with similar tasks
- Expand expertise: Learn about other areas of the platform
- Blueprint Developer Guide - Create deployment scenarios
- Coding Conventions - Detailed coding standards
- AI-Assisted Engineering - Using GitHub Copilot effectively
- Terraform Documentation - Official Terraform guides
- Bicep Documentation - Official Bicep guides
- Azure IoT Operations Documentation - Platform documentation
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.