Witajcie w kolejnym odcinku Microsoft Knowledge Nugget tutaj na M365FM. Nazywam się Mirko Peters i jestem Waszym gospodarzem. Wdrażaliście zasoby Azure poprzez klikanie w portalu. Działa to świetnie, dopóki przestaje działać. Potem musisz to zrobić ponownie, ale nie pamiętasz dokładnie, co wybrałeś. Musisz przekazać zadanie koledze z zespołu, a on nie potrafi odtworzyć Twoich kroków. Kontrola wersji? Nie ma czego dodawać do repozytorium. To problem, który dziś rozwiążemy. Pod koniec tego odcinka zrozumiesz, czym jest infrastruktura, jako kod, dlaczego istnieje bicep i jak sprawia on, że wdrożenia Azure są prostsze i bardziej niezawodne. Zaczniemy od problemu, potem przejdziemy do rozwiązania, a następnie pokażę praktyczny przykład. Chwyć kawę i zaczynajmy. Problem portalu. Pułapka, kliknij i wdróż, wydaje się szybka. Logujesz się, wypełniasz formularz, klikasz, utwórz i gotowe. Ale co się dzieje, gdy musisz zrobić to ponownie z tymi samymi ustawieniami, regionem i konwencją nazewnictwa?

Musisz pamiętać każdą jedną rzecz, którą wybrałeś i właśnie wtedy wszystko zaczyna się sypać. Ręczne wdrażanie oznacza niespójne wyniki, błędy ludzkie i brak ścieżki audytu. Oto przykład z życia wzięty. Ktoś z twojego zespołu tworzy zasób z nieco innymi ustawieniami. Teraz masz dwa środowiska, które do siebie nie pasują. Jedno działa, drugie nie i powodzenia w szukaniu przyczyny. Do tego dochodzi problem dokumentacji. Infrastruktura opisana w dokumencie Word lub Co Gorsza na filmie z YouTube nagranym 6 miesięcy temu, gdy portal wyglądał zupełnie inaczej. Funkcje się przesuwają, menu zmienia, pojawiają się nowe opcje. Rozmawiałem z menedżerem produktu z zespołu Azure Portal i powiedział, że wypuszczają nowe funkcje dwa razy dziennie. Dwa razy dziennie. Twój dokument Word jest przestarzały, zanim jeszcze skończysz go pisać. Oto w czym rzecz. Klikanie sprawdza się przy nauce. Nie sprawdza się w produkcji.

Więc jaka jest alternatywa? Piszesz plik, który opisuje to, czego chcesz, a następnie każesz Azure to zbudować. Czym jest infrastruktura jako kod? Infrastruktura jako kod oznacza zarządzanie konfiguracją chmury za pomocą kodu zamiast przeklikiwania się przez portal webowy. Oto główna idea. Piszesz plik opisujący infrastrukturę, który znajduje się w twoim repozytorium, dzięki czemu możesz kontrolować jego wersję, recenzować go w pool requestach i uruchomić go ponownie jutro, by uzyskać ten sam wynik. Kluczowe pojęcie to deklaratywność. Oznacza to, że opisujesz, czego chcesz, a nie jak to zbudować. Nie mówisz Azure, najpierw utwórz grupę zasobów, potem dodaj konto magazynu, a następnie skonfiguruj sieć. Zamiast tego mówisz, chcę grupę zasobów z kątem magazynu i siecią skonfigurowaną w ten sposób. A Azure sam ustala kolejność. Wynikiem jest coś, co nazywamy idempotencją. Uruchom to raz, uruchom sto razy, a otrzymasz ten sam rezultat.

Na tym polega ta siła. Pomyśl o tym, jak o projekcie budowlanym w porównaniu do budowania ręcznego. Projekt jest powtarzalny, udostępnialny i można go sprawdzić. Daj go komuś innemu, a zbuduje dokładnie to samo. Obecnie istnieje kilka narzędzi, które to robią. Szablony ARM, Bicep, Terraform, Pulumi. Wszystkie realizują tę samą koncepcję na różne sposoby. To ważne rozróżnienie. Infrastruktura jako kod to sama koncepcja. Bicep to tylko jedno z narzędzi, które ją wdraża. Ale jest pewna kwestia. Azure od lat posiada język IAC o nazwie Szablony ARM. I jest powód, dla którego Microsoft stworzył nowy. Problem z szablonami ARM. Szablony ARM to oryginalny format IAC dla Azure. To pliki JSON i mają wiele zalet. Pełne pokrycie każdego zasobu Azure i ten sam silnik wdrażania, którego używa się wewnętrznie. Jeśli możesz coś stworzyć w portalu, możesz to zdefiniować w szablonie ARM. Więc w czym tkwi problem?

