microsoft / microsoft/GitHub-Copilot-for-Azure

Pass Equity: Azure Compute Skills Lifecycle Parity — 11 PRs open for SME review

Open
#1,608 5 comments 0 reactions 1 assignee View on GitHub

@paulyuk is already working on this.

Since Apr 1, 2026.

enhancement untriaged
Dominant language
Python
Stars
250
Forks
204
Avg merge
1d 12h
Merged PRs (30d)
67

Description

## Summary — Pass Equity Scorecard

"Pass equity" measures whether a developer gets an **equally good AI-assisted experience** regardless of which Azure compute service they choose. Today, the experience is uneven — Azure Functions gets deep investment across most lifecycle phases while Container Apps and App Service have significant gaps.

> **⚠️ Starting Assessment & Proposal** — This is an initial assessment based on automated skill auditing and prior research (session `8fc96f69`, March 25 2026). Each PR proposal below is a starting point. We will leverage collaboration from each service/domain expert to modify or contribute what they believe is essential. The grades and gap analysis reflect current skill file coverage, not platform capability.

### Overall Grades (A–F scale)

| Lifecycle Phase | App Service | Container Apps | Azure Functions | Equity Gap |
|---|---|---|---|---|
| **Develop** (scaffold, code gen) | C | C | **A** | 🔴 High |
| **Deploy** (IaC, provisioning) | A | A | A | 🟢 Equitable |
| **Operate** (config, scaling, day-2) | B+ | C | B | 🟡 Medium |
| **Diagnose** (troubleshoot, logs) | B | B+ | B | 🟡 Medium |
| **Migrate** (cross-cloud) | F | F | **A** | 🔴 Critical |
| **Observe** (monitoring, APM) | A- | B | B | 🟡 Medium |
| **Secure** (RBAC, compliance) | A | A | A | 🟢 Equitable |
| **Overall** | **B-** | **C+** | **A-** | |

### Pass Equity Score: **62%** — 11 cells below A across 5 lifecycle phases

---

## Gap Specifications — One Sub-Issue Per Equity Gap

Each gap below is tracked as a **linked sub-issue** with detailed specifications. Actual **Pull Requests** implementing the fix will reference the sub-issue they close.

Each sub-issue describes: the current gap, what "A grade" looks like (learned from the highest-scoring service), the specific deliverables, and key scenarios informed by Azure Learn docs and MCP tool capabilities.

---

### [Gap-1](https://github.com/microsoft/GitHub-Copilot-for-Azure/issues/1609): App Service Develop (C → A)

**Learning from:** Functions (A) — 200+ template files, composition algorithm, 6 runtimes, 9 recipe integrations

**Current state:** 4 reference files (README, bicep, scaling, deployment-slots). No code generation, no app templates, no multi-language scaffolding.

**What "A" looks like for App Service:**
App Service's key scenarios differ from Functions — they're long-running web apps and APIs, not event-driven functions. Templates should reflect this.

