Latest / M365.FM – podcast o Microsoft 365, Copilot i AI po polsku / ALM w Power Platform z GitHub Actions: źródło, build, test i wdrożenie bez zgadywania (Dubbing AI)

Transcript

ALM w Power Platform z GitHub Actions: źródło, build, test i wdrożenie bez zgadywania (Dubbing AI) · M365.FM – podcast o Microsoft 365, Copilot i AI po polsku

• 0:00
  Gotowi na 10 dni z Microsoft 365, Copilot, AI, Azure oraz ludźmi, którzy kształtują przyszłość pracy?
• 0:07
  W styczniu wraca M365Con, a tym razem mierzymy jeszcze wyżej.
• 0:12
  Dołącz do nas na sesję na żywo pokazy praktyczne i zdobądź wiedzę od MVP oraz ekspertów z całego świata.
• 0:18
  Żadnych ogólnych slajdów, żadnego natłoku pustych haseł.
• 0:22
  Zajmujemy się prawdziwymi wyzwaniami, Copilot Studio agentami, AI, Fabrik, bezpieczeństwem, ładem i automatyzacją.
• 0:28
  Niezależnie od tego, czy jesteś informatykiem, programistą czy liderem biznesowym, mamy sesje stworzone z myślą o Tobie.
• 0:35
  Podczas 10 pełnych dni poznasz różne technologie i nawiążesz kontakty z globalną społecznością.
• 0:40
  Oglądaj na żywo i zabierz praktyczne wnioski do swojej organizacji.
• 0:44
  Styczeń 2027 roku, 10 dni, jedna społeczność Microsoft. Rejestracja jest już otwarta.
• 0:52
  Zarezerwuj swoje miejsce już dziś.
• 0:54
  Adres to m365.con.net
• 0:59
  Dołącz teraz na m365.con.net.
• 1:03
  Widzimy się na żywo w styczniu.
• 1:04
  Czy masz wrażenie, że Twoje wdrożenia w Power Platform to czarna skrzynka?
• 1:08
  Wysyłasz aktualizację, wstrzymujesz oddech i masz nadzieję, że zadziała w środowiskach dev, test i prod?
• 1:13
  Co jeśli mógłbyś kontrolować i widzieć każdy etap procesu ALM za pomocą GitHub Actions bez zgadywania i ręcznych poprawek?
• 1:22
  Odsłońmy kulisy tego, jak łączą się komponenty, kontrola wersji, automatyzacja i bezpieczne zmienne.
• 1:28
  To nie jest kolejna zwykła instrukcja.
• 1:30
  To wyjaśnienie, dlaczego, które pomijają inne przewodniki, aby kolejne wdrożenie nie pozostawiało niewiadomych.
• 1:35
  Dlaczego więc ALM w Power Platform przypomina labirynt?
• 1:38
  Jeśli kiedykolwiek próbowałeś wdrożyć Power App i czułeś niepokój, że coś ważnego mogło umknąć, nie jesteś sam.
• 1:46
  Na papierze Power Platform obiecuje łatwe tworzenie aplikacji, ale pod tą przyjazną otoczką ALM jest wszystkim, tylko nieprostotą.
• 1:53
  Aplikacja internetowa wdraża się z repozytorium, buduje w potoku i trafia na produkcję w przewidywalny sposób.
• 1:59
  Power Platform natomiast ukrywa połowę logiki w interfejsach typu
• 2:03
  Przeciągnij i upuść ekranach konektorów i formułach, których nie widać w żadnym repozytorium Git.
• 2:08
  Dlatego nawet jeśli śledzisz każdy krok z ogólnych przewodników, napotykasz dziwne, trudne do zdiagnozowania awarie, gdy biznesowe aplikacje opuszczają fazę rozwoju.
• 2:17
  Przyjrzyjmy się dostępnym poradnikom dotyczącym ALM.
• 2:20
  Większość z nich przeprowadzi Cię przez eksportowanie pliku zip rozwiązania i importowanie go gdzie indziej.
• 2:24
  Wydaje się proste, prawda?
• 2:25
  Ale to jak to tylko jedna warstwa.
• 2:27
  To, co pomijają, to dlaczego?
• 2:29
  Dlaczego wdrożenia Power Platform psują się w sposób, w jaki zwykły kod nigdy się nie psuje?
• 2:33
  To właśnie powoduje niekończące się zamieszanie.
• 2:35
  U źródła problemu leży to, że logika, połączenia i konfiguracja w Power Apps nie są przechowywane jak klasyczny kod.
• 2:42
  Nie chodzi tylko o sklonowanie repozytorium i obserwowanie testów jednostkowych.
