Skryptowa automatyzacja może nie jest tak skomplikowanym procesem deweloperskim jak pisanie aplikacji, niemniej jednak możemy w tym celu wykorzystywać te same specjalistyczne narzędzia. Dzięki nim nawet tak proste rozwiązania jak skrypty Windows PowerShell mogą być wytwarzane w profesjonalny sposób.

W zarządzaniu infrastrukturą IT automatyzacja zadań pozwala na ustandaryzowanie przeprowadzanych prac oraz znaczne skrócenie czasu wykonywanych operacji. W środowisku systemów Windows, ale i nie tylko, jako podstawowe narzędzie do automatyzacji przyjęło się używać skryptowego języka, jakim jest Windows PowerShell.

Wspomniane skrypty PowerShella dają nam praktycznie nieograniczone możliwości kreowania własnej infrastruktury. Jednak im więcej mamy skryptów, tym trudniej nimi zarządzać. W szczególności gdy niektóre z rozwiązań mogą ciągle ewoluować, np. poprzez optymalizację kodu czy po prostu implementowanie nowych funkcjonalności. By móc łatwo odnaleźć się w omawianym środowisku skryptowym, konieczne jest wdrożenie centralnego repozytorium kodu, z poziomu którego będą przeprowadzane wszelakie zmiany deweloperskie. Dodatkowo konieczne jest zastosowanie centralnego rozwiązania do dystrybucji skryptów, tak by mogły być w łatwy sposób zaimplementowane w ramach docelowych serwerów końcowych. Takim centralnym rozwiązaniem do dystrybucji skryptów może być usługa Azure DevOps.

> AZURE DEVOPS

Usługa Azure DevOps jest narzędziem wykorzystywanym do nowoczesnego zarządzania procesami deweloperskimi. Przeznaczona jest głównie do wykorzystywania podczas tworzenia aplikacji, niemniej jednak może być również skutecznie zastosowana w mniejszej skali, np. do zarządzania własnymi skryptami. Usługa dostarcza szereg komponentów, m.in. repozytorium kodu źródłowego Git, automatyzację procesów przy wykorzystaniu Azure Pipelines czy dedykowaną przestrzeń do hostowania pakietów przeznaczonych do dalszej dystrybucji.

Przewagą wspomnianego narzędzia jest jego dostępność. Całe rozwiązanie jest zlokalizowane w chmurze usług Microsoft, dzięki czemu nie musimy implementować żadnych dodatkowych elementów wewnątrz lokalnej infrastruktury organizacji. Dodatkowo w przypadku niewielkich rozwiązań nieprzekraczających 2 GB oraz skupiających maksymalnie pięciu deweloperów z całego środowiska możemy korzystać zupełnie bez ponoszenia dodatkowych kosztów.

Aby wykreować nowe środowisko Azure DevOps, należy przejść do witryny usługi i skorzystać z opcji Rozpocznij bezpłatnie. Ostatecznie wystarczy zalogować się do usługi za pomocą służbowego lub osobistego konta Microsoftu w celu wykreowania nowej organizacji. W ramach wspomnianej organizacji usługi Azure DevOps będziemy mogli tworzyć projekty do zarządzania swoimi rozwiązaniami skryptowymi.

> ARTEFAKTY

Każdy projekt usługi Azure DevOps ma zdefiniowany zestaw komponentów do organizacji pracy deweloperskiej. Jednym z nich są artefakty (Azure Artifacts). Pozwalają one na udostępnianie pakietów, wśród których mogą znajdować się m.in. paczki typu NuGet. W przypadku omawianej prywatnej galerii skryptów jest to idealne narzędzie do centralnego składowania gotowych do dystrybucji skryptów PowerShella. Analogiczny mechanizm paczek NuGet jest również stosowany w ramach oficjalnej galerii skryptów, jaką jest PowerShell Gallery.

Domyślnie każda organizacja ma automatycznie wdrożony jeden kanał artefaktów (Artifacts Feed). Jednakże jeżeli potrzebujemy ich więcej, możemy utworzyć własne dedykowane kanały. Jest to szczególnie przydatne, gdy zamierzamy rozdzielić poszczególne skrypty, tak by konkretne rozwiązania były od siebie odseparowane, a co za tym idzie, nie były dostępne w ramach jednego docelowego repozytorium skryptów Windows PowerShell podmapowanego na końcowych serwerach. Proces tworzenia kanału artefaktów nie jest skomplikowany i został pokrótce przybliżony w ramce Krok po kroku: Tworzenie kanału artefaktów.

