Documentation

• 1: Overview
• 1.1: Dev Box accelerator
• 1.2: Microsoft Dev Box
• 1.3: Roadmap
• 2: Getting Started
• 2.1: Prerequisites
• 2.1.1: Organization roles and responsabilities requirements
• 2.1.2: Framework and Tools requirements
• 2.2: Quick Start
• 3: Accelerator Configration
• 3.1: Resource Groups
• 3.2: Security
• 3.3: Network and Connectivity
• 3.4: Dev Center
• 4: Customization
• 4.1: Dev Box Image Definitions Samples
• 4.1.1: Back-End Engineering Development
• 4.1.2: Front-End Engineering Development
• 4.1.3:
• 4.1.4:
• 4.1.5:

1 - Overview

1.1 - Dev Box accelerator

Overview

The Dev Box accelerator is an open-source, reference implementation designed to help you quickly establish a landing zone subscription optimized for Microsoft Dev Box deployments. Built on the principles and best practices of the Azure Cloud Adoption Framework (CAF) enterprise-scale landing zones, it provides a strategic design path and a target technical state that:

• Establishes foundational services (network, monitoring, security, and workload) required for a secure, scalable, and multi-tenant Dev Box environment.
• Aligns to CAF guidance for subscription structure, resource groups, and role-based access control (RBAC).
• Is fully modular, parameterized, and ready to be adapted to your organization’s existing landing zone or to provision new platform services from scratch.
• Is open source—feel free to fork, extend, or customize the Bicep modules, policies, and scripts to meet your unique requirements.

Resources Visualization

What the Microsoft Dev Box accelerator Provides

The Microsoft Dev Box Accelerator delivers a comprehensive set of Bicep modules, automation scripts, and YAML configuration files with accompanying JSON schema definitions, designed to streamline the deployment of a production-ready Microsoft Dev Box landing zone. These artifacts empower infrastructure professionals with a configuration-as-code approach, enabling repeatable, scalable, and policy-compliant environments.

Key Components

• Networking: Virtual networks, subnets, network connections and optional hub connectivity.
• Identity & Access: Microsoft Entra integration, service principals, managed identities, and RBAC assignments.
• Security & Governance: Policy assignments (tagging, security baseline, resource consistency), Azure Monitor and Log Analytics integration.
• Platform Services: DevCenter, Projects, and supporting components.

Cloud Adoption Framework Alignment

All artifacts align with CAF’s enterprise-scale landing zone patterns:

• Management Group Hierarchy: Clear separation of concerns (Connectivity, Monitoring, Security, Workload).
• Modularity: Deploy only the foundational services you need.

Enterprise-Scale Design Principles

• Scalability: Supports hundreds of developers and multiple Dev Box SKUs.
• Security: Zero-trust networking, least-privilege access, continuous monitoring, and compliance.
• Cost Management: Tagging, budget alerts, and automated Dev Box lifecycle management.

Design Areas

When implementing a scalable Microsoft Dev Box landing zone, consider the following design areas:

1.2 - Microsoft Dev Box

What is Microsoft Dev Box?

Microsoft Dev Box gives developers self-service access to ready-to-code cloud workstations called dev boxes. You can configure dev boxes with tools, source code, and prebuilt binaries that are specific to a project, so developers can immediately start work. You can create cloud development environments for your developer teams by using a customized image, or a preconfigured image from Azure Marketplace, complete with Visual Studio already installed.

If you’re a developer, you can use multiple dev boxes in your day-to-day workflows. Access and manage your dev boxes through the developer portal.

Microsoft Dev Box bridges the gap between development teams and IT, by bringing control of project resources closer to the development team.

The Dev Box service was designed with three organizational roles in mind: platform engineers, development team leads, and developers.

Platform engineers and IT admins work together to provide developer infrastructure and tools to the developer teams. Platform engineers set and manage security settings, network configurations, and organizational policies to ensure that dev boxes can access resources securely.

Developer team leads are experienced developers who have in-depth knowledge of their projects. They can be assigned the DevCenter Project Admin role and assist with creating and managing the developer experience. Project admins create and manage pools of dev boxes.

Members of a development team are assigned the DevCenter Dev Box User role. They can then self-serve one or more dev boxes on demand from the dev box pools that are enabled for a project. Dev box users can work on multiple projects or tasks by creating multiple dev boxes.

Microsoft Dev Box bridges the gap between development teams and IT, by bringing control of project resources closer to the development team.

1.3 - Roadmap

2 - Getting Started

2.1 - Prerequisites

2.1.1 - Organization roles and responsabilities requirements

Overview

The Dev Box accelerator aligns with the requirements and responsibilities for each organizational role involved in deploying and using Microsoft Dev Box, with a focus on RBAC permissions and configuration prerequisites.

The roles covered include:

• Platform Engineers
• Development Team Leads
• Developers

Each role has distinct requirements to ensure a secure, scalable, and successful Dev Box deployment.

Platform Engineer Requirements

Platform Engineers are responsible for deploying and governing the core infrastructure that powers Microsoft Dev Box, including Dev Centers, network connections, and governance policies.

Responsibilities

• Create and configure Dev Centers and Projects
• Set up network connections (Microsoft-hosted or custom VNETs)
• Define Dev Box definitions (SKUs, base images)
• Apply RBAC roles and enforce policies
• Enable monitoring and diagnostics

Required Azure Roles

Additional Requirements

Development Team Lead Requirements

Development Team Leads manage the Dev Box experience for their teams by defining image configurations, Dev Box pools, and assigning users to environments.

Responsibilities

• Define Dev Box pools per team or project
• Customize and manage Dev Box definitions
• Assign users to Dev Box environments via Microsoft Entra ID groups
• Validate Dev Box readiness and configurations

Required Azure Roles

Additional Requirements

Developer Requirements

Developers are end users of Microsoft Dev Box and require access to preconfigured environments that match their team’s development stack.

Responsibilities

• Access and manage assigned Dev Boxes via the portal
• Use the Dev Box to develop, build, and test code
• Customize environment (if permitted) within constraints

Required Azure Roles

Summary

Before deploying or using the Dev Box accelerator, ensure each role has the following:

• Platform Engineers: Subscription access, network configuration, Dev Center ownership, and monitoring setup
• Team Leads: RBAC permissions, Dev Box definitions and pools, image strategy, and group assignments
• Developers: Assigned Entra ID group, portal access, and an understanding of the configured environment

For RBAC setup instructions, see:
Assign roles using Azure portal

2.1.2 - Framework and Tools requirements

Overview

This document provides a reference table for key Azure development tools, along with direct links to their official documentation and installation guides.

How to Install

Windows (via PowerShell and winget)

# Azure CLI
winget install --id Microsoft.AzureCLI