• 2:45
  Kiedy więc próbujesz przenieść aplikację, wszystkie te ukryte zależności połączenia z Outlookiem, SharePointem czy własnymi API nie zawsze przenoszą się gładko w tym pliku zip.
• 2:54
  Oto scenariusz.
• 2:55
  Masz nową, świetnie działającą aplikację w środowisku deweloperskim.
• 2:58
  Eksportujesz rozwiązanie, importujesz do testowego i nagle przepływ przestaje działać.
• 3:01
  Rzadko jest to problem związany tylko z plikiem.
• 3:04
  Zamiast tego połączenia wskazują na złe miejsce, uprawnienia się nie zgadzają, a polityki danych blokują połączenia, które jeszcze przed chwilą wydawały się poprawne.
• 3:12
  Wyobraź sobie teraz robienie tego w trzech środowiskach, dev, test i prod, gdzie każdy używa innych połączeń, polityk ochrony danych zatwierdzających i zabezpieczeń administratora.
• 3:22
  Nie da się tego po prostu przekopiować.
• 3:23
  Badania potwierdzają to, co administratorzy i twórcy widzą co tydzień.
• 3:27
  Większość nieudanych wdrożeń Power Platform wynika z brakujących odniesień do konektorów lub źle zarządzanych zmiennych środowiskowych.
• 3:34
  Brak odniesienia do konektora oznacza po prostu, że przepływ nie może znaleźć swojego połączenia z Outlookiem lub Dataverse.
• 3:40
  Dlatego w chwili, gdy próbujesz uruchomić aplikację lub przepływ w innym środowisku, otrzymujesz błędy wykonania.
• 3:46
  A ponieważ zmienne środowiskowe w Power Platform działają inaczej niż w innych produktach Microsoft 365, sprawiają one problemy nawet doświadczonym programistom.
• 3:55
  Zmienne mają obsługiwać punkty końcowe, klucze lub konfiguracje specyficzne dla dzierżawy.
• 4:00
  Jeśli jednak ktoś zapomni zaktualizować je po wyeksportowaniu rozwiązania, nawet niepozorna zmiana może zepsuć działającą aplikację.
• 4:06
  Wielu z nas wpada w tę samą pułapkę na początku.
• 4:09
  Można pomyśleć, że wyeksportowany plik zip rozwiązania zawiera wszystko, co potrzebne, ale w rzeczywistości pomija on dynamiczne odniesienia do konektorów.
• 4:14
  Załóżmy na przykład, że masz aplikację używającą konektora HTTP dla zewnętrznej usługi w środowisku dev.
• 4:19
  Podczas importu do środowiska test lub prod ta konkretna instancja konektora nie będzie istnieć.
• 4:24
  Odniesienie do konektora wewnątrz aplikacji wskazuje na brakujący obiekt, a przepływy w rozwiązaniu po cichu się psują, dopóki użytkownik lub administrator ręcznie ich nie odtworzy i nie zmapuje na nowo.
• 4:34
  Jeśli masz więcej niż jednego twórcę lub administratora, jeszcze łatwiej stracić orientację, co dokąd prowadzi, a nikt nie chce analizy po awarii w stylu u mnie na dev działało.
• 4:44
  Kolejna komplikacja – jednostki usługi – Service Principles.
• 4:47
  Większość osób zaczyna od używania kont użytkowników do eksportowania i importowania rozwiązań, bo tak szybciej.
• 4:53
  Ale próba automatyzacji za pomocą GitHub Actions lub dowolnego systemu Ci przy użyciu danych logowania konkretnej osoby szybko prowadzi do ślepego załuka.
• 5:00
  Natrafisz na mury uprawnień, czasem bez jasnych komunikatów o błędach lub nawet wywołasz audyty zgodności, ponieważ uruchamiasz krytyczne wdrożenia na koncie osobistym zamiast na koncie przeznaczonym do automatyzacji.
• 5:10
  Jednostki usługi – Service Principles, będące w istocie tożsamościami aplikacji utworzonymi w usłudze Azure Ad, obsługują wszystkie uprawnienia, logowanie i audyt potrzebne w Twoim potoku.
• 5:19
  Bez nich Twój łańcuch automatyzacji zamienia się w mozaikę przekazań między osobami i nigdy nie wiesz, kto co zmienił.
• 5:25
  Kontrola wersji również staje się wielką niewiadomą.
• 5:28
  W przypadku zwykłego kodu masz historię komitów i narzędzia do śledzenia zmian Blame Tools.
• 5:32
  Pliki rozwiązań Power Platform to tylko migawki, co oznacza brak szczegółowego śledzenia zmian.
• 5:37
  Logika ukryta w formułach ekranu aplikacji typu Canvas lub w słabo udokumentowanych przepływach nie jest widoczna, dopóki ponownie ich nie wyeksportujesz.
