WinGet и YAML файлове за конфигуриране на вашия компютър като професионалист

Ако всеки път, когато получавате ново оборудване, трябва да прекарвате часове Инсталиране на програми, настройване на Windows и настройване на вашата среда за разработкаВреме е за опростяване. WinGet и YAML файловете ви позволяват да превърнете целия този тромав процес в практически автоматичен, който можете да повторите на всеки компютър с една единствена команда.

Идеята е да опишете в конфигурационен файл какво искате да се инсталира и как трябва да бъде конфигурирана системата ви, след което да го оставите Мениджър на пакети на Windows (winget) заедно с конфигурация на желаното състояние на PowerShell (DSC) Вършете мръсната работа: инсталирайте софтуер, приложете настройки, стартирайте скриптове и проверете дали машината ви е в точното състояние, за да можете да работите, без да губите време.

Какво е WinGet и защо е толкова полезен за автоматизиране на вашия компютър?

WinGet е официалният мениджър на пакети на Microsoft за Windows 10 и Windows 11.Работи от командния ред и ви позволява да инсталирате, актуализирате, конфигурирате и деинсталирате приложения по начин, много подобен на този, който се прави в GNU/Linux с apt, dnf или подобен, но перфектно интегриран в екосистемата на Windows.

Вместо да търсите инсталатори в стотици уебсайтове, да изтегляте EXE или MSI файлове и да кликвате върху „Следващ, следващ, приемам“, с WinGet можете да стартирате команда като име на пакет за инсталиране на winget След това системата изтегля програмата от надежден източник, извършва тиха инсталация и регистрира пакета за бъдещи актуализации.

Основните източници на софтуер, които WinGet използва, са Microsoft Store и хранилището на общността, хоствано в GitHubкъдето всяко приложение е описано от YAML манифест, който указва как да се инсталира, неговата версия, хеш за целостта и т.н. Освен това е възможно да се добавят частни хранилища, като например такова за вашата организация, за да се разпространява вътрешен софтуер по контролиран начин.

Цялата екосистема на WinGet се основава на три стълба:

La CLI крило (командата, която използвате в терминала).
Лос услуги, които хостват и валидират пакети.
Лос YAML конфигурационни файлове които ви позволяват декларативно да дефинирате желаното състояние на цяла машина, а не само на отделни приложения.

Основни WinGet команди за управление на приложения

Преди да се задълбочим в техническите аспекти на YAML конфигурационните файлове, е полезно да разберем основите. основни WinGet команди за ежедневна употребаВсичко се управлява от PowerShell, Windows Terminal или класическия команден ред.

Ако просто пишете WinGet В конзолата ще видите инсталираната версия, наличните подкоманди и обобщение на опциите. Оттам можете да започнете да експериментирате без страх.

за инсталиране на приложение Използвате подкомандата install. Например, за да инсталирате Visual Studio Code на вашия компютър, просто трябва да направите:

winget install Microsoft.VisualStudioCode

В този случай, Microsoft.VisualStudioCode е точният идентификатор на пакета в хранилището на WinGet. В много случаи можете да инсталирате и с името точно както е показано в магазина, в кавички, ако има интервали, но използването на ID намалява неяснотата.

Ако искате актуализирайте програмите сиМожете да помолите WinGet да опита да качи всичко, което разпознава, с:

winget upgrade --all

Или можете да се съсредоточите върху конкретно приложение, например:

winget upgrade Microsoft.VisualStudioCode

Съвременните версии на WinGet могат да актуализират не само това, което са инсталирали сами, но и приложенията, които откриват в системата и които имат свързан манифест в произхода си.

за деинсталирайте софтуераМеханиката е също толкова проста:

winget uninstall Microsoft.VisualStudioCode

Премахването ще работи, стига WinGet да има програмата картографирана в каталога си, било то защото я е инсталирал, било защото я разпознава чрез информация, регистрирана в системата.

Когато трябва да намерите програма, можете да използвате Търсене на крилаНапример, за да видите какви опции за бележник са налични:

winget search notepad

Командата ще върне списък с име, идентификатор на пакета и произход (общностно хранилище, магазин или частно хранилище) и този идентификатор е този, който трябва да използвате при инсталиране или надграждане, за да сте сигурни.

Ако искате да знаете кой софтуер контролира WinGet на вашия компютър, можете да използвате:

winget list