# Azure Developer CLI
winget install --id Microsoft.AzureDeveloperCLI

# Bicep CLI (requires Azure CLI)
az bicep install

# Visual Studio Code
winget install --id Microsoft.VisualStudioCode

Ubuntu (via Bash)

# Azure CLI
curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash

# Azure Developer CLI
curl -fsSL https://aka.ms/install-azd.sh | bash

# Bicep CLI (requires Azure CLI)
az bicep install

# Visual Studio Code
sudo apt update
sudo apt install wget gpg -y
wget -qO- https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > packages.microsoft.gpg
sudo install -o root -g root -m 644 packages.microsoft.gpg /etc/apt/keyrings/
sudo sh -c 'echo "deb [arch=amd64 signed-by=/etc/apt/keyrings/packages.microsoft.gpg] https://packages.microsoft.com/repos/code stable main" > /etc/apt/sources.list.d/vscode.list'
sudo apt update
sudo apt install code -y

2.2 - Quick Start

This guide will help you quickly deploy the Dev Box accelerator in your Azure environment for evaluation and testing purposes.

Installation

Step 1: Fork the Required GitHub Repositories

Begin by forking the necessary GitHub repositories to your account.

# Dev Box accelerator repository
gh repo fork Evilazaro/DevExp-DevBox --clone --remote

# Identity Provider solution demo repository
gh repo fork Evilazaro/IdentityProvider --clone --remote

# eShop solution demo repository
gh repo fork Evilazaro/eShop --clone --remote

Step 2: Initialize Your Local Environment

Navigate to your cloned Dev Box repository directory and initialize the environment:

Windows (PowerShell)

# Change to recommended region for your location
$location = "eastus2"
$envName = "prod"

# Verify GitHub authentication
if (-not (gh auth status 2>&1 | Select-String "Logged in")) {
    Write-Host "Please login to GitHub first with 'gh auth login'" -ForegroundColor Red
    exit 1
}

# Create Azure Developer CLI environment
azd env new $envName --no-prompt

# Configure environment settings
Set-Content -Path ".\.azure\$envName\.env" -Value "AZURE_ENV_NAME='$envName'"

# Securely retrieve GitHub token
$pat = gh auth token
Add-Content -Path ".\.azure\$envName\.env" -Value "KEY_VAULT_SECRET='$pat'"
Add-Content -Path ".\.azure\$envName\.env" -Value "AZURE_LOCATION='$location'"

# Show current configuration (validates setup)
azd config show

Linux/macOS (Bash)

# Change to recommended region for your location
location="eastus2"
envName="prod"

# Verify GitHub authentication
if ! gh auth status &>/dev/null; then
    echo "Please login to GitHub first with 'gh auth login'"
    exit 1
fi

# Create Azure Developer CLI environment
azd env new "$envName" --no-prompt

# Configure environment settings
mkdir -p .azure/"$envName"
echo "AZURE_ENV_NAME='$envName'" > .azure/"$envName"/.env
pat=$(gh auth token)
echo "KEY_VAULT_SECRET='$pat'" >> .azure/"$envName"/.env
echo "AZURE_LOCATION='$location'" >> .azure/"$envName"/.env

# Show current configuration (validates setup)
azd config show

Step 3: Deploy the Accelerator

Once your environment is configured, deploy the accelerator:

# Deploy the accelerator
azd provision -e $envName

3 - Accelerator Configration

3.1 - Resource Groups

Overview

This YAML configuration file azureResources.yaml defines the organizational structure for Azure resource groups as part of the Microsoft Dev Box Accelerator. It follows Azure Landing Zone best practices, enabling modular, decoupled, and scalable management of cloud resources. By segmenting resources into functional groups—workload, security, monitoring, and connectivity—the configuration supports clear governance, access control, and lifecycle management for enterprise-scale Dev Box deployments.

Role in Dev Box Accelerator:
This file is a foundational component, ensuring that all resources deployed for Microsoft Dev Box environments are organized, tagged, and governed according to enterprise standards. It enables teams to manage infrastructure and workloads independently, supporting both operational efficiency and compliance.

Table of Contents

• Overview
• Configurations
  • Workload Resource Group
  • Security Resource Group
  • Monitoring Resource Group
  • Connectivity Resource Group
• Examples and Use Cases
• Best Practices
• References

Configurations

Each top-level section in the YAML file represents a distinct Azure resource group category. Below is a breakdown of each section, its keys, and their purposes.

Workload Resource Group

Purpose:
Holds primary Dev Box workload resources (Dev Center, Dev Box definitions, pools, and project resources).

YAML Representation:

workload:
  create: true
  name: devexp-workload
  description: prodExp
  tags:
    environment: dev
    division: Platforms
    team: DevExP
    project: Contoso-DevExp-DevBox
    costCenter: IT
    owner: Contoso
    landingZone: Workload
    resources: ResourceGroup

Key Explanations:

• create: Whether to create this resource group (true/false).
• name: Resource group name, following a consistent naming convention.
• description: Brief summary of the group’s purpose.
• tags: Metadata for governance, cost allocation, and management.

Security Resource Group

Purpose:
Isolates security-related resources (Key Vaults, Defender for Cloud, NSGs, private endpoints).

YAML Representation:

security:
  create: true
  name: devexp-security
  description: prodExp
  tags:
    environment: dev
    division: Platforms
    team: DevExP
    project: Contoso-DevExp-DevBox
    costCenter: IT
    owner: Contoso
    landingZone: Workload
    resources: ResourceGroup

Key Explanations:
Same structure as workload, but dedicated to security assets for stricter access and monitoring.

Monitoring Resource Group

Purpose:
Centralizes monitoring and observability resources (Log Analytics, Application Insights, Azure Monitor).

YAML Representation:

monitoring:
  create: true
  name: devexp-monitoring
  description: prodExp
  tags:
    environment: dev
    division: Platforms
    team: DevExP
    project: Contoso-DevExp-DevBox
    costCenter: IT
    owner: Contoso
    landingZone: Workload
    resources: ResourceGroup

Key Explanations:
Enables unified operational health monitoring and diagnostics.

Connectivity Resource Group

Purpose:
Contains networking and connectivity resources (VNets, NSGs, peerings, DNS zones, Azure Bastion).

YAML Representation:

connectivity:
  create: true
  name: devexp-connectivity
  description: prodExp
  tags:
    environment: dev
    division: Platforms
    team: DevExP
    project: Contoso-DevExp-DevBox
    costCenter: IT
    owner: Contoso
    landingZone: Workload
    resources: ResourceGroup

Key Explanations:
Segregates network infrastructure for specialized management and security.

Examples and Use Cases

Example: Deploying Dev Box Resources

