Server Azure DevOps - Azure DevOps Server

Server Azure DevOps
Vývojáři	Microsoft
První vydání	2005 ; Před 16 lety
Stabilní uvolnění	Aktualizace 2020 1 / 10. srpna 2021 ; před 2 měsíci
Operační systém	Microsoft Windows
Typ	Správa životního cyklu aplikace
Licence	Zkušební verze
webová stránka	blankyt microsoft.com si .com / en-us / services / devops / server /

Azure devops Server (dříve Team Foundation Server (TFS) a Visual Studio Team System (VSTS)) je Microsoft produkt, který poskytuje řízení verzí (a to buď s Team Foundation Řízení verzí (TFVC) nebo Git ), reporting, řízení požadavků , projektové řízení ( pro týmy agilního vývoje softwaru i pro vodopády ), automatické sestavování, testování a možnosti správy vydání . Pokrývá celý životní cyklus aplikace a umožňuje funkce DevOps . Azure DevOps lze použít jako back-end pro řadu integrovaných vývojových prostředí (IDE), ale je přizpůsoben pro Microsoft Visual Studio a Eclipse na všech platformách.

On-premis vs. online

Azure DevOps je k dispozici ve dvou různých formách: místní („server“) a online („služby“). Druhá forma se nazývá Azure DevOps Services (dříve Visual Studio Online, než byla v roce 2015 přejmenována na Visual Studio Team Services). Cloudová služba je podporována cloudovou platformou Microsoft Azure . Používá stejný kód jako místní verze Azure DevOps s drobnými úpravami a implementuje nejnovější funkce. Uživatel se přihlásí pomocí účtu Microsoft k nastavení prostředí, vytváření projektů a přidávání členů týmu. Nové funkce vyvinuté v krátkých vývojových cyklech jsou nejprve přidány do cloudové verze. Tyto funkce migrují na místní verzi jako aktualizace, přibližně ve tříměsíčních intervalech.

Architektura

Serverová architektura

Azure DevOps je postaven na víceúrovňové škálovatelné architektuře. Primární struktura se skládá z aplikační vrstvy zodpovědné za logiku zpracování a údržbu portálu webové aplikace (označovaný jako Team Web Access nebo TWA). Azure DevOps je vytvořen pomocí webových služeb Windows Communication Foundation . Ty může spotřebovat jakýkoli klient, ačkoli je doporučen objektový model klienta. Datová a aplikační vrstva mohou existovat na stejném počítači.

K podpoře škálovatelnosti může být aplikační vrstva vyrovnávána zátěží a datová vrstva může být seskupena. Pokud používáte Microsoft SQL Server 2012 nebo novější, jsou podporovány clustery Failover a skupiny dostupnosti AlwaysOn SQL Server, které umožňují geografickou replikaci dat. Primární kontejner je kolekce projektů. Kolekce projektů je databáze, která obsahuje skupinu týmových projektů. Kolekce projektů je dalším mechanismem škálovatelnosti, protože každou kolekci lze umístit na různé instance serverů SQL nebo SQL Server. Konfigurační databáze „Oe“ na instanci Azure DevOps ukládá metadata kolekce projektů. Data z databází shromažďování projektů jsou agregována do skladové databáze, která denormalizuje data připravená k načtení do krychle Analysis Services. Sklad a krychle umožňují komplexní hlášení trendů a analýzu dat.

Azure DevOps se může integrovat s existující farmou SharePoint . SQL Server Reporting Services jsou podporovány pro pokročilejší vykazování proti datovému skladu nebo datové krychli Analysis Services. Tyto instalace mohou být na stejném systému nebo na různých systémech. Do infrastruktury lze také přidat servery pro správu, servery pro správu laboratoří, servery pro správu vydání a proxy servery (aby se snížilo určité zatížení aplikační vrstvy), testovací stroje a stroje pro testování zatížení. Pro podporu týmů vyžadujících plánování podnikových projektů se Azure DevOps také integruje s Microsoft Project Server , který umožňuje správu portfolia, správu zdrojů a sledování projektů na podnikové úrovni.

Rozšiřitelnost

