Skip to content

GitHub Projects And Roadmap Operating Model

Jump to bottom
Chris Panagiotidis edited this page Jun 13, 2026 · 1 revision

GitHub Projects And Roadmap Operating Model

This page explains how the GitHub Projects, milestones, labels, and issues are used to operate the Azure Landing Zone Lab roadmap.

Use this page with:

Project Boards

Board Purpose
Master Roadmap Full roadmap across all active workstreams
Secure Foundation Security, governance, RBAC, policy, management access, and PaaS hardening
CI/CD Validation GitHub Actions, OIDC, Terraform validation, state safety, and tests
Observability Operations Monitoring, diagnostics, workbooks, runbooks, and cost operations
Workload Scenarios Workload spokes, App Gateway, AKS, smoke tests, and production-like scenarios

Milestones

Milestone Intended outcome
Project 1 - Secure Foundation & Governance Complete priority security and governance hardening
Project 2 - CI/CD, State & Validation Complete delivery pipeline and validation hardening
Project 3 - Observability & Operations Complete monitoring, evidence, runbook, and cost operations
Project 4 - Workload & Production Scenarios Complete workload validation and production-like scenarios

Labels

Label family Examples Use
Workstream project:foundation, project:cicd-validation Routes issue to the right project board
Priority priority:P0, priority:P1, priority:P2 Defines sequencing and urgency
Area area:security, area:monitoring, area:docs Helps filter by skill or subsystem
Type type:task, type:validation Separates implementation from proof

Issue Quality Standard

Every roadmap issue should include:

  • Goal.
  • Why it matters.
  • Scope.
  • Acceptance criteria.
  • Source references.
  • Wiki links.
  • Validation approach.

An issue is not ready if it does not explain how success will be proven.

Operating Rhythm

Recommended weekly flow:

  1. Review the Master Roadmap.
  2. Pull the highest-priority unblocked P0/P1 issue.
  3. Confirm the issue has clear acceptance criteria.
  4. Implement on a branch.
  5. Run local validation.
  6. Open or update PR.
  7. Attach evidence from CI, Terraform plan, Azure validation, or screenshots.
  8. Update wiki if behavior changed.
  9. Close issue only after validation evidence is present.

Definition Of Done

Work type Done means
Terraform change fmt, init, validate, plan, security scan, and policy check pass
Security change Threat/risk documented and validation proves control behavior
CI/CD change Workflow run proves the new behavior
Monitoring change Logs, metrics, diagnostics, or alerts are verified
Documentation change Sidebar, links, and related pages are updated
Cost change Cost impact and cleanup path are documented

Cross-Linking Rules

  • Each Project readme links to the relevant wiki pages.
  • Each issue should link to at least one wiki page.
  • Each major wiki page should link back to the roadmap or related project board when it describes future work.
  • Completed implementation issues should leave evidence in PRs or wiki pages, not only in comments.

Current Roadmap Entry Points

Next page: Roadmap And Backlog

Azure Landing Zone Lab

Start Here

Architecture

Deployment

Security

Operations

Validation

Reference

Clone this wiki locally