JSON jest świetny dla maszyn, ale fatalny dla ludzi. Pokażę Ci, co mam na myśli. Konto magazynu w szablonie ARM zajmuje około 20 linii kodu. To samo konto w bicep zajmuje około 10 linii. Wersja JSON jest mniej więcej dwukrotnie większa. A to tylko prosty zasób. Wyobraź sobie pełne wdrożenie z siecią, obliczeniami, bazami danych i regułami bezpieczeństwa. Szablon ARM staje się ścianą tekstu. Typowe problemy są przewidywalne. Brakujące przecinki, niedopasowane nawiasy, przegadane zagnieżdżenia, przez które trudno poznać, gdzie kończy się jeden zasób, a zaczyna drugi. Spędzasz więcej czasu na zmaganiach ze składnią JSON niż na definiowaniu infrastruktury. Do tego dochodzą zależności. W ARM musisz ręcznie deklarować Dependzone. Jeśli zasób, a wymaga wcześniejszego istnienia zasobu B, musisz to wyraźnie zapisać. Pomiń jeden, a wdrożenie się nie powiedzie. Powodzenia w szukaniu tego, który pominąłeś.

Jeśli kiedykolwiek próbowałeś napisać 200 liniowe pliki od SON ręcznie, wiesz, że to nie jest przyjemne. Ani trochę. Krzywa uczenia się jest stroma. Nowi członkowie zespołu mają trudności ze zrozumieniem szablonów ARM. Bariera wejścia jest wysoka. I co dzieje się w praktyce? Wiele zespołów kończy z jedną osobą, która zna szablony ARM. Ta osoba staje się pojedynczym punktem awarii. Jest jedyną, która może zmodyfikować wdrożenie i jedyną, która może je naprawić, gdy coś się zepsuje. To nie jest zrównoważone. Microsoft wysłuchał opinii i stworzył Bicep, aby naprawić dokładnie te problemy. Czym jest Bicep? Czym więc dokładnie jest Bicep? To język zaprojektowany do wdrażania zasobów Azure, będący w swojej istocie transpilatorem. Piszesz w Bicep, a kod kompiluje się do formatu ARM.json. Ten sam silnik pod spodem, ale znacznie czytelniejszy sposób pisania. Nazwa Bicep to tak naprawdę ARM w SPAC Bicep.

ARM. Mały żart wewnętrzny od Microsoftu, ale kiedy zobaczysz to w działaniu, nabiera to sensu. Bicep działa w oparciu o ARM, zamiast go zastępować. Otrzymujesz tę samą moc dzięki prostszej składni. Bicep nie zastępuje ARM, tylko na nim bazuje. Wszystko, co możesz zrobić za pomocą ARM, zrobisz też w Bicep. Każdy typ zasobu, każda wersja API, każda opcja konfiguracji, wszystko jest dostępne. Jedyną różnicą jest sposób zapisu. Składnia jest znacznie czystsza. Brak cudzysłowów przy nazwach właściwości, przecinków między nimi i nawiasów do pilnowania. Po prostu jest prościej. Porównajmy obie wersje obok siebie. Wersja ARM JSON konta magazynowego jest pełna szumu. Cudzysłowy, przecinki, nawiasy, zagnieżdżenia. Wersja Bicep zawiera te same informacje, ale jest czytelna. Możesz na nią spojrzeć i od razu zrozumieć, co robi bez przedzierania się przez warstwy składni JSON. Dużym ulepszeniem jest automatyczne wnioskowanie zależności.