• 5:44
  Ktoś zmienia ustawienie przepływu w interfejsie użytkownika, a Ty musisz życzyć sobie szczęścia w odkrywaniu, dlaczego środowiska docelowe nagle zachowują się inaczej.
• 5:50
  W rezultacie zarządzanie ALM dla Power Platform przypomina układanie puzli, w których brakuje połowy elementów albo są one ukryte pod pudełkiem.
• 5:57
  Niewidoczne zależności, łączniki specyficzne dla środowiska oraz zmienne, których nie widać w kodzie, zmieniają typowy przepływ pracy programisty.
• 6:06
  A to jeszcze przed zmierzeniem się z faktem, że środowiska produkcyjne prawie zawsze mają surowsze uprawnienia, inne zasady ochrony danych i wymogi audytowe, które nie są oczywiste w fazie programowania czy testów.
• 6:16
  Ale jest też dobra strona. Ta złożoność nie jest przypadkowa. Istnieje praktyczny powód, dla którego Power Platform traktuje źródło, zmienne i łączniki w tak unikalny sposób.
• 6:26
  Platforma ma na celu umożliwienie użytkownikom biznesowym tworzenie zaawansowanych aplikacji bez martwienia się o kod.
• 6:32
  Efektem ubocznym jest to, że ty jako osoba konfigurująca automatyzację musisz śledzić to, co ukryte pod maską.
• 6:38
  Jeśli wiesz, gdzie biegną te niewidoczne przewody, możesz naprawić lub uniknąć większości błędów, które wykolejają proces ALM w Power Platform.
• 6:47
  Jeśli brzmi to jak wyzwanie, to masz rację. Istnieją jednak cztery filary ALM, które pomagają uporządkować ten bałagan.
• 6:53
  Źródło Source, kompilacja Build, testowanie Test i wdrażanie Deploy.
• 6:56
  Każdy z nich ma swoje specyficzne cechy w Power Platform, ale razem przywracają strukturę temu, co inaczej wydaje się chaosem.
• 7:02
  Podstawowy system ALM, źródło, kompilacja, testowanie, wdrażanie.
• 7:05
  Za każdym razem, gdy ktoś prosi o potok Power Platform, który po prostu działa, pierwszą rzeczą, jaka przychodzi na myśl, są te cztery filary ALM, źródło, kompilacja, testowanie, wdrażanie.
• 7:15
  W tradycyjnym świecie programowania mógłbyś to robić niemal przez sen.
• 7:18
  Power Platform nie pozwala jednak na takie ułatwienia.
• 7:21
  Nagle źródło przestaje oznaczać kod.
• 7:24
  Oznacza to zmaganie się z plikami rozwiązań, eksportowanie spakowanych paczek zawierających aplikacje, przepływy, a czasem łączniki udające część kodu źródłowego.
• 7:33
  Zacznijmy od podstaw, a potem przeanalizujmy, co sprawia, że każdy z tych filarów jest w tym świecie nieco dziwny.
• 7:38
  Masz swój plik zip z rozwiązaniem.
• 7:40
  Nie jest to kod w potocznym tego słowa znaczeniu.
• 7:42
  Otwórz to, a przywitają Cię pliki XML i JSON, a nie logika, którą znasz z TypeScripta czy C-Kratka.
• 7:48
  To jednak kod źródłowy dla Power Platform.
• 7:51
  Zespoły często się tu potykają.
• 7:52
  Wygląda na przenośne, dopóki nie zauważysz, że większość zmian, jak aktualizacja formuły czy korekta logiki przepływu, nie jest widoczna, póki nie wyeksportujesz nowego pliku zip rozwiązania.
• 8:02
  Więc tak możesz wersjonować te pliki rozwiązań w Gicie, ale jeśli nie eksportujesz ich po każdej istotnej edycji, w historii powstaną rażące luki.
• 8:10
  Teraz konfiguracja.
• 8:12
  W zwykłych aplikacjach wystarczy zapisać ciągi połączeń w pliku konfiguracyjnym i gotowe.
• 8:17
  Power Platform przemyca dane specyficzne dla środowiska wewnątrz tych rozwiązań.
• 8:21
  To nie tylko zmienne środowiskowe, to odwołania do konektorów, dynamiczne punkty końcowe, role i uprawnienia powiązane z logiką biznesową.
• 8:29
  Jeśli zapomnisz je zaktualizować przed eksportem z wersji deweloperskiej lub testowej, utrwalisz błędne wskazania.
