Azure DevOps → GitHub + Copilot: doporučený phased přechod

Krátké doporučení

Nejlepší cesta není jednorázová „big bang“ migrace celého Azure DevOps. Doporučený model je postupný přechod:

1. GitHub zavést nejdřív jako cílovou platformu pro kód, pull requesty, code review, security a Copilot.
2. Azure Boards a část Azure Pipelines ponechat dočasně v provozu, pokud dnes drží delivery proces, release reporting nebo komplexní existující pipeline.
3. Nový vývoj a vybrané pilotní týmy přesunout do GitHubu jako první.
4. CI/CD migrovat po vlnách z Azure Pipelines do GitHub Actions, ne všechno naráz.
5. Copilot zavádět řízeně: licence, policies, pilot, měření adopce, školení a governance.

Tím vznikne hybridní období, kdy GitHub přebírá roli moderní developer platformy, ale Azure DevOps se nevypíná dřív, než jsou přepsané kritické pipeline, reporting a procesní závislosti.

Co dává smysl migrovat do GitHubu

Prakticky: začít se má u aktivních repozitářů, které mají jasné vlastníky, rozumně izolované pipeline a tým ochotný fungovat jako pilot. Historické nebo málo aktivní repozitáře není nutné migrovat jako první.

Co může dočasně zůstat v Azure DevOps

Dočasné ponechání některých částí v Azure DevOps není selhání migrace. Naopak snižuje riziko.

Důležité je definovat konečný stav: co zůstane dlouhodobě v Azure DevOps, co se migruje později a co se jen archivuje. Bez tohoto rozhodnutí se hybridní stav může změnit v trvalý chaos.

Doporučený cílový operating model

Cílový model by měl být jednoduchý:

• GitHub Enterprise / organizace jako hlavní místo pro repozitáře, pull requesty, review, Actions, security a Copilot.
• Standardizované GitHub organizace, týmy a oprávnění místo ad-hoc přístupů.
• Branch protection / rulesets pro hlavní branche: povinné review, status checks, podepisování nebo další guardraily podle potřeby.
• GitHub Actions jako default pro nové CI/CD, Azure Pipelines jen pro pipeline, které ještě nejsou převedené nebo mají silnou Azure DevOps závislost.
• Copilot jako řízený enterprise nástroj, ne jako individuální experiment bez policies.
• Jasná pravidla pro secrets, service connections a environments před masovou migrací pipeline.
• Azure DevOps jako dočasný zdroj legacy workflow, ne jako rovnocenný nový development hub.

Co založit a nastavit na začátku

Ještě před první větší migrační vlnou je potřeba připravit základní GitHub platformu a governance:

1. Rozhodnout GitHub Enterprise setup — enterprise account, cílový identity/access model, billing/cost governance a vlastnictví správy.
2. Navrhnout organizace a týmy — jedna hlavní organization vs. více organizací podle business/security hranic; mapování Azure DevOps projektů a týmů na GitHub teams.
3. Připravit repozitářový standard — repository naming, visibility, team permissions, CODEOWNERS, branch protection/rulesets, PR šablony a povinné status checks.
4. Připravit CI/CD baseline — Actions runner model, environments, secrets, approvals, reusable workflows a pravidla pro to, co zatím zůstane v Azure Pipelines.
5. Připravit Copilot governance — Business/Enterprise plán, seat assignment, policies, supported IDEs, pravidla pro citlivá data a měření adopce.
6. Ujasnit Azure DevOps variantu — GitHub Enterprise Importer cílí na migrace z Azure DevOps Cloud; pokud firma používá Azure DevOps Server/on-prem, je potřeba nejdřív naplánovat mezikrok nebo alternativní migrační cestu přes Azure DevOps Cloud.

Zavedení GitHub Copilot

Copilot by se neměl zavádět jen nákupem licencí. Je potřeba ho zavést jako změnu vývojového procesu.

1. Vybrat plán a správu

Pro firemní prostředí dávají smysl hlavně GitHub Copilot Business nebo GitHub Copilot Enterprise. Oba jsou určené pro organizační správu, policy control a centrální řízení. Enterprise varianta dává větší smysl, pokud firma chce hlubší integraci do GitHub Enterprise prostředí, znalostní kontext a širší governance.

Zdroj: Plans for GitHub Copilot

2. Nastavit policies před rolloutem

Před plošným zapnutím je potřeba rozhodnout minimálně:

• kdo dostane licenci,
• jestli bude povolený návrh kódu odpovídající veřejnému kódu,
• jaké IDE a prostředí jsou podporované,
• jak se bude nakládat s citlivým kódem a daty,
• jaká pravidla platí pro review AI-generovaného kódu,
• kdo smí měnit Copilot nastavení.

Zdroj: Managing GitHub Copilot in your organization

3. Spustit pilot

Pilot má být malý, ale reprezentativní. Doporučení:

• 1–3 týmy,
• aktivní repozitáře,
• mix seniorních a méně zkušených vývojářů,
• jasná metrika: adopce, subjektivní přínos, dopad na PR workflow, bezpečnostní připomínky, typy úloh, kde Copilot pomáhá/nepomáhá.

4. Školení a pravidla použití

Vývojáři musí vědět, že Copilot je asistent, ne autorita. Praktická pravidla:

• AI návrhy vždy procházejí stejným review jako ručně psaný kód.
• Copilot se používá hlavně na boilerplate, refactoring, testy, vysvětlení kódu, dokumentaci a menší implementační kroky.
• Neposílat do promptů tajemství, privátní klíče, produkční osobní data ani interní informace mimo povolený režim.
• U bezpečnostně citlivého kódu počítat s vyšší kontrolou.