W ARM musisz ręcznie deklarować Depends On. W Bicep jednak, jeśli zasób A odwołuje się do zasobu B, system automatycznie wykrywa zależność. Nie musisz tego wypisywać. Po prostu działa. Samo to pozwala zaoszczędzić godziny debugowania. Moduły to kolejna ważna część. Możesz podzielić infrastrukturę na mniejsze, wielorazowe elementy i udostępniać je w projektach. Jeden zespół tworzy moduł sieciowy, a inny z niego korzysta. Nie trzeba za każdym razem odkrywać koła na nowo. Parametry i zmienne pozwalają zdefiniować wejścia raz i używać ich wszędzie. Koniec z szukaniem i zastępowaniem zakodowanych na sztywno wartości. A interpolacja ciągów znaków oznacza, że możesz napisać prefiks storage zamiast skomplikowanych funkcji łączenia. Narzędzia to kolejny powód, dla którego tak dobrze pracuje się z bicep. Rozszerzenie VS Code oferuje IntelliSense, podświetlanie składni i sprawdzanie błędów w czasie rzeczywistym.

Szczerze mówiąc, to jedno z najlepszych rozszerzeń językowych w VS Code. Zaczynasz pisać, a ono podpowiada, co powinno być dalej. Jeśli popełnisz błąd, od razu Cię o tym informuję. Nie musisz już czekać na nieudane wdrożenie, by dowiedzieć się, że pominąłeś przecinek. Jak to zatem wygląda w praktyce? Przyjrzyjmy się, czym bicep różni się od ARM. Bicep kontra ARM, co właściwie jest inne? Porozmawiajmy o tym, co tak naprawdę zmienia się, gdy piszesz w bicep zamiast w ARM.json. Rozmiar pliku to jedna z oczywistych różnic. Pliki bicep są mniej więcej o połowę mniejsze od odpowiadających im szablonów ARM. To nie jest przesada. Usuwasz wszystkie cudzysłowy przecinki, nawiasy i standardowy kod, a zostaje tylko definicja infrastruktury. Połowa kodu, ten sam rezultat. Czytelność przychodzi naturalnie. Mniej linii, czystsza struktura i łatwiejsze zrozumienie na pierwszy rzut oka. Gdy otwierasz plik bicep, możesz go przejrzeć i zrozumieć, co jest wdrażane.

W ARM.json musisz przebijać się przez warstwy zagnieżdżeń, zanim znajdziesz właściwą konfigurację zasobów. Zależności to ogromna oszczędność czasu. W ARM ręcznie deklarujesz Depends On. Pomin jedną, a wdrożenie zakończy się niepowodzeniem. W bicep, jeśli zasób A odwołuje się do zasobu B, system obsługuje to automatycznie. Dodaję zależność w momencie kompilacji do ARM.json. Nie musisz o tym myśleć, po prostu działa. A to samo w sobie oszczędza godziny debugowania. Moduły to kolejna istotna różnica. ARM miał zagnieżdżone szablony, ale praca z nimi była uciążliwa. Osobne pliki, złożone łączenie, trudne wersjonowanie. Bicep ma moduły, które są czystsze, wersjonowalne i wielokrotnego użytku. Definiujesz moduł raz, publikujesz w rejestrze i odwołujesz się do niego z dowolnego miejsca. Ten sam moduł, ta sama konfiguracja za każdym razem. Sam proces wdrażania jest identyczny. Bicep kompiluje się do ARM.json, a potem Azure Resource Manager wdraża go.

Ten sam silnik, ten sam potok wdrażania. Nie musisz zmieniać procesu wdrażania, po prostu zmieniasz sposób pisania szablonów. What if to funkcja, którą ARM technicznie posiada, ale bicep czyni ją znacznie bardziej dostępną. Możesz podejrzeć zmiany przed wdrożeniem i zobaczyć dokładnie, co zostanie utworzone, zmodyfikowane lub usunięte. Bez niespodzianek i przypadkowych usunięć. Uruchamiasz what if, sprawdzasz wynik i jeśli wszystko wygląda dobrze, wdrażasz. Krzywa uczenia się to obszar, w którym bicep się wyróżnia. ARM.json zakłada, że wiesz, co robisz. Jest zaprojektowany dla maszyn, nie dla ludzi. Bicep jest zaprojektowany z myślą o początkujących. Intuicyjna składnia i narzędzia, które Cię prowadzą. Możesz go opanować w jedno popołudnie i stać się produktywnym do końca tygodnia. Microsoft uczynił bicep zalecanym sposobem tworzenia infrastruktury. Wszystkie nowe funkcje i ulepszenia trafiają najpierw do bicep.