• 8:36
  Widziałem zespoły, które religijnie komitowały pliki zip rozwiązań, a po wdrożeniu odkrywały, że połowa aplikacji wciąż łączy się z deweloperskim datavers zamiast produkcyjnym, bo nikt nie zmapował odwołań do konektorów.
• 8:48
  Następnie mamy budowanie.
• 8:50
  Słowo build kojarzy się zazwyczaj z kompilacją kodu i obserwowaniem zielonych ptaszków w zadaniu CI.
• 8:55
  W Power Platform proces budowania polega na przechowywaniu paczek zip, sprawdzaniu schematów i weryfikacji zależności.
• 9:02
  W potoku GitHub Actions zadanie budowania pobiera zatwierdzony plik rozwiązania, a następnie używa interfejsu wiersza poleceń Power Platform, by rozpakować, sprawdzić i ponownie spakować rozwiązanie.
• 9:11
  Krok weryfikacji to moment, w którym dzieje się magia lub chaos.
• 9:15
  Może on wyłapać zerwane odwołania lub nieobsługiwane akcje.
• 9:17
  Co gorsza, jeśli zmiana w przepływie opiera się na niestandardowym konektorze, który nie trafił do kontroli źródła, budowanie po cichu zapakuje niekompletny produkt.
• 9:26
  Tu sprawy stają się skomplikowane.
• 9:28
  Te zadania budowania mniej polegają na kompilacji, a bardziej na orkiestracji niezawodnego eksportu i upewnieniu się, że zawartość nadaje się do wysyłki.
• 9:36
  Zespoły, które to pomijają lub robią w pośpiechu, szybko trafiają na sytuacje, gdzie budowanie technicznie się udaje, ale to, co trafia na UAT lub produkcję, nie posiada połowy funkcji.
• 9:44
  Microsoft promuje przekaz, że pliki rozwiązań zapewniają przenośność ALM, ale zawsze jest tu jakiś przypis.
• 9:50
  Przenośność zależy od poprawnego zmapowania konektorów i skonfigurowania ról w środowiskach.
• 9:55
  Testowanie to kolejny ważny punkt.
• 9:57
  W potoku aplikacji webowej zautomatyzowane testy mogą uruchamiać testy jednostkowe lub sprawdzać interfejs użytkownika.
• 10:02
  W przypadku Power Platform to, co uznaje się za test, jest kwestią sporną.
• 10:06
  Czasami to walidacja rozwiązania, czyli czy rozwiązanie się otwiera i czy kluczowe zależności są poprawnie rozpoznawane.
• 10:12
  Innym razem to uruchamianie przepływów testowych lub sprawdzanie, czy konektory odpowiadają w środowisku testowym.
• 10:18
  Często testy wykonuje się ręcznie, ponieważ walidacja logiki biznesowej wewnątrz aplikacji typu Canvas nie jest jeszcze w pełni zintegrowana z automatycznymi potokami.
• 10:25
  Możesz jednak zautomatyzować sprawdzanie brakujących konektorów, weryfikację krytycznych przepływów, a nawet wysyłanie pingów do środowiska testowego, aby potwierdzić działanie poświadczeń.
• 10:33
  Wdrożenie to moment, w którym pojawiają się największe trudności.
• 10:36
  Przy wdrażaniu standardowej aplikacji wystarczy czasem po prostu wypchnąć artefakt internetowy na Azure.
• 10:40
  W Power Platform musisz mapować połączenia, przypisywać uprawnienia, aktualizować wpisy tajne, zmieniać zmienne środowiskowe i na koniec uruchomić import za pomocą jednostki usługi nigdy zwykłego konta.
• 10:49
  W przeciwnym razie utkniesz w audytach i odmowach dostępu.
• 10:53
  GitHub Actions może spiąć ten proces, ale tylko wtedy, gdy każde zadanie wie, w które środowisko celować i jakich wpisów tajnych użyć.
• 11:00
  Widziałem zespoły, które próbowały iść na skróty używając jednego zestawu poświadczeń dla środowiska deweloperskiego i produkcyjnego, co jest prostą drogą do chaosu, wycieków danych, błędów uprawnień i usterek widocznych tylko w jednym środowisku.
• 11:10
  Weźmy pod uwagę rzeczywisty zespół, z którym pracowałem kilka miesięcy temu.
• 11:13
  Robili większość rzeczy dobrze standardowe repozytoria Git, wersjonowane pliki zip rozwiązań i przejrzyste gałęzie.
• 11:18
  Mimo to ich potok zawsze zawodził podczas wdrażania.
• 11:21
  Dlaczego?
• 11:21
  Nigdy nie zawracali sobie głowy zamianą zmiennych środowiskowych ani aktualizacją referencji konektorów przed importem na produkcję.