Společnost Microsoft poskytuje dvě samostatná redistribuovaná rozhraní API pro připojení k Azure DevOps. Jedna je Java SDK, druhá je .NET Framework SDK. Tato rozhraní API umožňují připojení klienta k Azure DevOps. Protože je Azure DevOps napsán na architektuře orientované na služby, může komunikovat prakticky s jakýmkoli nástrojem, který může volat webovou službu. Dalším rozšiřitelným mechanismem je přihlášení k odběru systémových upozornění: například upozornění na změnu pracovní položky nebo dokončení sestavení. Existuje přibližně 20 předkonfigurovaných výstrah a týmy mohou nakonfigurovat tolik dalších výstrah, kolik je potřeba. Při použití v rozšiřitelném scénáři lze tato upozornění odeslat do webové služby, což spustí akce pro změnu nebo aktualizaci pracovních položek (například implementace pokročilých obchodních pravidel nebo generování pracovních položek programově na základě daného scénáře).

Datový sklad lze také rozšířit vytvořením vlastních adaptérů datového skladu. Se zavedením TFS 2012 lze také vytvářet vlastní doplňky pro Team Web Access s názvem Web Access Extensions .

Klienti

Azure DevOps podporuje Visual Studio 2010 a novější, Microsoft Test Manager (MTM) 2012 a 2013. Eclipse, starší verze Visual Studia a další prostředí lze do Azure DevOps zapojit pomocí poskytovatele integrace Microsoft Source Code Control Integration (MSSCCI Provider - vyslovováno „ Miss-Key “). Tyto nástroje poskytují plný přístup k funkcím v Azure DevOps.

Podporovány jsou také aplikace Microsoft Excel a Microsoft Project, které pomáhají spravovat pracovní položky, což umožňuje hromadnou aktualizaci, hromadné zadávání a hromadný export pracovních položek. Program Microsoft Project lze použít k naplánování práce v souladu s metodikou vývoje vodopádového softwaru. Excel i Project podporují obousměrné aktualizace dat. To například umožňuje projektovým manažerům vložit plán do Projectu, nechat tuto práci importovat do Azure DevOps, kde vývojáři aktualizují práci, a poté lze plán aktualizovat, aniž by musel správce projektu provádět další práci.

S Team Foundation Server 2012 byl Microsoft PowerPoint také integrován s Azure DevOps, aby umožnil rychlý vývoj storyboardu a pomohl s procesem správy požadavků. Integrace poskytuje rozšiřitelné tvary scénáře, které lze použít k sestavení jakéhokoli modelu makety rozhraní, který lze poté animovat pomocí integrovaných funkcí aplikace PowerPoint. Tyto scénáře pak lze propojit s pracovními položkami.

Ve snaze zvládnout rostoucí geografický rozptyl týmů a zapojit zúčastněné strany dříve a častěji do procesu, společnost Microsoft přidala klienta pro zpětnou vazbu. Tento nástroj umožňuje uživatelům provádět aplikace, komentovat to, co vidí, pomocí zvuku a videa, pořizovat obrazovky a poskytovat kontextovou zpětnou vazbu vývojovému týmu. To poskytuje konkrétní zpětnou vazbu o funkcích aplikace z pohledu uživatelů, aniž by bylo nutné schůzky a demonstrační relace. Azure DevOps také poskytuje nástroje příkazového řádku pro prostředí Unix i Windows. Power Tools pro TFS obsahuje integraci prostředí Windows, která umožňuje uživatelům vkládat a odebírat soubory, přidávat soubory a provádět další základní úkoly kliknutím pravým tlačítkem na soubor nebo složku.

Pracovní položky

Srdcem Azure DevOps je „pracovní položka“. Pracovní položka představuje věc - může to být práce, kterou je třeba splnit, riziko sledování, testovací případ, chyba nebo prakticky cokoli jiného, co si uživatel dokáže představit. Pracovní položky jsou definovány prostřednictvím dokumentů XML a jsou vysoce rozšiřitelné. Pracovní položky jsou sloučeny do šablony procesu, která obsahuje tyto a další informace, a poskytuje tak vývojový rámec. Azure DevOps obsahuje šablony procesů pro Microsoft Solutions Framework pro Agile, Scrum a CMMI. Týmy se mohou rozhodnout použít vestavěnou šablonu nebo jednu z mnoha šablon dostupných pro použití vytvořených třetími stranami. Šablony procesů lze přizpůsobit pomocí editoru šablon procesů, který je součástí Power Tools.

Pracovní položky lze navzájem propojit pomocí různých vztahů k vytvoření hierarchického stromu pracovních položek nebo plochého vztahu mezi pracovními položkami. Pracovní položky lze také propojit s externími artefakty, jako jsou webové stránky, dokumenty ve sdílené složce nebo dokumenty uložené v jiném úložišti, jako je SharePoint. Pracovní položky lze také propojit se zdrojovým kódem, výsledky sestavení, výsledky testů a konkrétními verzemi položek ve zdrojovém řízení.