С това ще получите инвентаризация на приложенията, открити от мениджъра на пакети. Много полезно за вземане на решение какво да актуализирате или какво да включите в конфигурационните си файлове.

Автоматизиране на инсталации с YAML файлове: красотата на всичко това

Наистина интересната част идва, когато преминете от въвеждане на команди една по една към Опишете идеалната си среда в един YAML файлВместо да имате списък с команди или крехък скрипт, вие декларативно определяте как искате машината да изглежда и делегирате работата на WinGet и DSC.

Конфигурационният файл на WinGet съдържа списъкът с пакети, версии, инструменти, скриптове и системни настройки от които се нуждаете за вашата среда за разработка (или за цялата компания). Не се ограничава само до инсталиране на програми: може да активира функции на Windows, да променя системния регистър, да управлява услуги, да стартира PowerShell скриптове… Всичко необходимо, за да приведе компютъра в определено състояние.

За да работи това, трябва да имате достатъчно скорошна версия на WinGet, по-специално v1.6.2631 или по-висока версияТова е моментът, в който интеграцията с DSC 3.0 и командата winget configure, отговорна за обработката на конфигурационните файлове на YAML, се въвеждат по стабилен начин.

Предимството е, че процесът става без надзор и повтаряемостИзпълнявате команда, приемате необходимите споразумения и можете да отидете да пиете кафе, докато системата инсталира всичко необходимо, настройва Windows, конфигурира вашите IDE и подготвя средата за употреба. И ако утре смените компютъра, просто повтаряте процеса и сте готови.

Освен това, тези файлове могат запазете го в Git хранилище, OneDrive или където пожелаете, споделяйте с екипа си промени във версиите, отворени проблеми и заявки за изтегляне… Накратко, третирайте конфигурацията на вашата машина като код (IaC), а не като нещо ръчно и неповторимо.

Командата за конфигуриране на winget и нейните основни опции

Входът към цялата декларативна система е командата конфигурация на крилото. Това е отговорно за четенето на конфигурационния файл на WinGet, проверката дали е правилен, изтеглянето на необходимите PowerShell модули и прилагането на промените.

Преди да се потопите, препоръчително е активиране на компоненти за конфигурация (ако вече не са активни) с:

winget configure --enable

След като това е направено, най-разумното нещо, което можете да направите, е да започнете с валидиране на YAML файла с командата:

winget configure validate -f ruta\a\archivo.winget

Валидацията проверява и двете YAML синтаксис като съответствие със схемата JSON официална конфигурация. Имайте предвид, че YAML е чувствителен към отстъпи (интервали, а не табулации), така че редактирането на тези файлове във Visual Studio Code с разширението Red Hat YAML и свързаната схема WinGet е почти задължително, за да избегнете преекспониране.

Когато всичко изглежда добре, можеш Приложете настройките сериозно с:

winget configure --file ruta\a\archivo.winget --accept-configuration-agreements

В този момент, конфигурационният процесор влиза в действие, интерпретирайки YAML, изтегляйки всички липсващи DSC модули от галерията на PowerShell и започвайки да изпълнява твърдения и ресурси. Задачите, които го позволяват, се изпълняват паралелно. Тези, които изискват права на администратор ще задейства предупреждение от UAC при изстрелване за височина.

Ако предпочитате да направите „сух тест“, преди да промените нещо, можете да използвате:

winget configure test -f ruta\a\archivo.winget --accept-configuration-agreements

С теста, WinGet оценява системата, като я сравнява с желаното състояние, описано във файла и То ви казва кои неща не се връзват.без дори да докосвате машината. Това е много полезно за настройване на сложни настройки и гарантиране, че няма да има изненади при прилагането на файла.

Възможно е също така да работите с отдалечени файлове, например хоствани в публично или частно хранилище, като изпълните нещо подобно:

winget configure --accept-configuration-agreements --disable-interactivity -f https://tu-servidor/tu-config.winget

Този метод на употреба е много подходящ за сценарии на масово внедряване или централизирано администриранекъдето ИТ отделът публикува конфигурация и потребителите или скриптовете трябва само да изпълнят команда, за да оставят корпоративния компютър с дефинирания стандарт.

Аргументи, опции и подкоманди на winget configure

Подкомандата configure поддържа редица параметри за фина настройка на поведениетоНякои от най-подходящите са:

-f, –файл. Път до конфигурационния файл на WinGet, който ще бъде приложен.
–модулен-път. Локална папка, където ще се съхраняват изтеглените DSC модули (по подразбиране в %LOCALAPPDATA%\Microsoft\WinGet\Configuration\Modules).
–път на процесора. Местоположение на процесор за персонализирана конфигурация, ако е приложимо.
–accept-configuration-agreements. Приемете предварително предупреждението за конфигурация, за да избегнете интерактивно известие.
–потискане-началните-детайлности. Опитайте да скриете първоначалните подробности за настройката за по-чист резултат.
–активиране / –деактивиране. Активиране или деактивиране на компонентите за конфигурация (изисква достъп до магазина).
–логове, –отворени-логове. Отворете папката, където се съхраняват конфигурационните лог файлове.
–подробно, –подробни-логове. Позволява подробно регистриране за отстраняване на неизправности.
–nowarn, –ignore-warnings. Потискайте предупредителните съобщения при изход.
–деактивиране на интерактивността. Това предотвратява всякакъв вид интерактивни подкани, идеални за скриптове без надзор.
–прокси / –не-прокси. Това ви позволява да дефинирате прокси за това конкретно изпълнение или да деактивирате използването на прокси.

В допълнение към основната команда, Командата за конфигуриране на winget има няколко подкоманди Какво трябва да знаете:

конфигуриране на крилце показване -f . Показва подробности за конкретен конфигурационен файл, полезно за проверката му, без да се отваря в редактор.
списък с конфигурации на крила. Показва обобщение на конфигурациите, които са били приложени към системата, което помага да се следи какво е било изпълнено.
тест за конфигуриране на крило -f . Режим на проверка, който сравнява текущото състояние на системата с това, дефинирано в конфигурацията.
конфигуриране на крило валидиране -f . Валидирайте само файла, без да докосвате машината.
winget конфигуриране на експортиране -o . Позволява експортиране на конфигурационни ресурси във файл, независимо дали става въпрос за всички конфигурации на пакети (--all), специфичен пакет (--package-id) или специфичен ресурс (--module y --resource), добавяйки към изходния файл, ако той вече съществува.

Формат и конвенция за именуване на конфигурационния файл на WinGet

Използване на конфигурационните файлове на WinGet YAML формат със свързана JSON схема което определя валидната структура. Собствената система за манифести на WinGet също е базирана на YAML. Така че всичко се вписва в един и същ модел.

По конвенция тези файлове се запазват с разширението .крилце, например configuration.wingetВ проекти, използващи Git, обикновено се препоръчва да се съхраняват в скрита директория. .configоставяйки маршрути като ./.config/configuration.winget за конфигурацията „по подразбиране“ на проекта.

Ако вашият проект използва различни комбинации от инструменти или предпочитания, можете да съхранявате няколко конфигурационни файла в една и съща папка, всеки с описателно име, което показва коя среда използва (например, frontend.winget, backend.wingetИ т.н.).

Първият ред на файла обикновено е специален коментар, който уведомява редакторите коя JSON схема да използват. Обикновено изглежда така:

# yaml-language-server: $schema=https://aka.ms/configuration-dsc-schema/0.2

В основната посока https://aka.ms/configuration-dsc-schema/ Можете да проверите най-новата версия на схемата и да актуализирате файла си, когато Microsoft пусне нови редакции с повече възможности.

След този заглавен файл, коренният възел на документа винаги е свойствакоето трябва да включва поле configurationVersion (например 0.2.0) и двата основни раздела, които структурират всичко: assertions y resources.

Структура на конфигурационен файл: свойства, твърдения и ресурси

Под възела свойства От една страна се декларира, че версия на конфигурациятакоето трябва да увеличите с развитието на файла, а от друга страна колекциите assertions y resources които описват поведението.

раздел твърдения. Това обхваща твърденията или предварителните условия, които трябва да бъдат изпълнени, за да бъдат определени ресурси значими: минимална версия на Windows, наличие на определена функция и т.н. Те не са действия сами по себе си, а по-скоро проверки на средата.
раздел ресурси. Той събира всички конфигурационни ресурси, които възнамерявате да приложите: инсталации на софтуер, системни настройки, скриптове, управление на услуги, промени в системния регистър и др. Всеки елемент в тези списъци е представен от възел от тип resource с необходимата информация.

И в двата случая, Всеки запис е дефиниран чрез посочване на DSC ресурса, който ще се използва., с формата {NombreModulo}/{NombreRecursoDSC}, Например, Microsoft.Windows.Settings/WindowsSettings да докоснете настройките на Windows или Microsoft.WinGet.DSC/WinGetPackage за да инсталирате WinGet пакет от DSC.