Szablony ARM nadal działają i nigdzie się nie wybierają, ale prawdopodobnie nie powinieneś pisać nowych. Jeśli zaczynasz dziś nowy projekt, bicep jest właściwym wyborem. Trzy linie kodu bicep, aby wdrożyć grupę zasobów. Zaledwie trzy linie. Odpowiadający im kod ARM.json to około 15 linii. Ten sam wynik to samo wdrożenie, ale jedno jest czytelne, a drugie to chaos. Teraz możesz się zastanawiać, a co z terraformem? Uczyć się bicep czy terraforma? Bicep kontra terraform. Czego powinieneś używać? Witajcie ponownie w Microsoft Knowledge Nugget. Nazywam się Mirco Peters i dziś zajmiemy się pytaniem, które wciąż powraca. Bicep czy terraform? Przeanalizujmy to. Terraform działa w wielu chmurach. Możesz go używać do Azure, AWS, GCP, a nawet do wszystkich trzech naraz. Ta i bicep jest stworzony wyłącznie dla Azure i niczego więcej. Ta kluczowa różnica wpływa na wszystko inne. Jeśli pracujesz w wielu chmurach, terraform to właściwy wybór.

Uczysz się jednego języka, jednego narzędzia, jednego procesu i działa wszędzie. Jeśli jednak skupiasz się głównie na Azure, bicep ma spore zalety. Oto pierwsza z nich. Brak pliku stanu do zarządzania. Terraform utrzymuje plik stanu, który śledzi wdrożenia, a ten plik jest kluczowy. Jeśli zostanie uszkodzony lub straci synchronizację, masz poważny problem. Musisz go bezpiecznie przechowywać, tworzyć kopie zapasowe i zarządzać dostępem. Bicep komunikuje się bezpośrednio z Azure Resource Manager, sprawdzając, co już istnieje i wykrywając różnicę. Brak pliku stanu oznacza brak problemów z synchronizacją i ryzyka uszkodzeń. Druga zaleta – obsługa od dnia premiery. Gdy Microsoft wydaje nową funkcję Azure, bicep obsługuje ją natychmiast tego samego dnia. Terraform musi czekać na aktualizację dostawcy, co czasem trwa chwilę, a czasem tygodnie. Jeśli musisz skorzystać z nowej funkcji od razu, bicep jest jedyną opcją.

Trzecia zaleta – tworzony przez zespół Azure. Narzędzia IntelliSense i komunikaty o błędach są zaprojektowane pod kątem działania Azure. Pisząc w bicep używasz języka, który natywnie rozumie zasoby Azure. Wie, które właściwości są wymagane, jakie wartości są poprawne i jakie istnieją zależności. Taką głęboką integrację trudno powtórzyć w narzędziu zewnętrznym. Możesz też używać obu. Wiele organizacji używa bicep do platform i stref docelowych, a Terraforma do obciążeń wielochmurowych. Nie wykluczają się one wzajemnie. Możesz dobrać odpowiednie narzędzie do każdego zadania. Szczera odpowiedź jest taka. W kontekście nauki samego Azure bicep ma mniej elementów składowych. To prostsza ścieżka na początek. Nie musisz uczyć się o plikach stanu, dostawcach czy konfiguracji back-endu. Instalujesz Azure CLI, otwierasz VS Code i zaczynasz pisać. Dość teorii. Porozmawiajmy o tym, czego faktycznie potrzebujesz, by zacząć.

Rozpoczęcie pracy. Czego naprawdę potrzebujesz? Potrzebujesz dwóch rzeczy, aby zacząć. Azure CLI oraz rozszerzenie bicep dla VS Code. To wszystko. Nie trzeba instalować oddzielnego bicep CLI, ani konfigurować dodatkowych narzędzi. Azure CLI ma wbudowany bicep. Instalacja Azure CLI jest dość prosta. Wejdź na stronę Microsoft Docs. Znajdź stronę instalacji dla swojego systemu operacyjnego. Jeśli używasz Maca, wystarczy jedno polecenie. Breath Install Azure CLI. W systemie Windows dostępny jest instalator MSI. Pobierz go, uruchom i gotowe. Działa to również na Linuxie za pomocą menedżera pakietów. Po instalacji uruchom Aversion, aby sprawdzić, czy wszystko działa. Powinieneś zobaczyć wersję Azure CLI oraz wersję bicep. Teraz otwórz VS Code, przejdź do panelu rozszerzeń po lewej stronie i wyszukaj bicep. Zainstaluj wersję od Microsoftu, nie zewnętrzną, lecz oficjalną. Naprawdę potrzebujesz tego rozszerzenia?