Flexibilita v systému pracovních položek umožňuje Azure DevOps hrát mnoho rolí od správy požadavků po sledování chyb, sledování rizik a problémů a také zaznamenávání výsledků recenzí. Rozšiřitelné možnosti propojení zajišťují, že sledovatelnost od požadavků ke zdrojovým kódům až po testovací případy a výsledky lze dosáhnout a hlásit pro účely auditu i historického chápání změn.

Ovládání zdroje

Azure DevOps podporuje dva různé typy řízení zdrojů - jeho původní zdroj pro řízení zdroje s názvem Team Foundation Version Control (TFVC) a s vydáním TFS 2013 podporuje Git jako úložiště zdrojů pro řízení zdroje.

Kontrola verze Team Foundation

TFVC je centralizovaný systém pro správu verzí, který umožňuje týmům ukládat jakýkoli typ artefaktu do jeho úložiště. TFVC podporuje při práci s klientskými nástroji dva různé typy pracovních prostorů - Server Workspaces a Local Workspaces. Serverové pracovní prostory umožňují vývojářům zamykat soubory pro odhlášení a poskytovat ostatním vývojářům oznámení, že se soubory upravují. Častou stížností tohoto modelu je, že soubory na vývojovém počítači jsou označeny jako jen pro čtení. Rovněž vyžaduje, aby vývojáři „přešli do režimu offline“, pokud nelze kontaktovat server. Místní pracovní prostory byly navrženy tak, aby se těmto problémům vyhnuly. Ve scénáři místního pracovního prostoru nejsou soubory jen pro čtení a nemusí se před prací na nich rezervovat. Dokud jsou soubory na místním počítači vývojáře, nezáleží na tom, zda je server připojen nebo ne. Konflikty se řeší při příjezdu .

Aby se zlepšil výkon pro vzdálené klienty, Azure DevOps obsahuje možnost instalace proxy serverů . Proxy servery umožňují ukládání obsahu řízení zdrojů do mezipaměti na místě blíže k vývojářům, aby se předešlo dlouhým výpadkům sítě a související latenci. Ohlášení se stále provádějí přímo proti aplikační vrstvě Azure DevOps, takže proxy server je ve scénářích čtení nejvýhodnější.

Azure DevOps jako součást modulu pro správu zdrojových kódů podporuje řadu funkcí, které pomáhají vývojářům zajistit, aby kód, který je zaškrtnutý, dodržoval konfigurovatelná pravidla. Tento modul pravidel se nazývá Zásady odbavení. Existuje několik zásad po vybalení z krabice, jako jsou zásady komentářů Changeset, které nedovolí ohlášení, pokud vývojář nezadá komentář k ohlášení. Tyto zásady lze rozšířit a lze je použít k prozkoumání všech aspektů kontrolovaného kódu, komentářů a souvisejících pracovních položek. Azure DevOps také podporuje funkci Code Analysis, která je při samostatném použití známá jako FxCop . Zahrnutí do Azure DevOps znamená, že analýzu lze spustit proti kódu zaškrtnutému na serveru a během automatizovaných sestavení.

Rozšíření Azure Repos pro kód Visual Studio podporuje TFVC.

Git

S vydáním TFS 2013 společnost Microsoft přidala nativní podporu pro Git . Nejedná se o konkrétní implementaci společnosti Microsoft, ale o standardní implementaci založenou na knihovně libgit2. Je to stejná knihovna, která ovládá populární GitHub, a kód je volně dostupný na GitHubu. Protože společnost Microsoft přistoupila k použití standardní knihovny, lze nyní libovolného klienta Git používat nativně s Azure DevOps (jinými slovy, vývojáři mohou používat své oblíbené nástroje a nikdy nenainstalují standardní klienty Azure DevOps). To umožňuje nástrojům na jakékoli platformě a libovolném IDE, které podporují Git, připojení k Azure DevOps. Například Xcode i Android Studio podporují doplňky Git. Kromě toho, pokud vývojáři nechtějí používat modul Microsoft Team Explorer Everywhere pro Eclipse , mohou se rozhodnout použít eGit k připojení k Azure DevOps.

Použití Gitu nevylučuje výhodu používání pracovní položky nebo systému sestavení Azure DevOps. Při kontrole kódu pomocí Gitu odkazování na ID pracovní položky v komentáři k check-inu přiřadí check-in k dané pracovní položce. Stejně tak Team Build bude také stavět projekty Git.