Suppose you want to deploy a new Dev Box environment for the “Contoso-DevExp-DevBox” project in a development environment:

• Workload group will host Dev Box definitions and pools.
• Security group will contain Key Vaults for secrets used by Dev Box VMs.
• Monitoring group will centralize logs and metrics for all Dev Box resources.
• Connectivity group will manage VNets and NSGs for secure access.

Sample Usage in a Deployment Pipeline:

# Pseudocode for pipeline step
- task: AzureResourceManagerTemplateDeployment
  inputs:
    resourceGroupName: $(workload.name)
    templateLocation: 'Linked artifact'
    csmFile: 'devboxTemplate.json'
    deploymentMode: 'Incremental'

This ensures resources are deployed into the correct, pre-defined groups.

Best Practices

• Consistent Naming:
  Use a standard naming convention for resource groups (e.g., [project]-[purpose]-[environment]-rg) to simplify management and automation.

• Tagging:
  Apply consistent tags across all resource groups for effective cost tracking, ownership, and compliance.

• Separation of Concerns:
  Segregate resources by function (workload, security, monitoring, connectivity) to enable independent scaling, access control, and lifecycle management.

• Adapt for Environments:
  Duplicate or adjust sections for different environments (dev, test, prod) by changing the environment tag and resource group names.

• Documentation:
  Keep descriptions up to date to reflect the actual purpose of each group, aiding onboarding and audits.

• Automation:
  Integrate this YAML into your Infrastructure as Code (IaC) pipelines to automate resource group creation and tagging.

References:

• Azure Landing Zones
• Azure Resource Groups

3.2 - Security

Overview

This document provides a comprehensive analysis of the security.yaml configuration file, a core component of the Microsoft Dev Box Accelerator. The Microsoft Dev Box Accelerator enables rapid, modular, and secure provisioning of development environments in Azure. The security.yaml file specifically governs the setup and management of an Azure Key Vault resource, which is critical for securely storing sensitive credentials and secrets required by development teams. By decoupling security configuration, the Accelerator ensures best practices, compliance, and flexibility across environments.

Table of Contents

• Overview
• Configurations
  • Resource Creation
  • Key Vault Configuration
  • Security Settings
  • Resource Organization (Tags)
• Examples and Use Cases
  • Example 1: Provisioning a Key Vault for a New Dev Environment
  • Example 2: Reusing an Existing Key Vault
• Best Practices

Configurations

Below is a detailed breakdown of each section and key in the security.yaml file, including their YAML representation and purpose.

Resource Creation

create: true

• Purpose: Indicates whether the Azure Key Vault resource should be created as part of the deployment.
• Type: Boolean (true or false)
• Typical Use: Set to true for initial deployments; set to false if the Key Vault already exists and should not be recreated.

Key Vault Configuration

keyVault:
  name: contoso
  description: Development Environment Key Vault
  secretName: gha-token

• name: Globally unique name for the Key Vault.
• description: Human-readable description of the Key Vault’s purpose.
• secretName: Name of the secret (e.g., a GitHub Actions token) to be stored in the Key Vault.

Security Settings

  enablePurgeProtection: true
  enableSoftDelete: true
  softDeleteRetentionInDays: 7
  enableRbacAuthorization: true

• enablePurgeProtection: Prevents permanent deletion of secrets, even by authorized users. Enhances data protection.
• enableSoftDelete: Allows recovery of deleted secrets within a retention period.
• softDeleteRetentionInDays: Number of days (7–90) that deleted secrets remain recoverable.
• enableRbacAuthorization: Uses Azure Role-Based Access Control (RBAC) for access management instead of legacy access policies.

Resource Organization (Tags)

  tags:
    environment: dev
    division: Platforms
    team: DevExP
    project: Contoso-DevExp-DevBox
    costCenter: IT
    owner: Contoso
    landingZone: security
    resources: ResourceGroup

• Purpose: Tags provide metadata for resource organization, cost management, and governance.
• Common Tags:
  • environment: Deployment environment (e.g., dev, test, prod)
  • division, team, project: Organizational context
  • costCenter: For billing and chargeback
  • owner: Resource owner
  • landingZone: Azure landing zone classification
  • resources: Resource grouping identifier

Examples and Use Cases

Example 1: Provisioning a Key Vault for a New Dev Environment

A new development team needs a secure place to store secrets for CI/CD pipelines. By setting create: true and specifying the secretName, the Accelerator will provision a Key Vault and store the required GitHub Actions token.

create: true
keyVault:
  name: devbox-kv-001
  description: Dev Box Key Vault for Team Alpha
  secretName: gha-token
  enablePurgeProtection: true
  enableSoftDelete: true
  softDeleteRetentionInDays: 14
  enableRbacAuthorization: true
  tags:
    environment: dev
    team: Alpha
    project: DevBox
    costCenter: IT
    owner: TeamAlphaLead
    landingZone: security
    resources: ResourceGroup

Example 2: Reusing an Existing Key Vault

If the Key Vault already exists, set create: false to avoid redeployment:

create: false
keyVault:
  name: existing-kv
  # ...other settings...

Best Practices

• Unique Naming: Ensure the name is globally unique within Azure to avoid deployment failures.
• Retention Period: Adjust softDeleteRetentionInDays based on your organization’s compliance and recovery requirements.
• RBAC vs. Access Policies: Prefer enableRbacAuthorization: true for modern, scalable access control.
• Tagging: Use descriptive and consistent tags to simplify resource management, cost tracking, and automation.
• Security: Always enable enablePurgeProtection and enableSoftDelete for production environments to prevent accidental or malicious loss of secrets.
• Schema Validation: Use the provided $schema directive for IDE validation and to prevent misconfiguration.

3.3 - Network and Connectivity

Overview

This document provides a comprehensive analysis of the newtork.yaml configuration file, a core component of the Microsoft Dev Box Accelerator. This YAML file defines the virtual network (VNet) infrastructure for Dev Box environments, enabling secure, isolated, and scalable connectivity for development resources in Azure. The modular and decoupled design of this configuration allows organizations to tailor network settings to their specific needs, ensuring best practices for security, governance, and operational efficiency.

Table of Contents

• Overview
• Configurations
  • Create Flag
  • Virtual Network Type
  • Virtual Network Name
  • Address Prefixes
  • Subnets
  • Tags
• Examples and Use Cases
  • Example 1: Isolated Dev Environment
  • Example 2: Hybrid Production Scenario
• Best Practices

Configurations

Below, each section and key of the YAML file is explained in detail, with the corresponding YAML representation.

Create Flag

create: true

• Purpose: Determines whether to create a new VNet (true) or use an existing one (false).
• Best Practice: Use true to ensure a dedicated, isolated network for each environment.

Virtual Network Type

virtualNetworkType: Managed