Zdroj: Rolling out GitHub Copilot at scale

Doporučený phased přechod

Fáze 0: Příprava a inventura (0–30 dní)

Cíl: rozhodnout rozsah a vybrat pilot.

Checklist:

• Sepsat repozitáře, vlastníky, aktivitu, branche, pipeline, service connections, secrets a release procesy.
• Rozdělit repozitáře na: migrovat hned, migrovat později, ponechat/archivovat.
• Vybrat cílovou GitHub organizaci/enterprise strukturu.
• Nastavit týmy, oprávnění, branch rules, secret management a základní governance.
• Vybrat Copilot Business/Enterprise variantu a připravit policies.
• Vybrat 1–3 pilotní týmy a 3–10 pilotních repozitářů.

Výstup fáze: schválený migrační backlog, pilotní scope, GitHub governance baseline a Copilot policy baseline.

Fáze 1: Pilot GitHub + Copilot (30–60 dní)

Cíl: ověřit přechod na reálných projektech bez ohrožení celé delivery.

Checklist:

• Migrovat pilotní repozitáře do GitHubu.
• Nastavit PR workflow, branch protection/rulesets a status checks.
• Převést jednodušší CI pipeline do GitHub Actions.
• Komplexní release pipeline klidně ponechat v Azure Pipelines.
• Zapnout Copilot pilotní skupině.
• Sledovat adopci, problémy, feedback, bezpečnostní připomínky a dopad na review.
• Dokumentovat šablony: repository template, Actions template, PR template, CODEOWNERS, pravidla pro secrets.

Výstup fáze: ověřený pilot, první migrované repozitáře, funkční Copilot governance, šablony pro škálování.

Fáze 2: Škálování aktivních repozitářů (60–90 dní)

Cíl: přenést většinu aktivního vývoje do GitHubu.

Checklist:

• Migrovat aktivní repozitáře po vlnách podle týmů nebo produktů.
• Pro každou vlnu předem zkontrolovat pipeline, secrets, permissions a rollback plán.
• Přepisovat Azure Pipelines do GitHub Actions podle priority a složitosti.
• Ponechat Azure Boards, pokud je stále potřeba pro delivery reporting.
• Rozšířit Copilot licence na další týmy po dokončení pilotního vyhodnocení.
• Zavést standardní onboarding pro nové repozitáře v GitHubu.

Výstup fáze: GitHub jako default pro aktivní kód a PR workflow; Azure DevOps už primárně jen pro zbylé Boards, legacy pipeline a historické artefakty.

Fáze 3: Konsolidace a vypínání zbytků (90+ dní)

Cíl: snížit hybridní komplexitu.

Checklist:

• Rozhodnout, které Azure Pipelines se migrují, které zůstanou a které se ruší.
• Archivovat nebo read-only označit staré repozitáře.
• Vyřešit dlouhodobý model pro work item historii a reporting.
• Zkontrolovat náklady licencí, Actions minut, storage a Copilot využití.
• Upevnit security baseline: secret scanning, dependency review, code scanning podle potřeby.

Výstup fáze: stabilizovaná platforma, menší závislost na Azure DevOps a jasný provozní model.

Konzervativní vs. ambiciózní varianta

Konzervativní varianta

Vhodná, pokud jsou Azure Pipelines složité, organizace má silné reporting závislosti na Azure Boards nebo nejsou připravení vlastníci repozitářů.

• Repozitáře migrovat po menších vlnách.
• Azure Boards ponechat déle.
• Azure Pipelines migrovat jen tam, kde je jasný přínos.
• Copilot rozšiřovat postupně po pilotu.

Výhoda: nižší riziko narušení delivery. Nevýhoda: delší hybridní období.

Ambiciózní varianta

Vhodná, pokud jsou repozitáře dobře zmapované, pipeline jsou relativně jednoduché a týmy chtějí rychle přejít na GitHub-first model.

• Nové projekty okamžitě jen v GitHubu.
• Aktivní repozitáře migrovat ve 2–3 větších vlnách.
• CI pipeline přepisovat do Actions agresivněji.
• Copilot zapnout širší skupině po krátkém pilotu.

Výhoda: rychlejší sjednocení developer experience. Nevýhoda: vyšší nároky na koordinaci, testování pipeline a podporu týmů.

Hlavní rizika

Praktická migrační mapa

Odkazy na zdroje

• GitHub Docs — Understand migrations from Azure DevOps to GitHub
• GitHub Docs — Migrating from Azure Pipelines to GitHub Actions
• GitHub Docs — Plans for GitHub Copilot
• GitHub Docs — Rolling out GitHub Copilot at scale
• GitHub Docs — Managing GitHub Copilot in your organization
• GitHub Docs — About GitHub Projects

Finální doporučení pro leadership

Začněte GitHubem jako novým vývojářským centrem, ne jako okamžitou náhradou všech Azure DevOps funkcí. Nejprve přesuňte aktivní kód, PR workflow, bezpečnostní kontroly a Copilot. Azure Boards a složité Azure Pipelines ponechte dočasně tam, kde snižují riziko. Po pilotu škálujte migraci po vlnách a průběžně snižujte závislost na Azure DevOps.

Nejbezpečnější rozhodnutí: GitHub-first pro nový a aktivní vývoj, Azure DevOps jako řízená přechodová vrstva, Copilot jako enterprise nástroj s governance od prvního dne.