Jedním z hlavních důvodů použití Azure DevOps jako úložiště Git je to, že je podporován serverem SQL Server a má stejnou ochranu jako Team Foundation Version Control (TFVC). To dává vývojářům několik možností při výběru typu projektu a stylu práce, který jim nejlépe vyhovuje.

Hlášení

Reporting je základní součástí Azure DevOps od jeho počátečního vydání v roce 2005. Reportovací infrastruktura se skládá z datového skladu (Tfs_Warehouse), což je relační databáze a datové krychle SQL Server Analysis Services. Když je tato možnost nainstalována, jsou oba tyto zdroje k dispozici pro hlášení prostřednictvím služby SQL Server Reporting Services. Protože se jedná o standardní databázové a krychlové struktury, může z nich hlásit jakýkoli nástroj, který může na tyto zdroje dat odkazovat. To zahrnuje nástroje jako Cognos, Tableau, Excel a další nástroje pro vytváření sestav. Součástí každé šablony procesu po vybalení z krabice je sada zpráv pro služby hlášení, které zahrnují informace o sestavení, výsledky testů a průběh, řízení projektů, agilní zprávy (přehled nevyřízených položek, Release Burndown, Sprint Burndown a Velocity), data o chybách a problémech. Nové sestavy lze vytvářet pomocí Report Builderu pro SSRS a kterékoli ze stávajících sestav lze upravit.

Pro výsledky zátěžových testů je k dispozici specializovanější reporting. Tato data jsou k dispozici přímo v aplikaci Visual Studio a lze je exportovat do aplikace Excel pro podrobnou analýzu.

TFS 2013 představil novou funkci nazvanou „odlehčené vykazování“, která umožňuje vytvářet zprávy v reálném čase na základě výsledků dotazů a nespoléhá se na sklad nebo krychli. TFS 2012 (a pokračování do roku 2013) nabízí diagramy burndown, rychlosti a CFD v reálném čase přímo v Team Web Access.

Budování týmu

Team Build (před TFS 2015) je serverová aplikace sestavení, která je součástí Team Foundation Server. Team Build tvoří dvě komponenty - MSBuild a Windows Workflow Foundation . MSBuild je deklarativní jazyk XML podobný Apache Ant . WF byl přidán do procesu sestavování počínaje TFS 2010; předtím byl k dispozici pouze MSBuild. Možnosti sestavení se nadále vyvíjely s každým dalším vydáním Azure DevOps. V TFS 2010 a 2012 byly soubory šablon WF ( Extensible Application Markup Language ) uloženy ve zdrojovém řízení a mohly být upravovány a verzovány přímo ze zdrojového řízení. V TFS 2013 byly tyto soubory odstraněny, aby se odstranil nepořádek a zefektivnil proces sestavení. Šablony WF lze i nadále stahovat, upravovat a ukládat ve zdrojovém řízení, pokud je to žádoucí, a TFS 2013 neporušuje stávající šablony procesu sestavování TFS 2010 nebo 2012. S podporou Gitu v TFS 2013 byla vylepšena Team Build, aby umožňovala automatické vytváření projektů Git i TFVC.