> PUBLIKOWANIE SKRYPTÓW

Gdy mamy już gotowy kanał artefaktów, możemy przejść do stworzenia serca całego mechanizmu, czyli centralnego repozytorium kodu źródłowego dla naszych skryptów. W tym celu wykorzystamy komponent Repos – Files usługi Azure DevOps. W jego ramach mamy do dyspozycji m.in. repozytorium Git, gdzie możemy przechowywać kod źródłowy naszych skryptów.

Przy wykorzystaniu dogodnego dla nas narzędzia deweloperskiego, np. Visual Studio Code, możemy edytować kod i docelowo synchronizować go z repozytorium w chmurze (rys. 2). Oczywiście samo zapisanie kodu źródłowego w chmurowej usłudze nie zapewni na razie automatycznego opublikowania skryptu w naszej prywatnej galerii. By było to możliwe, musimy zbudować odpowiedni przepływ. Wykorzystamy do tego komponent Azure Pipelines. W naszym testowym przypadku skupimy się na najprostszej możliwej formie przepływu, która będzie tylko budowała paczkę NuGet i ostatecznie publikowała ją w ramach wcześniej utworzonego kanału artefaktów. Zanim przejdziemy do utworzenia przepływu, musimy przygotować kilka dodatkowych elementów. Jednym z nich będzie plik manifestu przygotowywanej paczki NuGet. W tym celu w naszym repozytorium tworzymy plik z rozszerzeniem .nuspec, w którym zapisujemy przykładowy kod XML manifestu:

<?xml version=”1.0”?>
<package>
       <metadata>
               <id>$ID$</id>
               <version>$VERSIONHERE$</version>
               <authors>$AUTHORS$</authors>
               <requireLicenseAcceptance>false
</requireLicenseAcceptance>
               <description>$DESCRIPTION$
</description>
               <copyright>$COPYRIGHT$</copyright>
       </metadata>
       <files>
               <file src=”PSScripts**”/>
       </files>
</package>

Aby rozwiązanie było bardziej uniwersalne, dynamiczną zawartość manifestu możemy zdefiniować za pomocą zmiennych (np.: identyfikator, wersja, opis publikowanej paczki NuGet, autor czy informacje o prawach autorskich). Każda z nich musi być zdefiniowana w charakterystyczny sposób za pomocą znaku $. Docelowo pod każdą zmienną będą dynamicznie podstawiane dane podczas uruchamiania przepływu Azure Pipeline.

Następnie przechodzimy do drugiej kwestii, czyli zdefiniowania manifestu przepływu Azure Pipeline. Podobnie jak w przypadku manifestu paczki NuGet, tak i tutaj w ramach repozytorium tworzymy dedykowany plik, jednakże tym razem z rozszerzeniem .yml. Jako zawartość pliku azure-pipelines.yml deklarujemy kod YAML, który będzie zawierał cechy kluczowych sekcji naszego przepływu. W ramach przepływu będą definiowane następujące elementy:

• Trigger – zdefiniowanie formy wyzwalania przepływu, np. ręcznie (none) lub automatycznie po zatwierdzeniu nowych plików źródłowych w głównej gałęzi repozytorium (main);
• Variables – zmienne wykorzystywane w tworzonym przepływie. W tych elementach będą statycznie zdefiniowane wcześniej wspomniane parametry manifestu paczki NuGet. Mogą być definiowane na kilka sposobów, np. klasycznie w ramach poszczególnych wpisów w manifeście. Mogą być również zdefiniowane za pomocą dedykowanych grup zmiennych (Variable Groups) deklarowanych w ramach biblioteki (Library) projektu.
• Pool – określenie puli agentów, w ramach której będzie uruchamiany przepływ. Ze względu na to, że natywnym środowiskiem skryptów PowerShell są systemy z rodziny Windows, w naszym testowym przypadku wykorzystamy pulę agentów windows-latest;
• Stages/Jobs – docelowe etapy i zadania wykonywane w ramach przepływu. W naszym przypadku będą to dwie komendy narzędzia NuGet, czyli Pack oraz Push.

[...]

Autor ma wieloletnie doświadczenie w administracji oraz implementowaniu nowych technologii w infrastrukturze serwerowej. Pasjonat technologii Microsoft. Posiada tytuł MVP Cloud and Datacenter Management.