• 11:26
  W efekcie kluczowe przepływy wskazywały na niewłaściwe punkty końcowe, a dane wyciekały do błędnych systemów.
• 11:31
  Rozwiązaniem były skryptowe kroki w ich potoku GitHub, które zamieniały zmienne i mapowały ponownie każdy konektor podczas importu.
• 11:38
  Wytyczne Microsoftu mówią o tym wprost.
• 11:40
  Używaj plików rozwiązań do przenoszenia elementów między środowiskami, ale zawsze obsługuj referencje konektorów i mapowanie ról w ramach swojego potoku.
• 11:48
  Wskazują oni, że pomijanie tych kroków to główna przyczyna awarii aplikacji, szczególnie gdy środowiska stają się bardziej restrykcyjne.
• 11:53
  Gdy zaczniesz traktować źródło kompilacje, testy i wdrożenie jako połączone części mechanizmu, a nie odizolowane kroki, łatwiej dostrzec, dlaczego tyle prób ALM kończy się fiaskiem i jak faktycznie rozwiązywać problemy zamiast liczyć na łód szczęścia.
• 12:06
  Następnie przejdziemy do tego, jak GitHub Actions koordynuje ten taniec, wyzwalacze, gałęzie i podział zadań, które czynią automatyzację Power Platform elastyczną i bezpieczną.
• 12:16
  GitHub Actions – łączenie kropek za pomocą wyzwalaczy i zadań.
• 12:20
  Jeśli czekałeś na zakończenie potoku GitHub Actions po aktualizacji swojej aplikacji Power App, wiesz już, że automatyzacja nie oznacza natychmiastowości i z pewnością nie oznacza magii.
• 12:29
  Większość zespołów natrafia na te ściany zaraz po ekscytacji pierwszym udanym uruchomieniem przepływu pracy.
• 12:33
  Konfigurujesz skrypt, podpinasz go pod swoje repozytorium i oczekujesz, że każdy nowy KOMI będzie płynnie wdrażany we wszystkich środowiskach.
• 12:41
  Wtedy do głosu dochodzi rzeczywistość. Zamiast po prostu uruchamiać skrypt, GitHub Actions wykorzystuje łańcuch logiczny zbudowany wokół wyzwalaczy, zadań i przekazywania danych między środowiskami.
• 12:51
  Ten porządek i struktura sprawiają, że wdrożenia nie zamieniają się w plątaninę nieudanych kroków i dziwnych błędów.
• 12:56
  Punktem wyjścia w tym systemie jest wyzwalacz.
• 12:59
  Większość początkujących tworzy przepływ pracy, który uruchamia się przy każdym wypchnięciu kodu lub gdy Pulli Quest trafia do głównej gałęzi.
• 13:07
  Na pierwszy rzut oka wygląda to na najlepszą praktykę. Dlaczego nie uruchamiać potoku za każdym razem, gdy zmienia się kod?
• 13:13
  Oto haczyk. Kiedy ustawiasz wyzwalacz tylko dla głównej gałęzi, wszystko jest kierowane jednym torem.
• 13:17
  Co jeśli zmiany mają trafić do środowiska deweloperskiego, ale nie testowego czy produkcyjnego?
• 13:21
  Co jeśli chcesz wdrożyć na produkcję, a testy nadal trwają?
• 13:24
  Zespoły, które stosują uniwersalne wyzwalacze, często napotykają problemy, gdzie funkcje dla środowisk deweloperskich trafiają na produkcję lub wdrożenia testowe nagle nadpisują ustawienia produkcyjne.
• 13:35
  Możesz rozgałęzić przepływy pracy dla każdego środowiska dev, test i prod i ustawić bardzo specyficzne wyzwalacze dla każdego z nich.
• 13:42
  Na przykład skonfiguruj przepływ uruchamiany tylko przy wypchnięciach do gałęzi dev lub inny, gdy ktoś scala zmiany z gałęzią wydania produkcyjnego.
• 13:50
  Takie podejście daje większą kontrolę i tworzy wyraźną granicę między pracą w toku a zmianami na żywo, ale wiele zespołów nigdy nie rewiduje swoich wyzwalaczy po ich utworzeniu.
• 13:58
  W ten sposób sekrety z jednego środowiska mogą przedostać się do innego, a konfiguracja dla dev trafia przypadkiem na produkcję.
• 14:05
  Jeden zespół, z którym współpracowałem, próbował uruchomić cały proces, a LM z jednego przepływu pracy.
• 14:10
  Przez pewien czas wydawało się, że jest dobrze, dopóki ktoś nie zauważył, że ciąg połączenia z produkcyjną bazą danych pojawił się w środowisku deweloperskim.
