Když spravujete desítky nebo stovky zařízení, mít ovladače pod kontrolou představuje zásadní rozdíl mezi stabilním prostředím a noční můrou problémů. Ruční instalace ovladačů, model po modelu, je v žádné středně velké organizaci nepraktická. Chytrým přístupem je nastavit lokální úložiště ovladačů, integrovat ho s vašimi nástroji pro nasazení a poté proces co nejvíce automatizovat.
Souběžně s tím je stále běžnější, že nasazení, kód a nástroje koexistují ve stejném pracovním postupu: repozitáře Git, řešení Visual Studia, systémové obrazy, úložiště v hypervizorech, jako je Citrix Hypervisor/XenServer atd. To vše se prolíná se správou ovladačů a potřebou nasadit obrazy a ovladače na více počítačů v síti.
Co je lokální repozitář ovladačů a jaké problémy řeší?
Lokální úložiště ovladačů je v podstatě centralizované umístění ve vaší infrastruktuře (obvykle sdílená složka na serveru), kde ukládáte všechny balíčky ovladačů, které budete používat k nasazení, údržbě a aktualizaci zařízení. Tato složka je obvykle zpřístupněna jako sdílená složka UNC (\\server\resource) a v mnoha scénářích také jako adresář přístupný přes HTTP(S) prostřednictvím webového serveru.
Toto úložiště ovladačů slouží jako jediný zdroj informací pro vaše sekvence úloh pro tvorbu obrazů, skripty nasazení, mechanismy hardwarově nezávislého zobrazování (HII) a procesy aktualizace. Namísto vkládání specifických ovladačů do každého obrazu systému (což výrazně zvyšuje počet obrazů, které je třeba spravovat) pracujete s co nejobecnějšími obrazy a delegujete na úložiště logiku, která určuje, který ovladač se má pro každé zařízení použít.
Řešení pro správu koncových bodů často používají koncept preferovaných nebo replikovaných obsahových serverů . To vám umožňuje rozhodnout, kde se fyzicky nachází úložiště ovladačů pro každé pracoviště: obvykle má každá velká kancelář server v blízkosti, aby se zabránilo tomu, aby počítače musely pro stahování ovladačů překračovat přetíženou síť WAN.
Základní požadavky pro správné fungování úložiště ovladačů
Abyste se vyhnuli problémům během instalace, musí váš repozitář splňovat několik minimálních technických požadavků . Zaprvé, cesta UNC musí být stabilní, konzistentní a správně publikovaná ve vašem nástroji pro správu. Toto stejné umístění nebo synchronizovaná replika musí být přístupná prostřednictvím adresy URL, pokud váš produkt stahuje ovladače přes HTTP(S) během předinstalace nebo z prostředí WinPE.
Jedním z kritických bodů je, že každý ovladač musí obsahovat svůj soubor .inf . Tento soubor popisuje podporovaný hardware, instalační cesty, závislosti a parametry, které Plug and Play (PnP) nebo nástroj HII používají k nalezení správného ovladače pro fyzické zařízení. Generické spustitelné soubory nebo instalační programy nestačí; bez souboru .inf se automatizace výrazně komplikuje.
Z hlediska interní organizace se důrazně doporučuje zachovat logickou strukturu podsložek (podle výrobce, modelu, typu zařízení nebo rozumné kombinace: /Dell/Laptops, /HP/Desktop, /Network, /Audio atd.). Ačkoli mnoho konzolí pro správu ovladačů prohledává rekurzivně, aniž by se na tuto strukturu spoléhalo, ušetříte si mnoho hodin a vyhnete se chybám, až přijde čas na čištění nebo provedení údržby.
Jak se generuje databáze ovladačů v repozitáři?
Jakmile jsou balíčky zkopírovány do repozitáře, začne fungovat nástroj pro správu ovladačů, který je součástí vaší sady pro správu ovladačů (často pod názvy jako „HII Driver Management“). Z této konzole transformujete jednoduchou sdílenou složku na indexovaný repozitář použitelný pro sekvence úloh.
Typický pracovní postup zahrnuje průvodce, který je přístupný prostřednictvím nabídek podobných nabídkám Nástroje > Zřizování > Správa ovladačů . Zde vyberete cestu UNC repozitáře, ověříte správnost přidružené adresy URL a zahájíte proces generování knihovny. Systém poté projde stromovou strukturou složek, přečte každý soubor .inf a vytvoří databázi (drivers.db3 nebo ekvivalent), která propojuje ID hardwaru s konkrétními ovladači.
Po dokončení vám nástroj sám zobrazí počet zpracovaných souborů a kolik z nich bylo rozpoznáno jako platné ovladače. Pokud si všimnete významného rozdílu mezi tím, co jste očekávali, a tím, co indexoval, je pravděpodobné, že chybí soubory .inf, některé soubory jsou špatně zabaleny nebo že přidáváte instalační programy, které nezpřístupňují ovladač ve standardním formátu.
Pokaždé, když do repozitáře přidáte nové balíčky, budete muset proces generování knihovny opakovat . Systém znovu analyzuje veškerý obsah a aktualizuje databázi bez ztráty předchozích položek. Je vhodné tento krok integrovat do rutiny údržby vždy, když zavádíte nové ovladače nebo významné aktualizace.
Údržba a aktualizace stávajícího repozitáře ovladačů
Úložiště ovladačů je živoucí, neustále se vyvíjející entita . Vydávají se nové modely, výrobci opravují chyby, publikují se bezpečnostní aktualizace a ovladače obecně zastarávají. Proto je zásadní definovat postup pro udržování databáze ovladačů v přiměřené aktuální podobě.
Typický proces zahrnuje stažení nejnovějších balíčků z oficiálních webových stránek , ověření, zda obsahují správně strukturované soubory .inf, a jejich zkopírování do příslušných podsložek v centrálním repozitáři. Jakmile to uděláte, vrátíte se do konzole pro správu ovladačů a znovu spusťte úlohu sestavení knihovny, abyste tyto nové funkce začlenili.
Pokud si ovladače uspořádáte podle výrobce a modelu, bude mnohem snazší odstranit starší verze , ponechat pouze doporučené ovladače nebo je segmentovat podle generace hardwaru. I když byste mohli „vše“ umístit do stejné složky a nechat nástroj, aby to spravoval, v praxi to obvykle vede k nespravovatelnému repozitáři s více duplicitními verzemi a vyšším rizikem, že Plug and Play (PnP) vybere ovladač, který jste nechtěli použít.
Použití úložiště v sekvencích úloh pro tvorbu obrázků
Nejběžnějším způsobem využití lokálního repozitáře ovladačů je jeho integrace s nasazovacími sekvencemi operačního systému . Cílem je pracovat s obrazem systému Windows, který je co nejvíce nezávislý na hardwaru, a nechat úlohy „nasazení balíčku ovladačů“ aplikovat příslušné ovladače pro systém.
V mnoha prostředích je pro celou organizaci nakonfigurována jedna sekvence obrázků a je přidáno několik kroků nasazení ovladačů . Každý krok je chráněn dotazem WMI nebo filtrem modelu, takže běží pouze na určených zařízeních. Tímto způsobem jeden pracovní postup zahrnuje notebooky, stolní počítače a pracovní stanice od různých výrobců, aniž by bylo nutné udržovat více paralelních sekvencí.
Tyto kroky čerpají přímo z repozitáře ovladačů a jeho přidružené databáze . Pořadí určuje, který balíček se má nainstalovat, a nástroj pro zřizování vyhledá potřebné ovladače v repozitáři a stáhne je prostřednictvím cesty UNC nebo HTTP(S) v závislosti na tom, zda je počítač ve fázi před instalací, zda používá WinPE nebo zda již má operační systém nainstalovaný.
Povolit uživatelům aktualizovat ovladače z portálu
V IT týmech se opakující otázkou je, zda je možné připravit posloupnost úloh sestávající pouze z kroků nasazení balíčku ovladačů a zpřístupnit ji na portálu typu Softwarového centra, aby ji uživatel mohl spustit sám, když potřebuje aktualizovat ovladače.
Z technického hlediska, pokud váš nástroj podporuje spouštění sekvencí na vyžádání a respektuje oprávnění a zásady, je nastavení proveditelné. Definovali byste sekvenci bez destruktivních kroků (bez přeformátování nebo přeinstalace systému), pouze s akcemi aktualizace ovladačů na základě balíčků, které již máte katalogizované v repozitáři.
Proces by pokračoval pomocí dotazů WMI nebo filtrů modelů, takže každý počítač by spouštěl pouze ty balíčky, které má. Rozdíl spočívá v bodě spouštění: namísto orchestrace z konzole jako součásti projektu obrazu publikujete sekvenci do jakéhosi katalogu aplikací, který uživatel spouští dle libosti nebo když mu to IT oddělení v aktualizační kampani nařídí.
Doporučuje se však opatrnost: aktualizace ovladačů na produkčních systémech může odhalit nekompatibility, které by se v čisté instalaci neobjevily. Rozumným přístupem je důkladně otestovat každý balíček , omezit tyto typy aktualizací na vysoce kontrolované systémy nebo pokročilé uživatele a jasně zdokumentovat, kdy a jak by měly být spuštěny.
Projekty ovladačů a balíčky ovladačů ve Visual Studiu
Na straně vývoje instalace ovladačů na zařízení koncových uživatelů obvykle zahrnuje projekty ovladačů ve Visual Studiu . Je důležité zde rozlišovat mezi dvěma pojmy: samotným projektem ovladače a projektem balíčku ovladače.
Projekt ovladače generuje binární soubor ovladače (obvykle soubor .sys v režimu jádra nebo jiný typ komponenty ovladače) a často odpovídající soubor INF. Tyto šablony se vytvářejí pomocí nástrojů pro vývoj ovladačů systému Windows a Visual Studio pro tento účel nabízí specifické průvodce.
Projekt balíčku ovladače funguje jako instalační kontejner : seskupuje jeden nebo více binárních souborů ovladače a všechny související soubory do jednoho „balíčku“, který bude použit k distribuci, instalaci a ladění ovladače na vzdálených počítačích. Při kompilaci takového projektu Visual Studio vygeneruje potřebnou strukturu pro standardní nasazení ovladače.
Když vytváříte řešení ovladače pomocí moderní šablony, Visual Studio obvykle automaticky generuje dva projekty : jeden pro ovladač a jeden pro balíček. Pokud z jakéhokoli důvodu vaše řešení balíček ještě neobsahuje, můžete jej přidat ručně vytvořením nového projektu, výběrem šablony „Instalační balíček ovladače systému Windows“ a zaškrtnutím možnosti jeho přidání do existujícího řešení.
Pokud vaše řešení již obsahuje balíček ovladačů, můžete jej upravit tak, aby odkazoval na jiné projekty v rámci stejného řešení. V Průzkumníku řešení otevřete projekt balíčku, přejděte k uzlu Reference a přidejte nebo odeberte odkazy na projekty ovladačů, které chcete zahrnout do finálního balíčku. Tímto způsobem může jedno řešení obsahovat více ovladačů a přidružených balíčků, což je běžná praxe v příkladech, jako je klasický „Ukázkový ovladač Toaster“.
Více repozitářů Git a pracovní postup ovladačů ve Visual Studiu
V prostředích, kde vývoj a systémy spolupracují, je velmi běžné, že skripty pro automatizaci ovladačů, nástroje pro nasazení a backendový kód jsou rozptýleny mezi více repozitářů Git. Visual Studio 2022 (počínaje verzí 17.4) tento scénář usnadňuje tím, že umožňuje pracovat až s 25 aktivními repozitáři současně v rámci stejné instance IDE.
To znamená, že si můžete otevřít komplexní řešení, které kombinuje frontend, API, knihovny, skripty pro nasazení, dokumentaci a utility , každé ve svém vlastním repozitáři, a spravovat je všechny z integrovaných zobrazení Git. Okna „Změny Gitu“ a „Repozitář Git“ jasně oddělují změny podle repozitáře a umožňují vám připravovat, potvrzovat, slučovat, přebaseovat, přejmenovávat větve a provádět další běžné operace, aniž byste ztratili přehled o tom, se kterým repozitářem pracujete.
Visual Studio si také dobře poradí se scénáři s více účty GitHub nebo smíšenými firemními a osobními repozitáři. Konfigurace Gitu pro každý repozitář si pamatuje, který účet byl použit, což výrazně zjednodušuje přístup k různým vzdáleným zařízením v závislosti na projektu. Navíc můžete vytvářet větve současně v několika souvisejících repozitářích, což je velmi užitečné při přípravě nové verze nástroje pro nasazení, která ovlivňuje více komponent.
Pokud jde o způsob načítání těchto repozitářů, můžete se rozhodnout pracovat s řešením (.sln), které seskupuje projekty z různých repozitářů, nebo otevřít kořenovou složku obsahující několik podadresářů, každý s vlastním souborem .git. V obou případech Visual Studio detekuje repozitáře a transparentně je aktivuje, čímž vám zobrazí jednotný, ale uspořádaný přehled o stavu každého z nich.
Strategie pro organizaci forků a vzdálených repozitářů
Když začnete spolupracovat na externích projektech a spravovat forky, vyvstává otázka, zda je lepší každou fork naklonovat do jiného adresáře (~/src/user1/project, ~/src/me/project), nebo pracovat s jedním kódovým stromem a několika nakonfigurovanými vzdálenými servery. Obě strategie dávají smysl v závislosti na objemu změn a typu spolupráce.
Pokud se rozhodnete pro jeden adresář, obvykle máte vzdálený server „origin“ odkazující na váš fork a další vzdálený server odkazující na původní repozitář . Poté vytvoříte větve, které podle potřeby následují po každém vzdáleném serveru. Jedná se o kompaktnější přístup, který snižuje lokální duplicitu kódu, ale vyžaduje pečlivé zvážení, který vzdálený server použijete k nahrání každé větve.
Instalace a nasazení obrazů systému Windows na více počítačích současně
Kromě úložiště ovladačů potřebuje mnoho organizací nainstalovat systém Windows na více počítačů současně se stejnou konfigurací systému, aplikacemi a ovladači. Praktickým způsobem, jak toho dosáhnout, je vytvořit referenční obraz a nasadit ho přes místní síť LAN, namísto přeinstalace každého počítače zvlášť.
Toho je dosaženo pomocí nástrojů pro zálohování a nasazení obrazů, jako jsou AOMEI Backupper a AOMEI Image Deploy . Myšlenka je velmi jednoduchá: připravíte si „hlavní“ počítač s operačním systémem, ovladači a potřebným softwarem, zobecníte systém (například pomocí nástroje Sysprep k odstranění SID a zamezení konfliktům) a poté vytvoříte kompletní obraz systému nebo disku, který je uložen na sdíleném prostředku nebo NAS přístupném všem cílovým počítačům.
Nástroj AOMEI Image Deploy umožňuje spouštět klientské počítače přes síť pomocí PXE , za předpokladu, že síťová karta tuto funkci podporuje a máte k dispozici DHCP server (nebo jej povolíte v nástroji). Na serveru vytvoříte spouštěcí prostředí WinPE, klienti se připojí, centrální konzole detekuje IP adresy každého počítače a po potvrzení vyberete soubor s obrazem, cílové disky a počet počítačů, které chcete nasadit současně.
Toto řešení výrazně zjednodušuje hromadnou instalaci systémů typu „holé železo“ : stačí připravit původní hardware, vytvořit obraz a nechat nástroj replikovat tuto konfiguraci na desítkách počítačů. Pokročilejší verze AOMEI navíc umožňují „Universal Restoration“, což znamená, že můžete stejný obraz nasadit na jiný hardware úpravou potřebných ovladačů, abyste zajistili hladký proces spouštění.
Koncept nasazení image a výhody ve společnosti
Nasazení bitové kopie zahrnuje přizpůsobení operačního systému s jeho aplikacemi, ovladači a nastavením na jednom počítači a zachycení bitové kopie tohoto stavu, která je poté automaticky distribuována do ostatních počítačů. V praxi se jedná o řízené klonování původního počítače.
Výhody jsou jasné: úspora času a úsilí , standardizovaná konfigurace a možnost rychlé instalace nově pořízených systémů. Místo trávení hodin instalací a konfigurací každé pracovní stanice nasadíte standardní bitovou kopii paralelně na více klientů a poté provedete pouze jemné doladění, které nedává smysl automatizovat.
Předpoklady pro nasazení obrazů v síti pomocí nástroje AOMEI Image Deploy
Pro hladké nasazení je nutné definovat plně funkční server Windows a jeden nebo více klientských počítačů, na které bude obraz obnoven. Je důležité, aby server a klienti byli ve stejném segmentu sítě LAN a aby klientské síťové karty podporovaly bootování PXE.
V systému BIOS klienta budete muset jako první možnost nakonfigurovat spuštění ze sítě , zajistit, aby cílové disky měly stejné logické číslování (v ideálním případě ponechat připojený pouze cílový disk), a ověřit, zda je prostředí Windows Recovery Environment (Windows RE) serveru kompletní. Pokud server používá systém starší než Windows 7 nebo prostředí WinRE nenainstalováno, budete muset nainstalovat Windows AIK/ADK a použít nástroje pro obnovení, jako je například sada Windows Boot Recovery Toolkit.
Obraz systému nebo disku se vytvoří pomocí nástroje AOMEI Backupper a uloží se na NAS nebo sdílenou složku přístupnou ze stejné lokální sítě LAN. Následně AOMEI Image Deploy vygeneruje médium WinPE, spustí potřebné služby, nabootuje klienty v síti, detekuje a přiřadí cílové disky a spustí nasazení. Proces nasazení umožňuje sledovat průběh každého počítače a po dokončení jej automaticky vypnout nebo restartovat.
Návrh a správa balíčků ovladačů ve Windows
Při diskusi o nízkoúrovňových ovladačích ve Windows je užitečné pochopit, co přesně je balíček ovladačů . Nejedná se jen o soubor .sys, ale o sadu souborů nezbytných pro instalaci zařízení: soubory INF, binární soubory, katalogy podpisů, pomocné knihovny DLL atd. Systém Windows umožňuje přidat tyto balíčky do obrazu systému před, během nebo po instalaci systému.
V offline režimu údržby můžete pomocí nástroje DISM připojit obraz systému Windows nebo Windows PE a přidávat, odebírat nebo zobrazovat balíčky ovladačů bez spuštění operačního systému. Ovladače distribuované jako soubory .cab s logem Designed for Windows obvykle vyžadují před instalací rozbalení souboru .cab; ovladače vložené do nestandardních instalačních programů lze použít pouze v online systémech, často pomocí vlastních příkazů v souborech odpovědí.
Během automatické instalace systému Windows můžete pomocí instalačního programu a souboru odpovědí bez obsluhy definovat lokální nebo síťové cesty, kde se nacházejí balíčky .inf. V závislosti na fázi konfigurace (windowsPE, offlineServicing atd.) jsou tyto balíčky integrovány do úložiště ovladačů před prvním spuštěním, což systému umožňuje mít potřebné ovladače pro spuštění nebo pro kritické komponenty, jako je úložiště a síť.
Jakmile je systém spuštěný a funkční, můžete pomocí PnPUtil přidávat nebo odebírat balíčky za chodu nebo se spolehnout na skripty a soubory odpovědí, které spouštějí instalaci v režimu auditu. Tento přístup je užitečný, když chcete udržovat velmi jednoduchý základní obraz a přidávat pouze nezbytné ovladače na základě konkrétního hardwaru, na kterém bude nasazen.
Klasifikace řadičů, digitální podpis a správa složek
Jedním běžným problémem je, že ovladač je úspěšně importován do repozitáře , ale po spuštění systému se Plug and Play (PnP) rozhodne nainstalovat jiný ovladač, který považuje za „lepší“. To je způsobeno systémem hodnocení správce PnP, který upřednostňuje ovladače na základě jejich podpisu, shody PnP ID, data a verze.
To znamená, že ovladač s kompatibilní shodou podpisu může přepsat nepodepsaný ovladač, který lépe odpovídá hardwaru na úrovni přesného ID. Je také možné, že starší verze bude mít stále přednost, pokud má shodu podpisu nebo Plug and Play, kterou systém považuje za lepší. Proto je tak důležité zkontrolovat, které verze importujete a jak se chovají v přítomnosti generických ovladačů pro Windows.
Z hlediska zabezpečení musí být balíčky ovladačů digitálně podepsány . Binární soubory spouštěcí služby v režimu jádra (kritické soubory .sys pro přístup k systémovému disku) obvykle vyžadují vložené podpisy, aby se zabránilo jejich ztrátě během aktualizací. Podepsané ovladače Plug and Play obsahují soubor katalogu (.cat) obsahující hash všech souborů balíčku a právě tento podpis systém Windows ověřuje, aby povolil instalaci.
Ve zdrojové složce je vhodné oddělit balíčky do nezávislých adresářů podle ovladače nebo kategorie , aby se předešlo kolizím názvů souborů při přidávání velkého počtu souborů .inf. Po instalaci je systém Windows interně přejmenuje na OemX.inf, ale pokud má několik balíčků stejný název souboru, mohou ve zdrojové složce vzniknout konflikty. Pokud používáte soubory odpovědí nebo DISM s cestou /recurse, všechny soubory .inf v podsložkách budou přidány do repozitáře, takže je nutné pečlivě spravovat obsah každého adresáře, abyste zabránili zahlcení obrazu zbytečnými ovladači.
Úložiště a aspekty v Citrix Hypervisor/XenServer
Ve virtualizovaných prostředích se správa ovladačů a obrazů systému často spoléhá na úložiště (SR) , kde jsou uloženy virtuální disky, šablony, ISO a další soubory. Citrix Hypervisor (dříve XenServer) nabízí širokou škálu typů SR: lokální LVM, EXT3/EXT4, NFS, SMB, GFS2, iSCSI, HBA, ISO, udev atd., každý s vlastními omezeními velikosti VDI a výkonnostními charakteristikami.
Z XenCenteru můžete použít průvodce jako „ Nové úložiště “ nebo příkazy CLI jako sr-create k definování úložišť (SR) na lokálních discích, jednotkách iSCSI LUN, polích Fibre Channel nebo sdílených složkách NFS/SMB. Každý typ SR má své vlastní parametry (zařízení, server, cesta k serveru, SCSIid, poskytovatel, cílový IQN, verze nfs atd.) a vlastní varování: maximální velikosti VDI, požadavky na velikost bloku (obvykle 512 bajtů, vyžadující emulaci při použití nativního 4K), podporu pro thin provisioning, omezení snímků a metriky, mimo jiné.
Lokální SR založené na LVM nebo HBA nabízejí stabilní výkon zápisu a rychlé klonování a operace snapshotů, ale za cenu určitých režijních nákladů a omezení. SR EXT3/EXT4 umožňují thin provisioning na lokálním úložišti, ale výkon se může během intenzivního provozu snížit. Pro sdílené úložiště poskytují NFS a SMB thin provisioning VDI ve formátu VHD, ideální pro migraci za provozu a spouštění virtuálních počítačů na jakémkoli hostiteli ve fondu, ačkoli pečlivé sledování dostupného prostoru je zásadní, aby se zabránilo selhání zápisu a pádům počítače při dosažení 100% kapacity.
Typ úložiště GFS2 se sdílenými bloky nabízí odlehčené zřizování v klastrovaných prostředích , což umožňuje VDI až do 16 TiB a vylepšenou efektivitu prostoru se sdílenými základními obrazy a četnými snapshoty. Zavádí však omezení, jako je maximální počet úložných míst (SR) GFS2, požadavek na klastrování a multipathing, nedostatečná podpora některých funkcí (CHAP, ořezávání, některé metody migrace úložiště atd.) a potřeba monitorovat využití SR, aby se zabránilo vážnému snížení výkonu.
V případě SR založených na souborech ISO (NFS nebo CIFS) se tyto používají k vytváření centralizovaných knihoven obrazů CD/DVD, ze kterých se připojují instalační programy, nástroje a distribuce systému. I zde existují specifické parametry (umístění, typ, verze, uživatelské jméno, cifpassword_secret atd.) a z důvodů zabezpečení a robustnosti se doporučuje používat SMB 3.0 namísto 1.0.
Ve všech těchto prostředích se doporučuje používat vyhrazené úložné sítě (ideálně s agregovanými linkami a redundantními přepínači), neustále sledovat volné místo a vyhýbat se ručnímu zásahu do obsahu adresářů SR na souborovém serveru, protože Citrix Hypervisor nad nimi přebírá plnou kontrolu a jakákoli externí úprava může poškodit VDI nebo metadata.
Jak vidíte, nastavení lokálního repozitáře ovladačů, jeho integrace s nasazovacími sekvencemi, jeho kombinace s řešeními pro tvorbu obrazů, jako je AOMEI, a správná správa repozitářů kódu a úložišť je sada součástí, které do sebe zapadají.
Když je vše dobře navrženo – centralizované a indexované ovladače, hotové standardní obrazy, zdravé sdílené úložiště a důsledná správa verzí v Gitu a Visual Studiu – nasazení a údržba více týmů přestává být úkolem přežití a stává se opakovatelným, sledovatelným a mnohem lépe zvládnutelným procesem. Sdílejte tuto příručku, aby se o ní mohli dozvědět i ostatní uživatelé.