• Options:
  • Managed: Azure manages the network configuration (recommended for dev/test).
  • Unmanaged: Customer manages the network (required for hybrid or production scenarios).
• Best Practice: Use Managed for simplicity and security in dev/test; use Unmanaged for advanced scenarios.

Virtual Network Name

name: contoso-vnet

• Purpose: Unique identifier for the VNet resource.
• Naming Convention: [company]-[purpose]-[env]-vnet (e.g., contoso-dev-dev-vnet).

Address Prefixes

addressPrefixes:
  - 10.0.0.0/16

• Purpose: Defines the IP address range for the VNet using CIDR notation.
• Best Practices:
  • Use private ranges (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
  • Avoid overlaps with on-premises or other Azure VNets.
  • Allocate enough space for current and future needs.

Subnets

subnets:
  - name: contoso-subnet
    properties:
      addressPrefix: 10.0.1.0/24

• Purpose: Defines network segments within the VNet.
• Best Practices:
  • Create separate subnets for different workloads or security zones.
  • Apply Network Security Groups (NSGs) at the subnet level.
  • Size subnets appropriately (e.g., /24 provides 251 usable IPs).

Tags

tags:
  environment: dev
  division: Platforms
  team: DevExP
  project: DevExP-DevBox
  costCenter: IT
  owner: Contoso
  resources: Network

• Purpose: Metadata for resource organization, governance, and cost management.
• Common Tags:
  • environment: Deployment environment (dev, test, staging, prod).
  • division: Organizational division responsible.
  • team: Team responsible for the resource.
  • project: Associated project.
  • costCenter: For charge-back/accounting.
  • owner: Individual or team owner.
  • resources: Resource type or purpose.
• Best Practices:
  • Apply consistent tags across all resources.
  • Automate tagging where possible.

Examples and Use Cases

Example 1: Isolated Dev Environment

A development team needs a secure, isolated network for testing new features. They set create: true and use a dedicated address space and subnet:

create: true
virtualNetworkType: Managed
name: contoso-dev-dev-vnet
addressPrefixes:
  - 10.1.0.0/16
subnets:
  - name: dev-subnet
    properties:
      addressPrefix: 10.1.1.0/24
tags:
  environment: dev
  team: DevTeamA
  project: FeatureX
  costCenter: RnD
  owner: Alice
  resources: Network

Example 2: Hybrid Production Scenario

For production, the organization uses virtualNetworkType: Unmanaged to connect with on-premises resources and applies stricter subnetting and tagging.

Best Practices

• Avoid IP Overlaps: Always check that your address space does not overlap with existing Azure or on-premises networks.
• Subnet Sizing: Plan for future growth; resizing subnets later can be complex.
• Tag Consistently: Use automation to enforce tagging policies for governance and cost tracking.
• Security: Apply NSGs and consider Azure Firewall for enhanced security.
• Documentation: Keep your YAML files under version control and document changes for auditing and troubleshooting.
• Reference Azure Best Practices: Regularly review Azure VNet best practices for updates.

3.4 - Dev Center

Overview

The devcenter.yaml file is the central configuration for the Microsoft Dev Box Accelerator. It defines the structure, governance, and operational parameters for a Dev Center resource in Azure, enabling organizations to provide secure, scalable, and role-specific developer workstations (Dev Boxes). This YAML file orchestrates Dev Box pools, access controls, environment types, project boundaries, and integration with version-controlled catalogs, ensuring a modular and decoupled approach to developer environment management.

Key Roles of this YAML:

• Centralizes Dev Center resource setup and policy.
• Defines projects, environments, and access controls.
• Integrates with Git-based catalogs for configuration-as-code.
• Enables automated, role-specific Dev Box provisioning.

Configurations

Below is a breakdown of each major section, its YAML representation, and an explanation of its purpose.

Dev Center Metadata

name: "contoso-devcenter"
location: "eastus2"

• name: Globally unique identifier for the Dev Center resource.
• location: Azure region for deployment; select a region close to your team for performance.

Global Settings

catalogItemSyncEnableStatus: "Enabled"
microsoftHostedNetworkEnableStatus: "Enabled"
installAzureMonitorAgentEnableStatus: "Enabled"

• catalogItemSyncEnableStatus: Enables automatic sync of catalog items from source repositories.
• microsoftHostedNetworkEnableStatus: Uses Microsoft-managed networking for Dev Boxes (simplifies setup).
• installAzureMonitorAgentEnableStatus: Installs Azure Monitor agent for monitoring and compliance.

Identity and Access Control

identity:
  type: "SystemAssigned"
  
  roleAssignments:
    devCenter:
      - id: "b24988ac-6180-42a0-ab88-20f7382dd24c"
        name: "Contributor"
      - id: "18d7d88d-d35e-4fb5-a5c3-7773c20a72d9"
        name: "User Access Administrator"
    
    orgRoleTypes:
      - type: DevManager
        azureADGroupId: "8dae87fa-87b2-460b-b972-a4239fbd4a96"
        azureADGroupName: "Dev Manager"
        azureRBACRoles:
          - name: "DevCenter Project Admin"
            id: "331c37c6-af14-46d9-b9f4-e1909e1b95a0"

• type: Managed identity type (SystemAssigned recommended for simplicity).
• roleAssignments: Assigns Azure RBAC roles to the Dev Center and organizational groups for secure operations.

Catalogs

catalogs:
  - name: "customTasks"
    type: "gitHub"
    uri: "https://github.com/Evilazaro/DevExP-DevBox.git"
    branch: "main"
    path: ".configuration/devcenter/tasks"

• catalogs: List of Git-based repositories containing configuration scripts and templates for Dev Box customization.

Environment Types

environmentTypes:
  - name: "dev"
    deploymentTargetId: ""
  - name: "staging"
    deploymentTargetId: ""

• environmentTypes: Defines deployment environments (e.g., dev, staging) for SDLC alignment.

Projects

Each project is a distinct logical unit with its own pools, catalogs, and access controls.

Example Project Structure

projects:
  - name: "identityProvider"
    description: "Identity Provider project."
    
    identity:
      type: SystemAssigned
      roleAssignments:
        - azureADGroupId: "331f48d7-4a23-4ec4-b03a-4af29c9c6f34"
          azureADGroupName: "identityProvider Developers"
          azureRBACRoles:
            - name: "Contributor"
              id: "b24988ac-6180-42a0-ab88-20f7382dd24c"
            - name: "Dev Box User"
              id: "45d50f46-0b78-4001-a660-4198cbe8cd05"
            - name: "Deployment Environment User"
              id: "18e40d4e-8d2e-438d-97e1-9528336e149c"
    
    pools:
      - name: "backend-engineer"
        imageDefinitionName: "identityProvider-backend-engineer"
      - name: "frontend-engineer"
        imageDefinitionName: "identityProvider-frontend-engineer"
    
    environmentTypes:
      - name: "dev"
        deploymentTargetId: ""
      - name: "staging"
        deploymentTargetId: ""
    
    catalogs:
      environmentDefinition:
        name: "environments"
        type: "gitHub"
        uri: "https://github.com/Evilazaro/identityProvider.git"
        branch: "main"
        path: ".configuration/devcenter/environments"
      
      imageDefinition:
        name: "imageDefinitions"
        type: "gitHub"
        uri: "https://github.com/Evilazaro/identityProvider.git"
        branch: "main"
        path: ".configuration/devcenter/imageDefinitions"
    
    tags:
      environment: "dev"
      division: "Platforms"
      team: "DevExP"
      project: "DevExP-DevBox"
      costCenter: "IT"
      owner: "Contoso"
      resources: "Project"

Key Elements:

• identity: Project-level identity and RBAC assignments.
• pools: Role-specific Dev Box pools (e.g., backend, frontend).
• environmentTypes: Environments available to the project.
• catalogs: Project-specific catalogs for IaC and image definitions.
• tags: Resource tags for governance and cost tracking.

Top-Level Tags

tags:
  environment: "dev"
  division: "Platforms"
  team: "DevExP"
  project: "DevExP-DevBox"
  costCenter: "IT"
  owner: "Contoso"
  resources: "DevCenter"

• tags: Applied to the Dev Center resource for consistent governance, cost allocation, and ownership tracking.

Examples and Use Cases

Example 1: Adding a New Project

To onboard a new team, add a new entry under projects with its own identity, pools, catalogs, and tags.
Use Case: Isolates access and configurations for different business units or applications.

Example 2: Customizing Dev Box Pools

Define pools for different engineering roles (e.g., backend, frontend) with tailored image definitions.
Use Case: Ensures developers get the right tools and environments for their responsibilities.

Example 3: Integrating with GitHub Catalogs

Point catalogs to your organization’s GitHub repositories for configuration-as-code.
Use Case: Enables version-controlled, automated updates to Dev Box configurations and environments.

Best Practices

• Use Azure AD Groups: Assign permissions via groups, not individuals, for easier management.
• Leverage Tags: Apply consistent tags for cost tracking, ownership, and resource organization.
• Keep Catalogs Modular: Separate environment and image definitions for flexibility and reuse.
• Automate Sync: Enable catalog sync for up-to-date Dev Box provisioning.
• Align Environments with SDLC: Define dev, staging, and prod environments to match your release process.
• Review RBAC Assignments: Grant only necessary permissions to minimize risk.
• Document Custom Pools: Clearly describe the purpose and configuration of each Dev Box pool for maintainability.

References:

• Microsoft Dev Box Documentation
• Azure RBAC Roles

4 - Customization

4.1 - Dev Box Image Definitions Samples

4.1.1 - Back-End Engineering Development

Overview

This YAML file defines the base image configuration for backend engineers working on the Identity Provider Project Demo at Contoso, using the Microsoft Dev Box Accelerator. It specifies the tools, environment setup, and project-specific tasks required to provision a consistent, ready-to-code development environment in Azure Dev Box. The configuration ensures that all backend engineers have a standardized, secure, and productive workspace aligned with Contoso’s engineering requirements.

Configurations

Below is a breakdown of each section and key in the YAML file, with explanations and YAML snippets.

Metadata

$schema: "1.0"
name: identityProvider-backend-engineer
description: "This image definition sets up a development environment for backend engineers."
image: microsoftvisualstudio_visualstudioplustools_vs-2022-ent-general-win11-m365-gen2

• $schema: Version of the image definition schema.
• name: Unique identifier for this image definition.
• description: Human-readable summary of the image’s purpose.
• image: The Microsoft-provided base image (includes Visual Studio 2022, Windows 11, and M365).

Tasks

Defines the mandatory steps to set up the environment.

Core Environment Setup

- name: ~/powershell
  description: "Configure PowerShell environment and install DSC resources"
  parameters:
    command: |
      Set-ExecutionPolicy -ExecutionPolicy Bypass -Force -Scope Process
      Install-PackageProvider -Name NuGet -Force -Scope AllUsers
      Set-PSRepository -Name "PSGallery" -InstallationPolicy Trusted
      Install-Module -Name PSDSCResources -Force -AllowClobber -Scope AllUsers      

• Installs PowerShell DSC resources for consistent environment configuration.

Common Development Tools

- name: ~/winget
  description: "Import common engineering tools and configurations"
  parameters:
    downloadUrl: "https://raw.githubusercontent.com/Evilazaro/DevExp-DevBox/refs/heads/main/.configuration/devcenter/workloads/common-config.dsc.yaml"
    configurationFile: "c:\\winget\\common-config.dsc.yaml"

• Imports a shared configuration file for common tools.

- name: ~/winget
  description: "Install GitHub Desktop for visual Git management"
  parameters:
    package: "GitHub.GitHubDesktop"

• Installs GitHub Desktop for source control.

- name: ~/git-clone
  description: "Clone the Identity Provider repository to the local workspace"
  parameters:
    repositoryUrl: https://github.com/Evilazaro/IdentityProvider.git
    directory: Z:\Workspaces

• Clones the project repository into the workspace.

Backend Development Environment

- name: ~/winget
  description: "Install specialized backend development tools"
  parameters:
    downloadUrl: "https://raw.githubusercontent.com/Evilazaro/DevExp-DevBox/refs/heads/main/.configuration/devcenter/workloads/common-backend-config.dsc.yaml"
    configurationFile: "c:\\winget\\common-backend-config.dsc.yaml"

• Installs backend-specific tools (e.g., database, API, server utilities).

User Tasks

Defines optional tasks that individual engineers can run as needed.

userTasks:
  - name: ~/winget
    description: "Install additional backend-specific tools"
    parameters:
      downloadUrl: "https://raw.githubusercontent.com/Evilazaro/DevExp-DevBox/refs/heads/main/.configuration/devcenter/workloads/common-backend-usertasks-config.dsc.yaml"
      configurationFile: "c:\\winget\\common-backend-usertasks-config.dsc.yaml"

• Optional backend tools for specialized scenarios.

Environment Maintenance

- name: ~/powershell
  description: "Update Winget Packages"
  parameters:
    command: |
      # Updates all packages, .NET workloads, restores NuGet, builds, and tests the solution      

• Keeps all installed tools and packages up to date.
• Ensures the .NET solution is restored, built, and tested.

Project Setup

- name: ~/powershell
  description: "Build Identity Provider Solution"
  parameters:
    command: |
      # Restores, builds, and tests the solution to validate the environment      

• Validates that the environment is ready for development by building and testing the main project.

Examples and Use Cases

Example: Provisioning a Dev Box for a New Engineer

1. Dev Box Service reads this YAML file.
2. Base image is provisioned with Visual Studio, Windows 11, and M365.
3. Tasks run automatically:
   • PowerShell DSC resources are installed.
   • Common and backend tools are set up via WinGet.
   • GitHub Desktop is installed.
   • The Identity Provider repository is cloned to Z:\Workspaces.
   • All packages are updated, and the solution is built and tested.
4. User Tasks: The engineer can optionally install additional backend tools as needed.

Use Case: Ensuring Consistency Across Teams

• All backend engineers receive the same environment, reducing “works on my machine” issues.
• Updates and new tools can be rolled out by updating the YAML or referenced configuration files.

Best Practices

• Use Microsoft Base Images: Ensures compatibility and support.
• Leverage DSC and WinGet: For idempotent, repeatable environment setup.
• Centralize Tool Configurations: Reference shared configuration files for consistency.
• Separate Mandatory and Optional Tasks: Keep the base image lean and allow customization.
• Automate Updates and Validation: Regularly update packages and validate the build/test pipeline as part of environment setup.
• Use Trusted Sources: Only install packages from trusted repositories and URLs.
• Document Each Section: Use comments in the YAML to explain the purpose of each task.
• Follow Azure Dev Box Best Practices: Such as using the Z: drive for workspaces and scoped execution policies for security.

References:

• Microsoft Dev Box Documentation
• Azure Dev Box Best Practices
• WinGet Documentation

4.1.2 - Front-End Engineering Development

Overview

This YAML configuration file defines the development environment image for frontend engineers working on the Identity Provider Project Demo at Contoso, leveraging the Microsoft Dev Box Accelerator. The file specifies the base image, core tools, environment setup tasks, and optional user tasks to ensure a consistent, secure, and productive workspace for frontend development. It is designed to automate environment provisioning, reduce onboarding friction, and enforce organizational best practices.

Configurations

Below is a breakdown of each section and key in the YAML file, with explanations and YAML snippets for clarity.

Metadata & Schema

$schema: "1.0"
name: identityProvider-frontend-engineer
description: "This image definition sets up a development environment for frontend engineers."
image: microsoftvisualstudio_windowsplustools_base-win11-gen2

• $schema: Specifies the schema version for validation.
• name: Unique identifier for the image definition.
• description: Human-readable summary of the environment’s purpose.
• image: The Microsoft-provided base image (Windows 11 + dev tools), ensuring compatibility and performance.

Tasks

Defines the installation and configuration steps for the environment. Each task is an object with a name, description, and parameters.

Core Environment Setup

- name: ~/powershell
  description: "Configure PowerShell environment and install DSC resources"
  parameters:
    command: |
      Set-ExecutionPolicy -ExecutionPolicy Bypass -Force -Scope Process
      Install-PackageProvider -Name NuGet -Force -Scope AllUsers
      Set-PSRepository -Name "PSGallery" -InstallationPolicy Trusted
      Install-Module -Name PSDSCResources -Force -AllowClobber -Scope AllUsers      

• Purpose: Ensures PowerShell is ready for automation and installs DSC resources for idempotent configuration.

Common Development Tools

- name: ~/winget
  description: "Import common engineering tools and configurations"
  parameters:
    downloadUrl: "https://raw.githubusercontent.com/Evilazaro/DevExp-DevBox/refs/heads/main/.configuration/devcenter/workloads/common-config.dsc.yaml"
    configurationFile: "c:\\winget\\common-config.dsc.yaml"

• Purpose: Imports a shared configuration for tools used across engineering teams.

- name: ~/winget
  description: "Install GitHub Desktop for visual Git management"
  parameters:
    package: "GitHub.GitHubDesktop"

• Purpose: Installs GitHub Desktop for GUI-based Git operations.

- name: ~/winget
  description: "Install Visual Studio Code for web development"
  parameters:
    package: "Microsoft.VisualStudioCode"

• Purpose: Installs VS Code, the primary IDE for frontend development.

- name: ~/git-clone
  description: "Clone the Identity Provider repository to the local workspace"
  parameters:
    repositoryUrl: https://github.com/Evilazaro/IdentityProvider.git
    directory: Z:\Workspaces

• Purpose: Pre-clones the project repository for immediate access.

User-Specific Tasks (userTasks)

Tasks that can be customized or run by individual developers.

Optional Frontend Tools

- name: ~/winget
  description: "Install additional frontend-specific tools"
  parameters:
    downloadUrl: "https://raw.githubusercontent.com/Evilazaro/DevExp-DevBox/refs/heads/main/.configuration/devcenter/workloads/common-frontend-usertasks-config.dsc.yaml"
    configurationFile: "c:\\winget\\common-frontend-usertasks-config.dsc.yaml"

• Purpose: Allows engineers to install specialized frontend tools as needed.

Environment Maintenance

- name: ~/powershell
  description: "Update Winget Packages"
  parameters:
    command: |
      # Updates all packages, Node.js, npm, and frontend CLIs; restores .NET dependencies      

• Purpose: Keeps all tools and dependencies up to date, ensuring security and compatibility.

Project Setup

- name: ~/powershell
  description: "Build Identity Provider Frontend Components"
  parameters:
    command: |
      # Installs dependencies, builds the frontend, and runs unit tests      

• Purpose: Validates that the environment is ready for development by building and testing the frontend.

3. Examples and Use Cases

Example: New Engineer Onboarding

Scenario: A new frontend engineer joins the Identity Provider project.

• Action: The engineer provisions a Dev Box using this image definition.
• Result: The Dev Box is automatically configured with all required tools (VS Code, GitHub Desktop), project code is cloned, and the environment is validated by building and testing the frontend—all with minimal manual setup.

Example: Keeping Environments Consistent

Scenario: The engineering team wants to ensure all members use the same versions of tools and dependencies.

• Action: Updates are made to the shared configuration files referenced in the YAML.
• Result: All new Dev Boxes and environment refreshes use the updated configurations, reducing “works on my machine” issues.

Best Practices

• Use Microsoft Base Images: Always start from official Microsoft images for security, support, and compatibility.
• Automate Environment Setup: Use PowerShell DSC and WinGet to automate tool installation and configuration, ensuring repeatability.
• Centralize Common Configurations: Reference shared configuration files for tools to maintain consistency across teams.
• Separate Mandatory and Optional Tasks: Use userTasks for tools that are not required by everyone, keeping the base image lean.
• Keep Everything Updated: Include maintenance scripts to regularly update packages and dependencies.
• Validate Setup: Automate build and test steps to ensure the environment is ready for development immediately after provisioning.
• Follow Security Best Practices: Use scoped execution policy changes and trusted repositories to minimize security risks.
• Document Each Step: Comment each section and task for clarity and maintainability.

References

• Microsoft Dev Box Documentation
• Azure Dev Box Best Practices
• PowerShell DSC Resources
• WinGet Documentation

4.1.3 -

4.1.4 -

Overview

This document provides comprehensive documentation for the PowerShell Desired State Configuration (DSC) YAML file: common-config.dsc.yaml. This configuration is designed to automate the setup of a standardized development environment for .NET engineers, with a strong focus on Azure development workflows. It provisions essential tools, runtimes, and storage optimizations to ensure a productive and performant developer experience on Windows 10/11.

Table of Contents

• Storage Configuration
  • Dev Drive
• Source Control Tools
  • Git
  • GitHub CLI
• Development Runtimes
  • .NET SDK 9
  • .NET Runtime 9
  • Node.js
• Development Tools
  • Visual Studio Code
• Best Practices

Storage Configuration

Dev Drive

YAML Configuration:

- resource: Disk
  id: DevDrive1
  directives:
    module: StorageDsc
    allowPrerelease: true
    description: Configure Dev Drive with ReFS format
  settings:
    DiskId: "0" # First available disk (verify this matches your environment)
    DiskIdType: "Number"
    DriveLetter: "Z" # Standard letter for development drives
    FSLabel: "Dev Drive 1"
    DevDrive: true # Enables Windows Dev Drive optimizations
    AllowDestructive: true # Warning: Will format existing disk if present
    FSFormat: "ReFS" # Required for Dev Drive functionality
    Size: "50Gb" # Recommended minimum size for development workloads

Explanation:
Configures a Windows Dev Drive using the ReFS file system, optimized for development workloads. Dev Drive provides improved performance for source control operations, build processes, and large solution files—especially beneficial for Azure microservice architectures. The configuration ensures the drive is formatted and mounted as Z:, with Dev Drive optimizations enabled.

Official Documentation:

• Windows Dev Drive
• Optimize Dev Drive for Azure Dev Box

Source Control Tools

Git

YAML Configuration:

- resource: Microsoft.WinGet.DSC/WinGetPackage
  id: Git.Git
  directives:
    allowPrerelease: true
    description: Install Git version control system
  settings:
    id: Git.Git

Explanation:
Installs Git, the essential distributed version control system for source code management. Git is foundational for Azure DevOps, GitHub integration, and infrastructure-as-code workflows. It is also required for Azure Bicep, GitOps, and optimized for performance when used with Dev Drive.

Official Documentation:

• Git Documentation
• WinGet Git Package

GitHub CLI

YAML Configuration:

- resource: Microsoft.WinGet.DSC/WinGetPackage
  id: GitHub.cli
  directives:
    allowPrerelease: true
    description: Install GitHub command-line interface
  settings:
    id: GitHub.cli
  dependsOn:
    - Git.Git # Requires Git for full functionality

Explanation:
Installs the GitHub CLI (gh), enabling command-line management of GitHub repositories, issues, pull requests, and GitHub Actions. This tool streamlines Azure DevOps integration and automates workflows for Azure deployments. It depends on Git for core functionality.

Official Documentation:

• GitHub CLI Documentation
• WinGet GitHub CLI Package

Development Runtimes

.NET SDK 9

YAML Configuration:

- resource: Microsoft.WinGet.DSC/WinGetPackage
  id: Microsoft.DotNet.SDK.9
  directives:
    allowPrerelease: true
    description: Install .NET 9 SDK for application development
  settings:
    id: Microsoft.DotNet.SDK.9

Explanation:
Installs the .NET 9 SDK, which is central to Azure development. It provides tools for building, testing, and deploying applications targeting Azure services, including Azure Functions, Web Apps, and containerized workloads. The SDK includes Azure-specific templates and middleware.

Official Documentation:

• .NET SDK Documentation
• WinGet .NET SDK Package

.NET Runtime 9

YAML Configuration:

- resource: Microsoft.WinGet.DSC/WinGetPackage
  id: Microsoft.DotNet.Runtime.9
  directives:
    allowPrerelease: true
    description: Install .NET 9 Runtime
  settings:
    id: Microsoft.DotNet.Runtime.9
  dependsOn:
    - Microsoft.DotNet.SDK.9 # Runtime is included in SDK, but explicit dependency ensures correct order

Explanation:
Installs the .NET 9 Runtime, required for running .NET applications and Azure tooling. This ensures compatibility with Azure PowerShell, Azure Functions Core Tools, and local emulators. Explicit installation guarantees availability for tools that require the runtime directly.

Official Documentation:

• .NET Runtime Documentation
• WinGet .NET Runtime Package

Node.js

YAML Configuration:

- resource: Microsoft.WinGet.DSC/WinGetPackage
  id: OpenJS.NodeJS
  directives:
    allowPrerelease: true
    description: Install Node.js JavaScript runtime
  settings:
    id: OpenJS.NodeJS

Explanation:
Installs Node.js, a JavaScript runtime essential for modern web development and many Azure scenarios. Node.js is required for Azure Static Web Apps, Azure Functions (JavaScript/TypeScript), and npm-based Azure SDKs. It also supports local development and testing of Azure App Service Node.js apps.

Official Documentation:

• Node.js Documentation
• WinGet Node.js Package

Development Tools

Visual Studio Code

YAML Configuration:

- resource: Microsoft.WinGet.DSC/WinGetPackage
  id: Microsoft.VisualStudioCode
  directives:
    allowPrerelease: true
    description: Install Visual Studio Code editor
  settings:
    id: Microsoft.VisualStudioCode

Explanation:
Installs Visual Studio Code (VS Code), Microsoft’s recommended editor for Azure development. VS Code offers deep integration with Azure services through extensions, supports ARM/Bicep authoring, and provides tools for local Azure Functions and App Service development.

Official Documentation:

• Visual Studio Code Documentation
• WinGet VS Code Package

Best Practices

• Use Descriptive Comments: Each component in the YAML is well-commented, explaining its purpose and relevance to Azure development.
• Explicit Dependencies: Where necessary, dependsOn is used to ensure correct installation order (e.g., GitHub CLI depends on Git).
• Secure Installations: All tools are installed via WinGet, ensuring verified and secure sources.
• Optimized Storage: Dev Drive is configured for maximum performance, especially for large Azure repositories and build workloads.
• Modular Configuration: Each tool or runtime is defined as a separate resource, making the configuration easy to maintain and extend.
• Documentation Links: Official documentation is provided for each component, enabling quick access to further information.
• YAML Formatting: Use of consistent indentation and structure for readability and maintainability.

For further customization, consider adding Azure CLI, Azure Functions Core Tools, and specific VS Code extensions in separate configuration files to tailor the environment for specialized Azure scenarios.

4.1.5 -

Overview

The common-frontend-usertasks-config.dsc.yaml file is a PowerShell Desired State Configuration (DSC) YAML file designed to automate the setup of a comprehensive Azure frontend development environment for .NET engineers. This configuration ensures that essential tools, SDKs, and Visual Studio Code extensions are installed and kept up to date, providing a consistent and productive environment for frontend development targeting Azure services. The configuration leverages best practices for cross-platform development, automation, and security.

Table of Contents

• Postman API Platform
• .NET Workload Update
• Visual Studio Code Extensions

Component Details

Postman API Platform

YAML Configuration

- resource: Microsoft.WinGet.DSC/WinGetPackage
  id: Postman.Postman
  directives:
    description: Install Postman API platform for designing, testing and documenting APIs
    allowPrerelease: true
  settings:
    id: Postman.Postman

Explanation

This component uses the WinGet DSC resource to install the official Postman application. Postman is a widely used tool for API design, testing, and documentation, making it essential for frontend engineers working with Azure APIs and services. By automating its installation, the configuration ensures all developers have a consistent toolset for API integration and testing.

• Purpose: Enables API testing, documentation, and automation for frontend-to-backend integration.
• Why WinGet: Ensures installation of the official, verified package directly from the Microsoft package repository.

Official Documentation Link

• WinGet DSC Resource
• Postman

.NET Workload Update

YAML Configuration

- resource: PSDscResources/Script
  id: Dotnet.WorkloadUpdate
  directives:
    description: Update all installed .NET workloads
    securityContext: elevated # Requires admin rights to update .NET workloads
  settings:
    SetScript: |
      try {
          # Set execution policy for current process
          Set-ExecutionPolicy Bypass -Scope Process -Force -ErrorAction SilentlyContinue            
          
          # Ensure path is properly set
          $env:Path = [System.Environment]::GetEnvironmentVariable("Path","Machine") + ";" + [System.Environment]::GetEnvironmentVariable("Path","User")
          
          # Check if dotnet command exists before attempting updates
          if (Get-Command dotnet -ErrorAction SilentlyContinue) {
              Write-Verbose "Updating .NET workloads - this may take several minutes..." -Verbose
              
              # Update all workloads and ignore failures from sources that might be temporarily unavailable
              dotnet workload update --ignore-failed-sources
              
              Write-Verbose ".NET workloads updated successfully" -Verbose
          } else {
              Write-Warning "dotnet command not found. .NET SDK may not be installed."
          }
      } catch {
          Write-Error "Failed to update .NET workloads: $_"
      }      
    GetScript: return $false
    TestScript: return $false

Explanation

This component uses the Script resource from PSDscResources to ensure all installed .NET workloads are updated to the latest versions. This is critical for maintaining compatibility with Azure services, security, and accessing the latest features for frontend development (e.g., Blazor, MAUI, ASP.NET Core, Azure Static Web Apps tools).

• Purpose: Keeps .NET workloads current, reducing compatibility issues and security risks.
• Automation: Uses PowerShell scripting to automate updates, following Azure automation best practices for non-interactive execution.

Official Documentation Link

• PSDscResources/Script
• .NET Workloads

Visual Studio Code Extensions

YAML Configuration

- resource: PSDscResources/Script
  id: Microsoft.VisualStudioCode.Extensions
  directives:
    description: Install VS Code Extensions for Azure frontend development
    securityContext: elevated # Requires admin rights to install extensions for all users
    allowPrerelease: true # Allow prerelease versions when needed for latest features
  settings:
    SetScript: |
      try {
          # Set execution policy to bypass for automation
          Set-ExecutionPolicy Bypass -Scope Process -Force
          
          # Ensure VS Code CLI is in PATH
          $env:Path = [System.Environment]::GetEnvironmentVariable("Path","Machine") + ";" + [System.Environment]::GetEnvironmentVariable("Path","User")
          
          Write-Verbose "Installing VS Code extensions for Azure frontend development..." -Verbose
          
          # PowerShell extension for Azure automation scripts and DevOps
          code --install-extension ms-vscode.powershell
          
          # WSL integration for cross-platform development targeting Linux environments
          code --install-extension ms-vscode-remote.remote-wsl
          
          # C# extension for backend integration and full-stack development
          code --install-extension ms-dotnettools.csdevkit
          
          # TypeScript with latest features for modern web development
          code --install-extension ms-vscode.vscode-typescript-next
          
          # YAML support for deployment configurations and GitHub Actions
          code --install-extension redhat.vscode-yaml
          
          # Bicep for Azure infrastructure as code deployments
          code --install-extension ms-azuretools.vscode-bicep
          
          # Azure Tools pack for comprehensive Azure service integration
          code --install-extension ms-vscode.vscode-node-azure-pack
          
          # Azure CLI tools for command-line Azure management
          code --install-extension ms-vscode.azurecli
          
          # GitHub integration for repository management
          code --install-extension GitHub.remotehub
          
          # GitHub Pull Request integration for code reviews
          code --install-extension GitHub.vscode-pull-request-github

          # Postman extension for API testing and documentation
          code --install-extension Postman.postman-for-vscode
          
          Write-Verbose "VS Code extensions installed successfully" -Verbose
      } catch {
          Write-Error "Failed to install VS Code extensions: $_"
      }      
    GetScript: return $false
    TestScript: return $false

Explanation

This component installs a curated set of Visual Studio Code extensions essential for Azure frontend development. The extensions cover PowerShell scripting, WSL integration, C#, TypeScript, YAML, Bicep (Azure IaC), Azure CLI, and GitHub integration, ensuring developers have all the tools needed for modern, cloud-focused workflows.

• Purpose: Standardizes the development environment, boosts productivity, and ensures seamless integration with Azure services and DevOps practices.
• Automation: Uses the VS Code CLI to install extensions, ensuring repeatability and consistency across developer machines.

Official Documentation Link

• VS Code CLI Extension Management
• Visual Studio Code Extensions Marketplace

Best Practices

• Automation: Use DSC and scripting to automate environment setup, reducing manual errors and onboarding time.
• Idempotency: Although some scripts are not fully idempotent, they are structured for easy extension to check and enforce desired state.
• Security: Run installation scripts with the minimum required privileges and use official sources for all tools.
• Cross-Platform: Support both Windows and WSL2 for a flexible, modern development experience.
• Documentation: Comment each section and provide links to official documentation for further reference.
• Consistency: Standardize toolsets and extensions to ensure all developers have a uniform environment.

References

• PowerShell DSC Documentation
• WinGet Documentation
• PSDscResources
• Visual Studio Code
• Postman
• .NET Workloads
• Azure Static Web Apps