• 14:17
  Nie zdawali sobie sprawy, że ich sekrety były współdzielone między zadaniami, a kiedy kod przenosił się między środowiskami, te sekrety wyciekały wraz z nim.
• 14:24
  To nie była oczywista awaria ani błąd. Działo się to po cichu.
• 14:28
  Tego rodzaju wycieki danych zdarzają się częściej niż myślisz, zwłaszcza jeśli nie skonfigurujesz przepływów tak, aby oddzielić sekrety od zmiennych środowiskowych.
• 14:35
  Każde zadanie w przepływie pracy GitHub Actions obsługuje konkretny etap procesu.
• 14:39
  Jedno zadanie może obsługiwać eksport rozwiązania ze środowiska źródłowego, a inne zajmuje się walidacją, rozpakowywaniem, skanowaniem metadanych, sprawdzaniem zależności i weryfikacją referencji łączników.
• 14:52
  Kolejne zadanie przygotowuje zmienne środowiskowe, dostosowując rozwiązanie do docelowego środowiska.
• 14:58
  Ostatnie zadanie uruchamia proces importu przy użyciu jednostek usługi, aby zapisać zmiany w odpowiednim środowisku.
• 15:04
  Możesz myśleć o zmiennych środowiskowych i sekretach jak o podstawowych symbolach zastępczych, ale w praktyce to one spajają wszystko w całość.
• 15:12
  Ciągi połączeń, klucze API, współdzielone hasła, wszystko to musi być wymieniane między zadaniami, ale nigdy nie może wyciec poza swoje granice.
• 15:20
  W ALM Platformy Power Platform możesz mieć inne połączenie Dataverse dla każdego środowiska lub musieć zmieniać punkty końcowe w zależności od przepływu lub aplikacji Power App.
• 15:29
  Jeśli używasz ponownie zmiennych lub wpisujesz hasła na sztywno, otrzymasz albo nietrwały potok, albo, co gorsza, poważne zagrożenia bezpieczeństwa.
• 15:36
  Proces importu zależy od pobierania sekretów tylko z właściwego magazynu, aby środowisko produkcyjne nie było narażone przez błędy w testach lub fazie deweloperskiej.
• 15:44
  Dobrym modelem mentalnym dla sekretów w GitHub Actions jest wyobrażenie sobie każdego środowiska jako własnego cyfrowego sejfu, zamkniętego pudełka, które widzą tylko odpowiednie zadania.
• 15:53
  GitHub zapewnia precyzyjną kontrolę. Możesz przypisać sekrety do środowisk, więc zadanie uruchomione w fazie deweloperskiej nie uzyska dostępu do danych uwierzytelniających produkcji i odwrotnie.
• 16:02
  Skonfiguruj te sejfy, a nawet jeśli ktoś modyfikujący potok spróbuje czegoś ryzykownego, zasady ochrony środowiska zapobiegną skutkom błędu.
• 16:09
  Dokumentacja zarówno Microsoftu, jak i GitHuba kładzie na to ogromny nacisk.
• 16:13
  Zalecają one zasady ochrony środowiska i ścisłe zakresy sekretów, aby powstrzymać wycieki między środowiskami, zanim w ogóle wystąpią.
• 16:20
  Bez tego rodzaju ochrony nawet najlepiej zaprojektowane przepływy pracy ALM się rozpadają.
• 16:25
  Wyobraź sobie przepływ wdrażający na produkcję, który wciąż korzysta z ciągu połączenia deweloperskiego lub środowisko testowe nagle uzyskujące dostęp do danych produkcyjnych.
• 16:32
  Nie zawsze powoduje to widoczne awarie. Czasami oznacza to jedynie włączenie flag zgodności lub logi wypełniające się subtelnymi błędami, które powoli narastają w poważniejsze problemy.
• 16:41
  Dlatego rozgałęzianie przepływów pracy i definiowanie zakresów sekretów to nie tylko zaawansowane tematy.
• 16:45
  To siatka bezpieczeństwa, która chroni Twoją automatyzację przed cichym rozpadem.
• 16:48
  Warto również dzielić przepływy pracy nie tylko według środowisk, ale także według odpowiedzialności.
• 16:54
  Kod, który eksportuje i weryfikuje rozwiązania, nie powinien nawet wiedzieć, jak wdrażać czy podmieniać sekrety.
• 17:00
  Jeśli każde zadanie obsługuje jeden element układanki, znacznie łatwiej jest wykryć awarię, wycofać zmiany i przeprowadzić audyt po fakcie.
• 17:08
  Sekrety pozostają w swoich sejfach, zadania przestrzegają jasno określonych uprawnień, a awarie potoku wskazują dokładnie na element wymagający naprawy.
