Zrozumienie środowisk
Przepływy pracy wdrażania umożliwiają automatyzację kroków procesu wdrażania. Często należy uruchomić kroki w wielu oddzielnych środowiskach. W firmie z toy chcesz przejrzeć zmiany w kodzie przed wdrożeniem zmian w środowisku produkcyjnym.
W tej lekcji dowiesz się, jak środowiska w funkcji GitHub Actions ułatwiają obsługę własnego procesu.
Dlaczego masz wiele środowisk?
Procesy wdrażania wprowadzają zmiany w zasobach platformy Azure, w tym w używanych zasobach. Zmiana zasobów wiąże się z pewnym ryzykiem, ponieważ wdrożone zmiany mogą nie zachowywać się zgodnie z oczekiwaniami. Może się nawet okazać, że zmiany przerywają bieżącą konfigurację.
Aby zminimalizować ryzyko problemów, dobrym rozwiązaniem jest wypróbowanie zmian w bezpieczny sposób przed wdrożeniem ich w środowisku produkcyjnym. Można zminimalizować ryzyko, wdrażając zmiany w środowisku nieprodukcyjnym.
Wiele organizacji konfiguruje wiele środowisk nieprodukcyjnych, w których stopniowo wdrażają zmiany przed wydaniem do środowiska produkcyjnego. Każde środowisko nieprodukcyjne służy do określonego celu i często ma określone bramy jakości, które muszą zostać spełnione, aby przejść do następnego środowiska. Jeśli coś pójdzie nie tak, jak niepowodzenie testu, wdrożenie zostanie zatrzymane. W miarę jak wdrożenie przechodzi przez każde środowisko, rośnie zaufanie do zmian.
Typowe środowiska obejmują:
Programowanie: środowisko programistyczne jest zwykle używane przez deweloperów do wypróbowania zmian i szybkiego iterowania pracy.
Środowiska deweloperskie często mają minimalne mechanizmy kontroli, dzięki czemu członkowie zespołu mogą łatwo wypróbować pomysły. Możesz użyć środowiska programistycznego do przetestowania określonego ustawienia konfiguracji w zasobie lub dowiedzieć się, jak można skonfigurować nową witrynę internetową z bazą danych zaplecza w bezpieczny sposób. Wiele z tych zmian i wersji próbnych może nie przejść do procesu wdrażania, ponieważ eliminujesz pomysły, które nie kończą się powodzeniem.
W niektórych zespołach możesz nawet skonfigurować oddzielne środowisko programistyczne dla każdego członka zespołu, aby nie były w sobie dostępne podczas pracy nad nowymi funkcjami.
Środowiska programistyczne są czasami nazywane również środowiskami piaskownicy .
Test: środowisko testowe jest przeznaczone do uruchamiania testów ręcznych lub automatycznych pod kątem zmian.
Środowiska testowe mogą być używane w procesie ciągłej integracji. Po wdrożeniu zmiany w środowisku testowym można uruchamiać testy automatyczne. Jeśli wszystkie testy automatyczne przechodzą pomyślnie, zmiana jest bezpieczna do scalenia z główną gałęzią projektu. Testy automatyczne zwykle sprawdzają podstawowe funkcje systemu wraz z naruszeniami zasad w nowo wdrożonych zasobach.
Możesz również utworzyć dedykowane środowiska testowe dla określonych typów testów, takich jak testowanie wydajności i zabezpieczeń.
Integracja: Środowisko integracji może pomóc w przetestowaniu wszystkich punktów integracji z innymi systemami.
Możesz symulować kompleksowe transakcje w środowisku integracji. Te testy często są uruchamiane automatycznie, ale wiele organizacji wykonuje również testy ręczne względem tego środowiska.
Środowiska integracji są czasami nazywane również środowiskami testów integracji systemu (SIT).
Test akceptacji użytkownika: środowisko test akceptacji użytkownika (UAT) jest używane do ręcznej weryfikacji, zwykle przez uczestników projektu biznesowego, a nie przez deweloperów. W przypadku ręcznej weryfikacji ktoś przechodzi przez rozwiązanie i sprawdza, czy działa zgodnie z oczekiwaniami i czy spełnia niezbędne wymagania biznesowe. Następnie ta osoba zatwierdza zmiany, aby wdrożenie było kontynuowane.
Przedprodukcyjne: środowisko przedprodukcyjne jest często dublowaniem środowiska produkcyjnego z tymi samymi jednostkami SKU zasobów i konfiguracją. Jest ona używana jako ostateczna kontrola w celu sprawdzenia, jak będzie zachowywać się wdrożenie produkcyjne podczas i po zastosowaniu zmiany. Można go również użyć do sprawdzenia, czy spodziewać się przestoju podczas wdrażania produkcyjnego.
Środowiska przedprodukcyjne są czasami nazywane środowiskami przejściowymi .
Produkcja: Środowisko produkcyjne jest tym, z którego korzystają użytkownicy końcowi aplikacji. To środowisko na żywo, które chcesz chronić i jak najwięcej pracować.
W niektórych organizacjach może istnieć wiele środowisk produkcyjnych. Na przykład możesz mieć środowiska produkcyjne w różnych regionach geograficznych lub obsługiwać różne grupy klientów.
Pokaz: Twój zespół może również tworzyć środowiska demonstracyjne (demonstracyjne), aby pokazać aplikację użytkownikom końcowym, używać ich w szkoleniach lub zespołom sprzedaży, aby pokazać pewne możliwości potencjalnym klientom. Możesz nawet mieć wiele środowisk demonstracyjnych, które służą różnym celom. Środowisko demonstracyjne jest często odchudzoną repliką środowiska produkcyjnego z fałszywymi danymi klientów.
Środowiska w organizacji
Istnieją odmiany tych środowisk. Niektóre organizacje używają tylko kilku środowisk, a niektóre używają o wiele więcej. Liczba i typ używanych środowisk zależą od wdrażanego rozwiązania, rozmiaru zespołu tworzącego rozwiązanie oraz znaczenia obciążenia.
Czasami pojedyncze środowisko odgrywa rolę kilku wymienionych wcześniej środowisk. Innym razem może istnieć złożony przepływ pracy, który jest wdrażany w wielu środowiskach, niektóre równolegle i niektóre w sekwencji. Niektóre organizacje nawet automatycznie usuwają lub anulują aprowizacje środowisk, gdy nie są już używane, a następnie ponownie wdrażają je, gdy będą potrzebne w przyszłości.
Niezależnie od tego, co organizacja wybierze jako listę środowisk, celem jest zwiększenie zaufania do zmiany w miarę postępu przepływu pracy wdrażania. Jeśli zmiana nie spełnia wymagań dotyczących jakości, chcesz zatrzymać wdrażanie tej zmiany w każdym kolejnym środowisku w łańcuchu.
W firmie z toy decydujesz się rozpocząć od podstawowego zestawu środowisk dla witryny internetowej. Oprócz środowiska produkcyjnego utworzysz jedno nieprodukcyjne środowisko o nazwie Test:
Zaktualizujesz przepływ pracy, aby wdrożyć kod Bicep w środowisku testowym i uruchomić kilka podstawowych testów względem niego. Jeśli ten wysiłek zakończy się pomyślnie, możesz wdrożyć je w środowisku produkcyjnym.
Środowiska przepływu pracy
Funkcja GitHub Actions ma również koncepcję środowiska. Utworzysz środowisko funkcji GitHub Actions reprezentujące środowisko, które masz na platformie Azure. Podczas definiowania przepływu pracy w pliku YAML można połączyć zadania z określonym środowiskiem. Korzystając ze środowisk, możesz uzyskać dodatkowe funkcje w przepływie pracy.
Reguły ochrony
Środowisko w funkcji GitHub Actions może mieć skonfigurowane reguły ochrony. Za każdym razem, gdy środowisko jest używane w zadaniu w przepływie pracy, funkcja GitHub Actions upewni się, że te reguły są spełnione przed uruchomieniem zadania.
Można na przykład skonfigurować ręczne przeglądy w środowisku produkcyjnym. Przed rozpoczęciem wdrożenia produkcyjnego wyznaczony recenzent otrzymuje powiadomienie. Ta osoba może ręcznie sprawdzić, czy zasady i procedury są spełnione przed rozpoczęciem wdrażania. Na przykład osoba zatwierdzająca może sprawdzić, czy wszystko działa zgodnie z oczekiwaniami w środowisku przedprodukcyjnym przed zatwierdzeniem wdrożenia.
Ponadto można uruchomić automatyczne sprawdzanie, aby potwierdzić gałąź, z której pochodzi zmiana. Jeśli zmiana nie znajduje się w gałęzi głównej, możesz skonfigurować usługę GitHub, aby zapobiec jej wdrażaniu w środowisku produkcyjnym.
Wpisy tajne
Funkcja GitHub Actions umożliwia przechowywanie wpisów tajnych, które mogą być używane tylko w określonym środowisku. Więcej informacji na temat zarządzania wpisami tajnymi znajdziesz w dalszej części tego modułu.
Historia wdrożenia
Funkcja GitHub Actions śledzi historię wdrożeń w środowisku. Ta historia umożliwia łatwe śledzenie tego, co dzieje się w środowisku w czasie. Umożliwia nawet śledzenie wdrożenia do zatwierdzenia w repozytorium. Ta funkcja może być przydatna, jeśli masz problem z wdrożeniem i musisz zidentyfikować zmiany, które doprowadziły do problemu.
Tworzenie środowisk
Zazwyczaj środowisko jest tworzone przy użyciu interfejsu internetowego usługi GitHub.
Gdy przepływ pracy odwołuje się do środowiska, które nie istnieje, funkcja GitHub Actions automatycznie je utworzy. Ta funkcja może mieć wpływ na bezpieczeństwo repozytorium GitHub, ponieważ nowe środowisko nie będzie miało skonfigurowanych żadnych reguł ochrony. Najlepiej samodzielnie utworzyć środowisko za pośrednictwem interfejsu internetowego usługi GitHub, aby mieć pełną kontrolę nad zabezpieczeniami.
Łączenie zadania wdrożenia ze środowiskiem
W definicji przepływu pracy wdrażania można odwołać się do środowiska przy użyciu environment właściwości :
jobs:
deploy:
environment: Test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
W tym przykładzie zadanie o nazwie deploy jest połączone ze Test środowiskiem.
Środowiska i połączenia z platformą Azure
W przypadku korzystania z wielu środowisk należy sprawić, aby każde środowisko było niezależne od innych. Na przykład witryna internetowa środowiska deweloperskiego nie powinna mieć dostępu do bazy danych w środowisku produkcyjnym.
Ta sama zasada dotyczy również przepływu pracy wdrażania. Należy utworzyć oddzielne tożsamości obciążeń dla każdego środowiska. Zgodnie z tą praktyką dodano kolejną warstwę ochrony, aby upewnić się, że wdrożenia nieprodukcyjne nie mają wpływu na środowisko produkcyjne.
Tożsamości obciążeń powinny mieć przypisane określone uprawnienia do wdrażania tylko w subskrypcji i grupie zasobów używanej przez to środowisko:
Ważne
Użyj oddzielnej tożsamości obciążenia dla każdego środowiska, w którym planujesz wdrożyć. Udziel tożsamości obciążenia minimalne uprawnienia, które musi wdrożyć w swoim środowisku, i nie ma innych.
Dobrym pomysłem jest również oddzielenie środowisk na platformie Azure. Co najmniej należy utworzyć oddzielną grupę zasobów dla każdego środowiska. W wielu sytuacjach lepiej jest utworzyć oddzielne subskrypcje platformy Azure dla każdego środowiska. Następnie można utworzyć wiele grup zasobów w ramach subskrypcji każdego środowiska.
Zastosuj przypisania ról platformy Azure, aby użytkownicy i tożsamości obciążeń mogli uzyskiwać dostęp tylko do środowisk, do których potrzebują dostępu. Należy zachować ostrożność, aby ograniczyć dostęp do środowiska produkcyjnego do małego zestawu osób i tożsamości obciążenia wdrożenia dla tego środowiska.
Poświadczenia federacyjne dla środowisk
Gdy tożsamość obciążenia łączy się z platformą Azure z przepływu pracy wdrażania, używa poświadczeń federacyjnych do bezpiecznego uwierzytelniania się bez żadnych wpisów tajnych ani kluczy. W poprzednich modułach w tej ścieżce szkoleniowej poświadczenia federacyjne udzieliły dostępu do przepływów pracy wdrażania podczas wdrażania z głównej gałęzi repozytorium Git.
Podczas wdrażania w środowisku w przepływie pracy należy użyć poświadczeń federacyjnych o określonym zakresie w tym środowisku.
W tym module przepływ pracy obejmuje kilka zadań, z których wiele łączy się i wdraża na platformie Azure. Niektóre zadania używają środowisk, a niektóre nie. Dlatego należy utworzyć dwa federacyjne poświadczenia dla każdej tożsamości obciążenia: jeden o określonym zakresie w środowisku i jeden w zakresie do głównej gałęzi.