Наред с полето за ресурси, всяка единица обикновено включва раздели от директиви и настройки, незадължителен идентификатор id и, когато е необходимо, списък със зависимости dependsOn към други ресурси или твърдения.

Твърдения: Проверете версията на Windows и други предварителни изисквания

на Твърденията действат като предварителни филтри които решават дали има смисъл да се изпълняват определени ресурси на текущата машина. По този начин не се опитвате да инсталирате или конфигурирате нещо на система, която не отговаря на основните изисквания.

Типичен пример е проверката на минимална версия на операционната системаМного конфигурации изискват поне Windows 10 1809 или специфична компилация на Windows 11 и е безсмислено да продължавате, ако сте на по-стара версия, която дори не поддържа WinGet.

Твърдението на този стил използва DSC ресурси като например Microsoft.Windows.Developer/OsVersion, което показва свойство чрез настройки Мин. версия (например „10.0.22000“), който определя приемливия праг за конфигурацията.

Твърденията могат оценяват паралелнобез строг ред и по същество връщат състояние true или false. Ако твърдението върне false (не е изпълнено), всеки ресурс, който го включва като зависимост чрез dependsOn Ще бъде автоматично пропуснато.

Това поведение се счита за правилен резултат от гледна точка на декларативната система: по-добре е да се пропусне блок, който няма смисъл, отколкото да се наложи изпълнението му в неподходяща среда. Изходните съобщения може да показват нещо като „Ресурс не беше изпълнен, защото твърдение е неуспешно или е невярно“.

Дори ако някои от настройките не са приложими, WinGet все пак ще се опита да ги приложи. продължете с други независими ресурси за да приведете системата възможно най-близо до желаното състояние. В крайна сметка вие носите отговорност за прегледа на грешките и за вземането на решение дали да промените конфигурацията или средата.

Ресурси: Инсталиране на пакети, настройване на Windows и стартиране на скриптове

раздел ресурсите са практическото сърце на конфигурационния файлТук изброявате всичко, което искате да се случи на машината: инсталиране на софтуер, промени в системната конфигурация, изпълнение на PowerShell скриптове, управление на услуги и др.

Всеки ресурс е дефиниран с поле resource който следва формата Modulo/RecursoDSC, например Microsoft.Windows.Settings/WindowsSettings за активиране на системни функции или Microsoft.WinGet.DSC/WinGetPackage да се организира инсталирането на пакет чрез WinGet от DSC.

По желание можете да зададете уникален идентификатор което ще ви помогне да го препратите от dependsOn в други ресурси. Това е много полезно, когато искате например конфигурацията на допълнителни компоненти на Visual Studio изрично да зависи от предварителното инсталиране на самото Visual Studio.

Във всеки ресурс, разделът директивите съдържат контекстуална информация за това как трябва да се изпълни: текстово описание на задачата (description), ако модулите за предварителен преглед са приети от галерията на PowerShell (allowPrerelease) и на securityContext което показва дали изпълнението изисква повишени привилегии.

Когато сложите Контекст на сигурността: повишенWinGet ще поиска администраторски права веднъж в началото на настройката и оттогава нататък ще може да изпълнява ресурси с и без повишени права, използвайки различни процеси, без да ви бомбардира с още прозорци за контрол на потребителския контрол (UAC).

раздел настройките определят двойките име-стойност които се предават на DSC ресурса. Може да бъде нещо толкова просто, като DeveloperMode: true за активиране на режима за разработчици на Windows или по-сложни параметри, като например id y source от WinGet пакет, пътя до .vsconfig файл, конкретна стойност в системния регистър или подробностите за услуга, която трябва да бъде активирана.

Накрая, полето зависи от Това ви позволява да декларирате, че този ресурс трябва да се изпълнява само когато определени предходни твърдения или ресурси са успешно завършени. Ако една от тези зависимости се провали, ресурсът автоматично се маркира като неизпълнен или неуспешен, предотвратявайки нежелани странични ефекти.

Организирайте секцията с ресурси по четим начин

В големи проекти конфигурационните файлове могат да станат доста големи, така че си струва да отделите време за това. Помислете малко как организирате секцията с ресурси така че да остане поддържаем във времето.

Често срещана стратегия е да се организират ресурсите според логически ред на изпълнение:

Първо, какво подготвя системата (твърдения, основни актуализации).
След това общи инструменти (браузъри, компресори, помощни програми).
След това IDE и SDK.
Накрая, по-специфични скриптове или настройки.

Друг интересен подход е да ги групирате по вероятност за неуспех или сложностС други думи, поставете задачите, които най-често се провалят (тежки инсталации, които зависят от добра връзка или идентификационни данни), в началото, така че потребителят да осъзнае рано, че нещо не е наред, без да чака всичко да приключи.

Много хора предпочитат да групират по вид ресурсПърво, пакетът WinGet, след това конфигурациите на Windows (регистър, функции, услуги), след това скриптове и накрая, инструменти, специфични за конкретен проект. Този стил често наподобява типичната структура на софтуерен проект и ви помага бързо да се ориентирате.

Каквито и да са критериите, силно се препоръчва файлът да бъде придружен от README файла в хранилището обяснение на структурата на конфигурацията, ключовите зависимости, минималните необходими версии на Windows и препоръчителните стъпки за изпълнение.

Тази документация го прави така, че Други разработчици могат да допринесат за архива с по-малък риск. да нарушат нещо, тъй като те по-добре разбират какво прави всеки блок и какви твърдения или зависимости са в действие, преди да добавят нов ресурс.

Използване на променливата ${WinGetConfigRoot} в пътищата до файловете

Много DSC ресурси приемат параметри, които очакват пътища до конкретни файловеКонфигурации, скриптове, шаблони и др. на Visual Studio. Ако използвате абсолютни пътища, файлът ви губи преносимост веднага щом промените потребители, устройства или папки.

За да предотврати това, WinGet въвежда променливата ${WinGetConfigRoot}, което сочи към директорията, от която се изпълнява winget configureОттам можете да изградите относителни пътища, които ще работят по един и същ начин на всеки компютър, където се спазва същата структура на папките.

Ако например запазите конфигурационния файл в .config/configuration.winget и файла .vsconfig В корена на хранилището можете да използвате път като '${WinGetConfigRoot}\..\.vsconfig'Частта .. Качете се едно ниво нагоре от работната папка и ще бъдете преместени директно в директорията, където се намира .vsconfig.

Тази техника го прави така, че една и съща конфигурация е валидна за всички членове на екипа които клонират проекта към различни пътища, стига да спазват относителното разположение на файловете в хранилището.

Въпреки това, струва си да се помни в README файла, че Потребителят трябва да се увери, че целевият файл съществува. в относителния път, който очаква конфигурацията преди стартиране на winget configure, или изпълнението ще сигнализира за грешки в тези ресурси.

Къде да намерите DSC модули и готови за употреба ресурси

За да работи цялата тази система, WinGet разчита на PowerShell модули, които имплементират DSC ресурсиНякои идват „по подразбиране“ със самата система (т. нар. ресурси на входящата кутия), а други се получават от галерията на PowerShell.

Сред стандартните ресурси имате модули за управление променливи на средата, инсталиране или деинсталиране на MSI пакети (msiPackage), манипулиране на ключове и стойности в системния регистър (Registry), изпълнение на скриптови блокове (Script), управление на услуги на Windows (Service), добавяне или премахване на роли и функции (WindowsFeature) или стартиране и спиране на процеси (WindowsProcess).

La Галерията на PowerShell съдържа стотици допълнителни модули с DSC ресурси, предоставени от общността. Можете да използвате филтрите за търсене, за да показвате само тези, маркирани като „DSC ресурс“ и по този начин да намирате части за многократна употреба за вашите конфигурации.

Важно е обаче да се има предвид, че галерията не е напълно одитирана среда: Всеки може да публикува модулиа някои може да включват рискови или откровено злонамерени скриптове, ако не бъдат внимателно прегледани.

Поради тази причина Microsoft настоява, че произход и съдържание на модулите преди да ги използвате в конфигурации, които ще работят на производствени машини, особено ако тези ресурси работят с висок контекст на сигурност.

За да видите конкретни примери за конфигурационни файлове, Microsoft поддържа Хранилище за конфигурации на DSC WinGet и YAML достъпен чрез краткия линк https://aka.ms/dsc.yaml, където можете да намерите вдъхновение и да използвате вече тествани шаблони като основа.

Политики за сигурност, доверие и групови политики, свързани с WinGet