• 17:16
  Zrozumienie, jak GitHub Actions przekazuje pracę między zadaniami, utrzymując sekrety w ścisłych zakresach, a wyzwalacze jasno zdefiniowane zmienia ALM z eksperymentu w niezawodną, bezpieczną i przewidywalną praktykę.
• 17:29
  Ta segmentacja przepływu pracy nie polega tylko na spełnianiu najlepszych praktyk.
• 17:33
  To ona blokuje ciche wycieki bezpieczeństwa i przypadkowe nadpisania, eliminując całą klasę niewidocznych błędów, zanim zaczną nękać Twoje środowiska.
• 17:42
  Teraz, gdy elementy współpracują ze sobą dzięki poprawnie zakresowanej automatyzacji, czas zająć się kolejnym punktem zapalnym.
• 17:49
  Łączniki, jednostki usługi i drobne, lecz kluczowe pułapki, które mogą wstrzymać wdrożenia, gdy już poczujesz się pewnie.
• 17:56
  Tajemnicze jednostki usługi i problemy z łącznikami.
• 17:59
  Jeśli kiedykolwiek próbowałeś przenieść power-up lub flow ze środowiska deweloperskiego na produkcyjne, znasz tę historię.
• 18:05
  Wszystko działa bez zarzutu w jednym środowisku, a po przełączeniu natychmiast staje w miejscu lub pojawiają się tajemnicze błędy połączenia.
• 18:13
  Nie dotyczy to tylko jednego zespołu. Każdy administrator power platform prędzej czy później napotyka tę barierę.
• 18:20
  Istota problemu tkwi w tym, jak łączniki i sekrety zachowują się za kulisami.
• 18:24
  Nie można po prostu wyeksportować rozwiązania w pliku zip z deweloperki i oczekiwać, że zadziała gdzie indziej, bo zależności zmieniają się wraz ze środowiskiem.
• 18:33
  Zacznijmy od odwołań do łączników.
• 18:35
  Power Platform łącznik nigdy nie jest tylko statyczną porcją informacji dołączoną do aplikacji.
• 18:40
  Jest dynamiczny, zmienny i często unikalny dla każdego środowiska.
• 18:44
  Podczas eksportu rozwiązania odwołania do łączników działają niemal jak zakładki.
• 18:48
  Wskazują one na obiekty połączeń, które istnieją tylko w środowisku, w którym zostały utworzone.
• 18:52
  Dlatego po imporcie do testów lub na produkcję Twój zaawansowany punkt końcowy HTTP czy łącze Dataverse nie zawsze są odtwarzane tak samo lub wcale.
• 19:00
  To tutaj zespoły napotykają problemy.
• 19:03
  Jeśli środowisko deweloperskie używa łącznika do danych testowych, a konfiguracja nie jest odzwierciedlona na produkcji,
• 19:10
  przepływ lub aplikacja zawiodą po cichu lub zawieszą się przy pierwszej próbie połączenia.
• 19:16
  Wiele osób próbuje to obejść, współdzieląc poświadczenia użytkowników między środowiskami.
• 19:20
  Wychodzą z założenia, że jeśli użyją tego samego konta lub hasła, które stworzyło połączenie w deweloperce, może zadziała na produkcji.
• 19:27
  W rzeczywistości sprowadza to szereg problemów od odmowy uprawnień po uruchomienie kontroli zgodności.
• 19:32
  Wytyczne Microsoft są jasne, używanie poświadczeń poszczególnych użytkowników do automatycznych wdrożeń nie jest wykonalne ani bezpieczne.
• 19:39
  Uzależnia to automatyzację od resetowania haseł i może pozostawić niejasne ślady w dziennikach audytu.
• 19:44
  Brak jasnej odpowiedzialności sprawia, że uprawnienia blokują potok, gdy pierwotny użytkownik zostanie oznaczony, usunięty lub straci dostęp.
• 19:53
  Pora na jednostki usługi Service Principles.
• 19:55
  Jeśli z nimi nie pracowałeś, wyobraź sobie jednostkę usługi jako cyfrową dodatkową parę rąk stworzoną do automatyzacji.
• 20:01
  W przeciwieństwie do zwykłego użytkownika, jednostka usługi jest powiązana z rejestracją aplikacji w Azure Ad, a nie z prawdziwą osobą.
• 20:08
  Nadajesz jej minimalne uprawnienia potrzebne do wykonania zadań wdrożeniowych.
• 20:12
  Brzmi to prosto, ale korzyści są ogromne.
• 20:15
  Zamiast polegać na użytkowniku, który może odejść z organizacji lub zmienić rolę wdrożenia, pozostają spójne, sprawdzalne i możliwe do śledzenia.