**Deliverables:**
- [ ] `services/app-service/templates/selection.md` — Decision tree: Web API vs full-stack web app vs background worker (WebJobs)
- [ ] `services/app-service/templates/composition.md` — Composition algorithm (base + database + auth + caching recipes)
- [ ] **Base templates:** `web-api.md` (REST API), `web-app.md` (MVC/Razor/React SPA), `worker.md` (WebJobs/background)
- [ ] **Recipe templates** (per language: C#, Python, Node.js/TS, Java):
- `recipes/sql/` — SQL Database integration with EF Core / SQLAlchemy / Prisma / JPA
- `recipes/cosmos/` — Cosmos DB integration
- `recipes/redis/` — Azure Cache for Redis
- `recipes/auth/` — Entra ID / Easy Auth integration
- `recipes/storage/` — Blob Storage file handling
- [ ] **Language-specific source templates:** `source/dotnet.md`, `source/python.md`, `source/javascript.md`, `source/java.md`
- [ ] **Eval templates:** `eval/summary.md` per recipe
- [ ] Update `azure-prepare` routing to load App Service templates for web app requests

**Key scenarios (from Azure Learn):**
- RESTful Web APIs (ASP.NET Core, Flask/FastAPI, Express, Spring Boot)
- Full-stack web applications with server-side rendering
- Background processing with WebJobs (queue polling, scheduled tasks)
- Multi-slot deployment with staging/production swap

---

### [Gap-2](https://github.com/microsoft/GitHub-Copilot-for-Azure/issues/1610): Container Apps Develop (C → A)

**Learning from:** Functions (A) — composition algorithm with base + recipes

**Current state:** 5 reference files (README, bicep, scaling, health-probes, environment). No code generation, no container templates.

**What "A" looks like for Container Apps:**
Container Apps is a **general-purpose serverless container platform** that hosts any app stack and SDK at high scale. Key scenarios include high-scale serverless web apps, microservices with Dapr, background workers, and jobs. Event-driven processing (triggers, bindings) is best handled by **Functions on Container Apps** — bringing the Functions programming model into the Container Apps environment.

**Deliverables:**
- [ ] `services/container-apps/templates/selection.md` — Decision tree: High-scale serverless web app vs microservices vs background worker vs job vs Functions-on-Container-Apps (event-driven)
- [ ] `services/container-apps/templates/composition.md` — Composition algorithm (base + sidecar + integration recipes)
- [ ] **Base templates:**
- `web-app.md` — High-scale serverless web apps (any stack: Node.js, Python, .NET, Java, Go, Rust)
- `api.md` — REST/gRPC API services with ingress, auth, and scaling
- `microservice.md` — Multi-service architecture with service discovery
- `worker.md` — Background processing / long-running tasks
- `job.md` — Container Apps Jobs (scheduled, event-triggered, manual)
- `functions-on-aca.md` — Functions hosted on Container Apps (event-driven processing with triggers/bindings in container environment)
- [ ] **Recipe templates** (per language: C#, Python, Node.js/TS, Go, Java):
- `recipes/dapr/` — Dapr service invocation, state management, pub/sub
- `recipes/cosmos/` — Cosmos DB integration
- `recipes/servicebus/` — Service Bus integration with KEDA scaling
- `recipes/eventhubs/` — Event Hub consumer with KEDA scaling
- `recipes/redis/` — Redis state store / cache
- `recipes/acr/` — ACR build + push + deploy workflow
- `recipes/postgres/` — PostgreSQL Flexible Server integration
- [ ] **Dockerfile templates:** Per language with multi-stage builds (Node, Python, .NET, Java, Go)
- [ ] **Eval templates:** `eval/summary.md` per recipe
- [ ] Update `azure-prepare` routing to load Container Apps templates for container/microservice/serverless web app requests

**Key scenarios (from Azure Learn + domain input):**
- **High-scale serverless web apps** — Any stack/SDK with auto-scaling (including scale to zero), custom domains, managed TLS
- **Microservices** with service discovery, traffic splitting, and Dapr integration
- **Functions on Container Apps** — Event-driven processing using Functions triggers/bindings running in the Container Apps environment
- **Background workers** — Long-running processes consuming from queues or doing batch processing
- **Container Apps Jobs** — Scheduled, event-triggered, or manual batch/cron workloads
- **Any app stack** — All languages, frameworks, and SDKs that run in a container

---

### [Gap-3](https://github.com/microsoft/GitHub-Copilot-for-Azure/issues/1611): Container Apps Operate (C → A)

**Learning from:** App Service (B+) — deployment slots docs, scaling docs; Functions — `azure-upgrade` skill with Consumption→Flex automation

**Current state:** Scaling reference exists but no revision management guidance, no upgrade paths documented, no day-2 operations playbook.

**Deliverables:**
- [ ] `services/container-apps/revisions.md` — Revision management, traffic splitting, rollback patterns
- [ ] `services/container-apps/day2-operations.md` — Restart, exec into container, log streaming, environment variable updates
- [ ] `services/container-apps/networking.md` — VNet integration, internal/external ingress, custom domains, TLS
- [ ] `services/container-apps/upgrade-paths.md` — Single revision → multiple revision mode, environment SKU changes, Consumption → Dedicated
- [ ] Extend `azure-upgrade` skill to support Container Apps scenarios (or document as out-of-scope with rationale)
- [ ] Add 2 integration tests for Container Apps operate scenarios (revision management, scaling rules)

**Key scenarios:**
- Blue/green deployments via revision traffic splitting
- Canary releases with percentage-based traffic routing
- Rolling back to previous revision on failure
- Scaling rules for HTTP, Service Bus, custom metrics

---

### [Gap-4](https://github.com/microsoft/GitHub-Copilot-for-Azure/issues/1612): Functions Operate (B → A)

**Learning from:** App Service (B+) — deployment slots docs cover the slot lifecycle well

**Current state:** `azure-upgrade` skill covers Consumption→Flex. Missing: slot management guidance for Premium/Dedicated, scaling best practices across hosting plans, cold start mitigation playbook.

**Deliverables:**
- [ ] `services/functions/hosting-plans.md` — Comparison matrix: Consumption vs Flex Consumption vs Premium vs Dedicated vs Container Apps, with decision criteria
- [ ] `services/functions/cold-start.md` — Cold start mitigation strategies per plan (pre-warmed instances, always-ready, Flex minimum instances)
- [ ] `services/functions/slots.md` — Deployment slot usage for Premium/Dedicated plans, slot-sticky settings, swap best practices
- [ ] Extend `azure-upgrade` to cover Premium→Flex, Dedicated→Flex paths
- [ ] Add 1 integration test for Functions slot/swap scenario

**Key scenarios:**
- Choosing the right hosting plan for workload characteristics
- Eliminating cold starts for latency-sensitive workloads
- Zero-downtime deployments with staging slots

---

### [Gap-5](https://github.com/microsoft/GitHub-Copilot-for-Azure/issues/1613): App Service Operate (B+ → A)

**Learning from:** Functions — `azure-upgrade` skill with automated plan migration

**Current state:** Good deployment-slots and scaling references exist. Missing: automated upgrade path tooling, SKU right-sizing guidance, custom domain/TLS playbook.

**Deliverables:**
- [ ] `services/app-service/sku-selection.md` — SKU comparison matrix (Free→Basic→Standard→Premium→Isolated) with decision criteria and right-sizing guidance
- [ ] `services/app-service/custom-domains.md` — Custom domain + TLS certificate configuration via Bicep/Terraform
- [ ] `services/app-service/networking.md` — VNet integration, Private Endpoints, Access Restrictions, hybrid connections
- [ ] Extend `azure-upgrade` skill with App Service SKU upgrade paths (Free→Standard, Standard→Premium, etc.)
- [ ] Add 1 integration test for App Service operate (scaling or slot swap)

**Key scenarios:**
- Right-sizing SKU based on CPU/memory utilization metrics
- Custom domain with managed TLS certificate
- VNet integration for secure backend connectivity

---

### [Gap-6](https://github.com/microsoft/GitHub-Copilot-for-Azure/issues/1614): App Service Diagnose (B → A)

**Learning from:** Container Apps (B+) — dedicated `container-apps/README.md` with specific troubleshooting flows for image pulls, cold starts, health probes

**Current state:** No dedicated App Service diagnostic reference. Falls back to general AppLens flow. Despite having the richest MCP tooling (7 commands), there's no guidance on when/how to use each.

**Deliverables:**
- [ ] `references/app-service/README.md` in `azure-diagnostics` — Dedicated troubleshooting guide covering:
- High CPU/memory diagnosis (with specific AppLens detectors)
- Deployment failure analysis (Kudu logs, deployment history API)
- Application crash/restart diagnosis (Event Log, STDERR)
- Slow response time investigation (request tracing, dependency analysis)
- Custom domain / TLS certificate issues
- [ ] MCP tool usage guide — when to use each of the 7 App Service MCP commands for diagnostics
- [ ] Add 2 integration tests: deployment failure troubleshooting, high CPU diagnosis

**Key scenarios:**
- "My app is slow" → CPU profiler, request traces, dependency map
- "My deployment failed" → Kudu logs, SCM site, deployment history
- "My app keeps restarting" → event logs, health check failures, memory limits

---

### [Gap-7](https://github.com/microsoft/GitHub-Copilot-for-Azure/issues/1615): Functions Diagnose (B → A)

**Learning from:** Container Apps (B+) — has both reference docs AND integration tests for diagnostics

**Current state:** Has dedicated `functions/README.md` reference with ARG queries for monitoring discovery. Missing: integration tests, trigger-specific troubleshooting, binding error diagnosis.

**Deliverables:**
- [ ] Extend `references/functions/README.md` with:
- Trigger-specific troubleshooting (HTTP 5xx, timer misfires, queue poison messages, blob trigger delays)
- Binding error diagnosis (connection string issues, permission errors, SDK version conflicts)
- Durable Functions troubleshooting (stuck orchestrations, replay issues, task hub conflicts)
- Flex Consumption-specific issues (instance allocation, networking)
- [ ] Add 2 integration tests: trigger failure diagnosis, binding error troubleshooting

**Key scenarios:**
- "My timer function isn't firing" → NCRONTAB validation, singleton lock, scale controller logs
- "My queue trigger has poison messages" → dead-letter analysis, maxDequeueCount config
- "My Durable orchestration is stuck" → task hub status, purge instance history

---

### [Gap-8](https://github.com/microsoft/GitHub-Copilot-for-Azure/issues/1616): App Service Migrate — AWS Elastic Beanstalk → App Service (F → A)

**Learning from:** Functions Migrate (A) — 4-phase workflow (assess → migrate code → generate IaC → hand off), mandatory assessment report, 6 runtime guides, 12 service mappings

**Current state:** Zero coverage. No reference docs, no triggers, no tests.

**Deliverables:**
- [ ] `references/services/app-service/beanstalk-to-app-service.md` — Full migration guide:
- Platform preset → App Service Plan SKU mapping
- `.ebextensions/` → Bicep/App Settings conversion
- RDS → Azure SQL / Cosmos DB mapping
- ALB → App Service built-in LB / Front Door
- Environment variables → App Configuration / Key Vault
- [ ] `references/services/app-service/heroku-to-app-service.md` — Heroku migration guide:
- Dynos → App Service instances
- Procfile → Docker entrypoint / startup command
- Add-ons → Azure managed services mapping
- Buildpacks → Docker containers
- [ ] `references/services/app-service/app-engine-to-app-service.md` — GAE migration guide
- [ ] Runtime guides: `runtimes/` for Python, Node.js, Java, .NET (App Service specifics)
- [ ] Assessment template for PaaS-to-PaaS migrations
- [ ] Add routing rules in `azure-cloud-migrate` SKILL.md for Beanstalk/Heroku/GAE keywords
- [ ] Add trigger tests for App Service migration prompts
- [ ] Add 1 integration test with a real Beanstalk sample app

**Key service mappings:**

| AWS/Heroku/GCP | Azure App Service |
|---|---|
| Elastic Beanstalk Platform | App Service runtime stack |
| Heroku Dynos | App Service instances |
| App Engine Standard/Flex | App Service Plan Basic/Premium |
| `.ebextensions/` | Bicep + App Settings |
| Procfile | Startup command / Docker |
| RDS/Heroku Postgres | Azure SQL / PostgreSQL Flexible Server |
| ElastiCache/Redis add-on | Azure Cache for Redis |
| S3 | Azure Blob Storage |
| CloudFront/Heroku edge | Azure Front Door / CDN |

---

### [Gap-9](https://github.com/microsoft/GitHub-Copilot-for-Azure/issues/1617): Container Apps Migrate — AWS ECS/Fargate + Cloud Run → Container Apps (F → A)

**Learning from:** Functions Migrate (A) — same 4-phase pattern, adapted for containers

**Current state:** Zero coverage. GCP mentioned in triggers only, no scenario guidance.

**Deliverables:**
- [ ] `references/services/container-apps/ecs-to-container-apps.md` — Full migration guide:
- Task definitions → Container App YAML specs
- Service definitions → Container App revisions + ingress
- Fargate launch type → Consumption plan
- ECR → ACR migration (image transfer)
- ECS Service Connect → Container Apps service discovery
- ALB/NLB routing → Container Apps ingress rules
- App Mesh → Dapr integration
- CloudWatch → Application Insights / Log Analytics
- [ ] `references/services/container-apps/cloud-run-to-container-apps.md` — GCP migration guide:
- Cloud Run service/revision → Container App/revision (very similar model)
- Artifact Registry → ACR
- Cloud Run Jobs → Container Apps Jobs
- Secret Manager → Key Vault
- Concurrency settings → container concurrency config
- [ ] Container-specific assessment template (image analysis, port mapping, env vars, secrets, volumes)
- [ ] Add routing rules in `azure-cloud-migrate` for ECS/Fargate/Cloud Run keywords
- [ ] Add trigger tests for Container Apps migration prompts
- [ ] Add 1 integration test with a real ECS or Cloud Run sample app

**Key service mappings:**

| AWS ECS/GCP Cloud Run | Azure Container Apps |
|---|---|
| Task Definition / Cloud Run YAML | Container App spec |
| Fargate / Cloud Run serverless | Consumption plan |
| ECR / Artifact Registry | Azure Container Registry |
| ECS Service Connect / Cloud Run svc | Container Apps service discovery |
| ALB / Cloud Run ingress | Container Apps ingress |
| App Mesh / Istio | Dapr |
| CloudWatch / Cloud Logging | App Insights + Log Analytics |
| ECS Exec / Cloud Run exec | Container Apps console |
| Task IAM / IAM SA | Managed Identity |
| KEDA (EKS) / min-instances | KEDA autoscaling |

---

### [Gap-10](https://github.com/microsoft/GitHub-Copilot-for-Azure/issues/1618): Container Apps Observe (B → A)

**Learning from:** App Service (A-) — has auto-instrumentation reference; Functions — has ARG query for monitoring discovery

**Current state:** Manual SDK instrumentation only. No auto-instrumentation. No monitoring discovery queries. No Container Apps-specific observability playbook.

**Deliverables:**
- [ ] `references/container-apps/observability.md` in `appinsights-instrumentation` — Container Apps-specific guide:
- Environment-level Log Analytics workspace setup
- System logs vs application logs distinction
- Container Apps metrics (replica count, HTTP requests, CPU/memory per replica)
- Distributed tracing across microservices with Dapr
- [ ] ARG queries for Container Apps monitoring discovery (find workspace, check instrumentation status)
- [ ] `references/container-apps/dapr-observability.md` — Dapr telemetry collection, tracing configuration
- [ ] Add dashboard/metrics guidance for Container Apps Environment-level monitoring
- [ ] Add 1 integration test for Container Apps observability setup verification

**Key scenarios:**
- "Are my Container Apps sending telemetry?" → ARG discovery query
- Distributed tracing across microservices with correlation IDs
- Dapr pub/sub and service invocation observability
- Container Apps Environment system logs vs app logs

---

### [Gap-11](https://github.com/microsoft/GitHub-Copilot-for-Azure/issues/1619): Functions Observe (B → A)

**Learning from:** App Service (A-) — auto-instrumentation option

**Current state:** Manual SDK instrumentation, ARG queries for monitoring discovery exist. Missing: Functions-specific observability best practices, invocation-level tracing, Durable Functions monitoring.

**Deliverables:**
- [ ] `references/functions/observability.md` in `appinsights-instrumentation` — Functions-specific guide:
- FunctionAppLogs table queries for invocation analysis
- Invocation-level tracing (invocation ID, trigger details)
- Durable Functions monitoring (orchestration status, activity timing)
- Host-level vs function-level telemetry
- [ ] Built-in monitoring integration reference (Functions + App Insights auto-connection)
- [ ] KQL query library for common Functions diagnostics (error rate, duration P50/P95/P99, cold start frequency)
- [ ] Add 1 integration test for Functions observability setup

**Key scenarios:**
- Invocation duration analysis (P50/P95/P99 by function name)
- Cold start frequency tracking per hosting plan
- Durable Functions orchestration monitoring dashboard
- Scaling event correlation with performance metrics

---

## Summary Table — All Gap Sub-Issues

> Each row links to a **sub-issue** with full specifications. Implementation PRs will be opened against the `pass-equity` branch and will reference these issues.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.