Zapewnia IntelliSense, który podpowiada właściwości zasobów, wyróżnia składnie, dzięki czemu od razu widzisz błędy oraz sprawdza je w czasie rzeczywistym. Zobaczysz czerwone faliste linie pod błędnymi elementami, zanim spróbujesz wdrożyć kod. Szczerze mówiąc, to jedno z najlepszych rozszerzeń w VS Code i główny powód, dla którego praca z bicep jest tak przyjemna. Teraz utwórz nowy plik i nazwij go main-bicep. Rozszerzenie bicep sygnalizuje VS Code, aby się aktywowało. Bez niego piszesz zwykły tekst. Z nim zyskujesz pełne wsparcie narzędziowe. Oto krótki przykład. Wdrożenie grupy zasobów w trzech liniach kodu. Najpierw ustawiasz zakres docelowy na subskrypcję, a potem definiujesz zasób grupy zasobów z nazwą i lokalizacją. To wszystko trzy linie. Porównaj to z odpowiednikiem w Army od S.O.N., który zajmuje około 15 linii nawiasów i cudzysłowów. Aby to wdrożyć, używasz Azure CLI. Ponieważ wdrażasz na poziomie subskrypcji, polecenie to A Deployment Subcreate.

Podajesz lokalizację dla metadanych wdrożenia i wskazujesz swój plik bicep. To metoda wiersza poleceń, ale istnieje też interfejs wspomagany. W VS Code kliknij prawym przyciskiem myszy na plik bicep i wybierz Deploy Bicep File. Poprowadzi Cię przez cały proces. Zapyta o nazwę wdrożenia, poprosi o wybór subskrypcji, utworzenie lub wybór grupy zasobów oraz zapyta o plik parametrów. Odpowiadasz Nie i następuje wdrożenie. Wynik pojawi się w Twoim portalu Azure. To samo, co klikanie w portalu, ale teraz masz plik, którego możesz użyć ponownie. Możesz go dodać do swojego repozytorium, udostępnić zespołowi i uruchomić ponownie jutro. A teraz najlepsza część. Uruchom to samo wdrożenie ponownie i zobacz, co się stanie. Potęga idem potencyjności. Oto jak to wygląda przy uruchamianiu wdrożeń. Chcesz mieć możliwość uruchamiania ich wielokrotnie bez psucia czegokolwiek. Właśnie to zapewnia idem potencyjność.

Za pierwszym razem plik bicep tworzy grupę zasobów, ale za drugim razem nie dzieje się nic. Nic. Żadnego błędu, żadnych duplikatów. Nic. Bicep sprawdza, co już jest w Azure, porównuje to z Twoim żądaniem i stwierdza, że nie ma nic do zmiany. Nie próbuje tworzyć nowej grupy zasobów i nie wyrzuca błędu, że już istnieje. Po prostu potwierdza, że obecny stan jest zgodny z pożądanym. Pomyśl o tym, jak o uruchomieniu git status w czystym repozytorium. Nie ma nic do zrobienia. Wszystko jest już dokładnie tak, jak powinno być. To jest właśnie potęga infrastruktury jako kodu. Możesz uruchamiać wdrożenie wielokrotnie i za każdym razem uzyskać ten sam wynik. Bez niespodzianek, bez dryfu konfiguracji. Wiesz dokładnie, co jest wdrożone, ponieważ mówi o tym plik. Plik staje się Twoim jedynym źródłem prawdy. Nie musisz się zastanawiać, czy o czymś pamiętałeś, zmagać się z problemem U mnie działa, ani przeszukiwać portalu Azure, by sprawdzić, czy ktoś czegoś nie zmienił.

Plik mówi Ci, co tam jest. Jeśli chcesz coś zmienić, zmieniasz plik i wdrażasz ponownie. Jeśli chcesz sprawdzić stan, uruchamiasz wdrożenie ponownie, a ono potwierdza zgodność. W ten sposób budujesz zaufanie do swojej infrastruktury. Plik jest źródłem prawdy. Nie Twoja pamięć, nie dokument Word, nie film na YouTube sprzed pół roku, tylko plik. Gdzie więc bicep pasuje do szerszego obrazu Azure? Szerszy obraz, czyli gdzie pasuje bicep. Bicep żyje wewnątrz ekosystemu Azure Resource Manager. To nie jest oddzielne narzędzie. Wiele osób tak myśli, ale to tak naprawdę lepszy sposób na pisanie szablonów ARM. Pod spodem to wciąż ARM, ten sam silnik wdrożeniowy, to samo API, wszystko to samo. Jedyna różnica polega na sposobie zapisu. A ponieważ bicep kompiluje się do ARM wszystko, co działa z ARM, działa z bicep. Azure Policy egzekwuje zgodność Twoich wdrożeń. RBAC kontroluje, kto może co wdrażać.

