microsoft / microsoft/GitHub-Copilot-for-Azure
Pass Equity: Azure Compute Skills Lifecycle Parity — 11 PRs open for SME review
@paulyuk is already working on this.
Since Apr 1, 2026.
- 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.