Windows Workflow řídí celkový tok procesu sestavení a Azure DevOps obsahuje mnoho předem připravených aktivit pracovního toku pro správu běžných úkolů, které se provádějí během sestavení. MSBuild je značkovací jazyk, který se nachází v souborech .proj (csproj pro projekty C# a vbproj pro projekty Visual Basic). Systém sestavení je rozšiřitelný, přičemž uživatelé mohou vytvářet vlastní aktivity pracovního toku, schopnost vkládat do procesu MSBuild a spouštět externí procesy. Povaha pracovního toku sestavení umožňuje neomezenou flexibilitu, ale k dosažení této flexibility může být zapotřebí určité úsilí. Byly zahájeny sdílené a open source projekty s cílem vybudovat aktivity podporované komunitou za účelem zlepšení schopností Team Build.

Proces sestavení lze nakonfigurovat pro různé typy sestavení, včetně plánovaných sestavení, kontinuální integrace , brány s omezeným odbavením a postupných sestavení. Sestavení s bránou pro odhlášení uloží kód, který vývojář zapíše, provede „získání nejnovějšího“ kódu serveru a provede sestavení. Pokud je sestavení úspěšné, je kód zapsán jménem vývojáře, který kód odeslal. Pokud se sestavení nezdaří, je vývojář upozorněn a může opravit kód před pokusem o další ohlášení.

Sestavení mají zásady uchování, takže se nehromadí, když to není potřeba (nebo sestavení lze nasměrovat tak, aby neprodukovalo žádný uložený výstup) nebo že výstup sestavení lze uzamknout a uložit navždy. Novinkou v TFS 2013 je možnost zkontrolovat výsledky sestavení ve správě zdrojů. Toto bylo nezbytné vylepšení pro podporu automatizovaných sestavení ve službě Azure DevOps Services, kde neexistuje umístění pro umístění sestavení. V místní verzi lze výstup sestavení nakonfigurovat tak, aby skončil v libovolném přístupném umístění sdílené složky.

Proces sestavení v Azure DevOps je také součástí mechanismu sledovatelnosti, ve kterém Team Build spojuje mnoho artefaktů, které jsou vytvořeny a uloženy v Azure DevOps. Za předpokladu, že vývojáři přidruží zdrojový kód k pracovním položkám při check -inu, Team Build má schopnost podávat zprávy o změnách v každé sestavě - jak změny zdrojového kódu, tak změny pracovních položek, jakož i výsledky testů (to zahrnuje výsledky testování jednotek i automatizované výsledky funkčního testování (CodedUI)). Jakmile jsou chyby a PBI vyřešeny a integrovány do sestavení, pracovní položky, které tyto artefakty sledují, se automaticky aktualizují, aby bylo uvedeno, ve kterém sestavení byly úspěšně integrovány. V kombinaci s testovacími nástroji pak testeři získají integrovaný pohled na to, jaký kód byl v každé verzi změněn , ale také na to, které chyby, PBI a další práce se měnily od sestavení k sestavení.

Zpočátku, v TFS 2015 a s Visual Studio Team Services (VSTS), společnost Microsoft znovu objevila architekturu pro engine sestavení tak, aby byl založen na multiplatformní aplikaci Node.js. Agenti sestavení Windows, Mac a Linux jsou aktuálně podporováni. Azure DevOps poskytuje možnosti elastického sestavení prostřednictvím hostingu sestavení v Microsoft Azure.

Správa vydání

V polovině roku 2013 společnost Microsoft zakoupila produkt InRelease od společnosti InCycle Software. InRelease byla plně začleněna do Team Foundation Server 2013. Tato schopnost doplňovala automatizované procesy sestavování a testování tím, že umožňovala skutečné řešení nepřetržitého nasazení . Nástroje byly přejmenovány na „Release Management“ pro TFS 2013. Možnosti Release Management dávají týmům možnost provádět řízené, pracovní toky (poskytuje Windows Workflow Foundation ) řízené vydání do vývojových, testovacích a produkčních prostředí a poskytuje řídicí panely pro monitorování průběh jednoho nebo více vydání.

Společnost Microsoft přestavěla Release Management pro Visual Studio Team Services a místní verzi TFS s novými změnami v aktualizaci 2015 2. Nová verze Release Management využívá webový prohlížeč jako klienta a spoléhá na stejnou architekturu agenta jako Team Foundation Build . Release Management umožňuje funkce DevOps pro Azure DevOps.

Dějiny

Tato první verze Team Foundation Server byla vydána 17. března 2006.

Jméno výrobku	Formulář	Rok vydání	Číslo verze
Team Foundation Server 2005	On-premise	2006	8
Team Foundation Server 2008	On-premise	2008	9
Team Foundation Server 2010	On-premise	2010	10
Náhled služby Team Foundation	Mrak	2012
Team Foundation Server 2012	On-premise	2012	11
Visual Studio Online	Mrak	2013
Team Foundation Server 2013	On-premise	2013	12
Team Foundation Server 2015	On-premise	2015	14
Týmové služby Visual Studio	Mrak	2015
Team Foundation Server 2017	On-premise	2017	15
Team Foundation Server 2018	On-premise	2017	16
Služby Azure DevOps	Mrak	2018
Azure DevOps Server 2019	On-premise	2019	17
Azure DevOps Server 2020	On-premise	2020	18

Viz také

Porovnání softwaru pro správu verzí
Porovnání systémů pro sledování problémů
Microsoft Visual SourceSafe (VSS)
Seznam softwaru pro správu verzí
Racionální týmový koncert
SVNBridge , rozšíření klienta nebo serveru na straně TFS systému Windows, které umožňuje přístup k položkám řízeným revizemi TFS z klientských aplikací Subversion .
WinOps

Languages

In other projects