• 20:22
  Każde środowisko uzyskuje dostęp tylko do odpowiednich połączeń i zasobów, a wszelkie zmiany są rejestrowane na tym koncie robota.
• 20:28
  Gdy coś zawiedzie, masz czystą ścieżkę audytu i nie zostajesz z osieroconymi przepływami, których nikt nie może naprawić.
• 20:34
  W kwestii problemu mapowania łączników rozważ, co się dzieje, gdy środowiska zaczynają się od siebie różnić.
• 20:40
  Może zespół programistów uzyskał zgodę na nowy, niestandardowy łącznik.
• 20:43
  Załóżmy, że łączy się on z interfejsem API w piaskownicy Sandbox.
• 20:46
  Kiedy przychodzi czas na przejście na produkcję, łącznik ten nie tylko może być niedostępny, ale może być nawet niedozwolony przez organizacyjne zasady ochrony danych.
• 20:53
  Jeśli zapomnisz o ponownym zmapowaniu, aplikacja odwoła się do niewłaściwego punktu końcowego lub całkowicie przestanie działać.
• 20:58
  Widziałem ostatnio, jak boleśnie odczuła to pewna grupa z sektora ochrony zdrowia.
• 21:01
  Jedno pominięte mapowanie łącznika spowodowało użycie danych testowych na produkcji i prawie wywołało incydent związany z naruszeniem przepisów.
• 21:07
  Ich zautomatyzowany potok wyeksportował wszystko zgodnie z planem, ale odwołanie do łącznika wewnątrz rozwiązania wciąż wskazywało na starą bazę danych testowych,
• 21:15
  czego Power Platform nie wykryło, dopóki prawdziwe dane nie zaczęły przepływać niewłaściwymi kanałami.
• 21:19
  Zmienne środowiskowe pomagają złagodzić część tych problemów.
• 21:23
  W przeciwieństwie do sztywnego kodowania punktów końcowych czy klucze API, zmienne środowiskowe pozwalają oddzielić to, co zmienia się między środowiskami, od tego, co pozostaje stałe.
• 21:31
  Możesz podmieniać punkty końcowe, klucze API lub inne sekrety przy każdym wdrożeniu, bez konieczności przepisywania aplikacji czy przepływu.
• 21:37
  Na przykład przepływ współpracujący z tabelą Dataverse w środowisku deweloperskim można przy imporcie skonfigurować tak, aby korzystał z tabeli produkcyjnej, po prostu zmieniając zmienną środowiskową w procesie wdrażania.
• 21:47
  Potoki GitHub Actions sprawiają, że jest to praktyczne rozwiązanie. Każde zadanie może wstrzyknąć odpowiednią wartość we właściwym czasie, ale nawet tutaj kluczem jest dyscyplina.
• 21:56
  Jeśli zapomnisz zaktualizować zmienną lub pozwolisz, by sekrety wyciekły między środowiskami, twój przepływ pracy nagle stanie się narażony na ataki.
• 22:03
  Microsoft podkreśla potrzebę starannego określania zakresu sekretów i świadomego mapowania odwołań do łączników.
• 22:09
  Ich zasady zapobiegania utracie danych DLP istnieją z konkretnego powodu, aby powstrzymać wrażliwe informacje przed przenikaniem między środowiskami lub pojawianiem się w niewłaściwym miejscu.
• 22:18
  Jeśli spróbujesz je ominąć, współdzieląc zmienne lub połączenia, natkniesz się na firmowe mechanizmy kontroli bezpieczeństwa lub zgodności z przepisami.
• 22:26
  Co ważniejsze, tracisz przewidywalność, ponieważ zaciera się granica między tym, co jest przeznaczone dla środowiska deweloperskiego, testowego lub produkcyjnego.
• 22:33
  Trudno przecenić korzyści płynące z poprawnego wykonania tych wszystkich czynności.
• 22:36
  Zasady usługi Service Principles w połączeniu z dobrze zarządzanymi zmiennymi środowiskowymi i poprawnie zmapowanymi łącznikami zmieniają Twój potok wdrożeniowy.
• 22:42
  Twoje wdrożenia stają się przewidywalne.
• 22:45
  Gdy coś się zepsuje, masz jasny łańcuch odpowiedzialności i dokładnie wiesz, gdzie szukać przyczyny.
• 22:49
  Czy to było mapowanie łącznika, zmienna, czy może brakujące uprawnienie?
• 22:52
  Audytorzy mogą śledzić zmiany i nie ma niepewności, gdy ktoś odchodzi z organizacji lub zmienia hasła.
• 22:57
  Wszystko sprowadza się do traktowania sekretów, łączników i zasad usługi tak, jakby miały one kluczowe znaczenie.