Тъй като WinGet и DSC могат инсталиране и конфигуриране на софтуер на едроАспектът на сигурността е от основно значение, особено в корпоративни среди, където има доста строги изисквания за съответствие.

WinGet се интегрира с Microsoft Store чрез Origin msstore и използва техники на закрепване на сертификат да провери дали HTTPS сертификатът на магазина съответства на един от известните сертификати и по този начин да предотврати атаки от типа „човек по средата“ (MITM).

В организации, които използват защитни стени с SSL инспекция, това поведение може да причини проблеми, ако устройството за сигурност преопакова връзката със собствен сертификат. За такива случаи има политика, наречена Заобикаляне на сертификата за закрепване на Microsoft Store което ви позволява да укажете дали WinGet трябва да пропусне тази проверка.

Възможните опции включват оставяне на политиката неконфигурирана (спазвайки препоръчителното поведение по подразбиране), активирането ѝ, така че WinGet Не валидирайте сертификата на магазина или изрично го деактивирайте, за да го принудите да приема само известни сертификати на Microsoft.

Деактивиране на закотвянето на сертификата увеличава риска от атаки „човек по средата“Следователно, това трябва да се прави само с пълно познаване на фактите и когато няма разумна алтернатива, да се впише в цялостна стратегия за сигурност.

В допълнение към тази директива има специфични за WinGet шаблони за групови правила (.admx и .adml файлове), които позволяват на администраторите контролирайте разрешени или блокирани източници, активирайте или деактивирайте експериментални функции, дефинирайте поведението към прокси сървъри и като цяло оформят начина, по който мениджърът на пакети се държи в организацията.

Тези шаблони се разпространяват в пакета DesktopAppInstallerPolicies.zip в хранилището на WinGet в GitHub. След разархивиране, файловете се копират в C:\Windows\PolicyDefinitions Съответната папка с езици вече е налична, така че може да се управлява от конзолата за управление на групови политики.

Съществуват и обекти на групови правила, като например EnableWindowsPackageManagerConfiguration и EnableWindowsPackageManagerConfigurationExplanation които позволяват блокиране на използването на конфигурационни файлове на WinGet в цялата организация, в случай че се прецени, че тази функционалност трябва да бъде строго ограничена.

Допълнителни хранилища и използване на частни източници в WinGet

WinGet използва следните основни източници веднага щом е готов за употреба: Microsoft Store и хранилището на общността в GitHubкъдето можете да намерите манифести за множество популярни програми: браузъри, пакети за разработка, инструменти за дизайн, различни помощни програми и др.

Много компании обаче се нуждаят от нещо повече: частни хранилища, където можете да хоствате свои собствени приложения, вътрешни пакети, валидирани версии на определени инструменти или филтрирани каталози, които отговарят на техните политики.

WinGet ви позволява да регистрирате допълнителни източници, използвайки командата:

winget source add --name <nombre_del_repositorio> --arg <URL_del_repositorio>

Тозият произход обикновено е от тип REST по подразбиране, въпреки че можете да го укажете с --type Ако имате нужда от това. Освен това има параметри като например – ниво на доверие да се определи нивото на доверие (няма или надеждно) и –accept-source-agreements автоматично приемане на лицензионните споразумения за изходния код, което е от съществено значение при автоматизиране на включването на хранилища.

За да проверите кои шрифтове имате на компютъра си в момента, можете да изпълните:

winget source list

Тази команда връща всички налични източници с тяхното име и тип. От този момент нататък, търсенията и инсталациите на WinGet ще вземат предвид допълнителните хранилища според конфигурираните от вас настройки.

Има проекти, които предлагат Готови за внедряване решения за частни WinGet хранилища в Azure или локални инсталации, използващи Docker, което предлага значителна гъвкавост при настройване на корпоративни каталози или контролирани среди, където съществува само одобрен от ИТ специалистите софтуер.

На практика, комбинирането на частни хранилища с добре проектирани YAML конфигурационни файлове позволява напълно стандартизирайте конфигурацията на софтуера и оборудването на компания, със спокойствието, че всичко произлиза от произход, който вие сами контролирате.

С всичко горепосочено, WinGet, неговите YAML конфигурационни файлове и DSC ресурсите превръщат досадната задача по подготовката и поддръжката на Windows компютри в процес. много по-бързо, повторяемо и по-безопасноНезависимо дали сте разработчик, който иска да клонира средата си на множество компютри, или управлявате парк от компютри в организация и искате да спрете да правите всичко ръчно.