Cost Management śledzi wydatki na Twoje zasoby. Azure DevOps i GitHub Actions wdrażają Twoje pliki bicep poprzez potoki. Wszystko to działa idealnie, ponieważ bicep tworzy standardowy kod JSON dla ARM. Nic nie tracisz na przejściu na to rozwiązanie. W rzeczywistości zyskujesz przejrzystość. Microsoft zbudował cały ekosystem wokół bicep. Azure Verified Modules, czyli AVM, to wyselekcjonowana biblioteka modułów bicep i Terraform zgodnych z najlepszymi praktykami. Nie musisz pisać wszystkiego od zera. Możesz korzystać z gotowych modułów dla typowych wzorców, takich jak sieci wirtualne, konta magazynu czy usługi aplikacji. Są one testowane, utrzymywane i zgodne z modelem Well-Architected Framework. Cloud Adoption Framework zawiera implementacje referencyjne bicep dla ustandaryzowanych architektur korporacyjnych. Jeśli budujesz strefę docelową, landing zone, istnieje do tego odpowiedni szablon bicep.

Stosy wdrożeniowe zapewniają zarządzanie cyklem życia grup zasobów. Możesz wdrożyć stos, a jeśli usuniesz zasób z pliku bicep, stos może automatycznie go usunąć lub zabezpieczyć go przed przypadkowym skasowaniem. Decyzja należy do Ciebie. Ekosystem stale się rozwija dzięki nowym modułom, lepszym narzędziom i głębszej integracji ze sztuczną inteligencją oraz GitHub Copilot. Możesz opisać swoje wymagania prostym językiem, a Copilot wygeneruje kod bicep za Ciebie. Microsoft nieustannie inwestuje w bicep jako podstawowe narzędzie do tworzenia zasobów w Azure. Dlatego nowe funkcje trafiają w pierwszej kolejności do bicep. Szablony ARM nadal działają, ale innowacje skupiają się wokół bicep. Oto główne wnioski. Jeśli pracujesz w Azure, bicep to naturalny kolejny krok po klikaniu w portalu. Nie musisz uczyć się Terraform ani zgłębiać tajników JSON w ARM. Instalujesz dwie rzeczy, piszesz kilka linii kodu i wdrażasz infrastrukturę, która jest powtarzalna, wersjonowana i niezawodna.

Pozostawię Cię z czymś praktycznym, co możesz zrobić już dziś. Wiesz już, czym jest infrastruktura jako kod, dlaczego istnieje bicep i jak upraszcza on wdrożenia w Azure. Oto najważniejsza kwestia. Bicep to nie jest inny system wdrażania. To lepszy sposób pisania tych samych szablonów ARM używający tego samego silnika i Azure Resource Manager w tle, tylko w języku zrozumiałym dla ludzi. Oto wyzwanie dla Ciebie. Utwórz plik main, bicep, wdruż grupę zasobów i uruchom to wdrożenie dwukrotnie. Zobacz, jak działa za każdym razem. Za pierwszym razem tworzy zasób, a za drugim potwierdza, że nic się nie zmieniło. To ten moment, w którym wszystko staje się jasne i zdajesz sobie sprawę, że nigdy nie wrócisz do ręcznego klikania w portalu. To jest fundament. Od tego momentu możesz dodawać konta magazynu w sieci wirtualne i usługi aplikacji używając tego samego schematu. Napisz plik, wdruż go, uruchom ponownie.

Ten plik staje się Twoim źródłem prawdy, z którego wynika wszystko inne. Jeśli uznasz to za pomocne, udostępnij materiał komuś, kto wciąż ręcznie klika w portalu. Będzie Ci wdzięczny. Zasubskrybuj na swojej ulubionej platformie podcastowej, a w następnym odcinku pójdziemy o krok dalej z bicep, wdrażając rzeczywiste zasoby z realnymi właściwościami.