Zrozumienie środowisk
Potoki wdrażania umożliwiają automatyzację kroków w procesie 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 usłudze Azure Pipelines ułatwiają obsługę własnego przepływu pracy.
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 na przykład wdrożyć 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
Mogą pojawić się 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 potok, 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ępów w potoku 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 potok, 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, kod zostanie wdrożony w środowisku produkcyjnym.
Środowiska potoków
Usługa Azure Pipelines ma również koncepcję środowiska. Utworzysz środowisko usługi Azure Pipelines reprezentujące środowisko, które masz na platformie Azure. Podczas definiowania potoku w pliku YAML należy połączyć zadania wdrożenia z określonym środowiskiem. Korzystając ze środowisk, możesz uzyskać inne funkcje w potoku.
Kontrole i zatwierdzenia
Środowisko w usłudze Azure DevOps może mieć skonfigurowane kontrole i zatwierdzenia. Za każdym razem, gdy środowisko jest używane w zadaniu w potoku, usługa Azure DevOps upewnia się, że te testy i zatwierdzenia kończą się powodzeniem przed uruchomieniem zadania.
Można na przykład skonfigurować zatwierdzenia ręczne w środowisku produkcyjnym. Przed rozpoczęciem wdrożenia produkcyjnego wyznaczony osoba zatwierdzająca otrzyma powiadomienie e-mail. 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 przejrzeć dzienniki i współczynniki błędów w środowisku przedprodukcyjnym po ostatnim wdrożeniu. Jeśli sprawdzanie potwierdzi, że liczba błędów nie została znacząco zwiększona, umożliwia kontynuowanie wdrażania.
Historia wdrożenia
Usługa Azure Pipelines ś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 określonego żądania funkcji w elementach roboczych usługi Azure Boards lub 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.
Zabezpieczenia
Do środowisk można zastosować inne mechanizmy kontroli zabezpieczeń. Możesz ograniczyć potoki, które mogą używać określonego środowiska. Możesz też zapobiec przypadkowemu utworzeniu pomocniczego potoku, który wchodzi w interakcję ze środowiskiem produkcyjnym.
Możesz również zastosować uprawnienia użytkownika, aby kontrolować użytkowników, którzy mogą zarządzać środowiskami. Określone uprawnienia mogą umożliwić użytkownikom tworzenie nowych środowisk, modyfikowanie środowisk oraz wyświetlanie środowisk i historii wdrożeń.
Uwaga
Gdy potok odwołuje się do środowiska, które jeszcze nie istnieje, usługa Azure Pipelines automatycznie go utworzy. Ta funkcja może mieć wpływ na bezpieczeństwo projektu usługi Azure DevOps, ponieważ automatycznie uzyskasz uprawnienia administracyjne do środowiska. Najlepszym rozwiązaniem jest samodzielne utworzenie środowiska za pośrednictwem interfejsu internetowego usługi Azure DevOps, dzięki czemu masz pełną kontrolę nad zabezpieczeniami i nie uzyskujesz przypadkowo uprawnień, których nie potrzebujesz.
Łączenie zadania wdrożenia ze środowiskiem
W definicji potoku wdrażania należy utworzyć deployment właściwość w celu określenia zadania wdrożenia i określić nazwę środowiska, w którym jest wdrażane zadanie:
- stage: DeployTest
displayName: Deploy (Test Environment)
jobs:
- deployment: DeployWebsite
environment: Test
strategy:
runOnce:
deploy:
steps:
- checkout: self
W tym przykładzie zadanie o nazwie DeployWebsite jest połączone ze Test środowiskiem.
Napiwek
Zadania mają również inne właściwości, w tym strategię wdrażania, która wykracza poza zakres tego modułu. Link do dodatkowych informacji znajduje się w lekcji podsumowania.
Środowiska i połączenia usług
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ż potoku wdrażania. Połączenie usługi używane do wdrażania w środowisku deweloperskim nie powinno mieć dostępu do środowiska produkcyjnego. Zgodnie z tą zasadą dodano kolejną warstwę ochrony, aby upewnić się, że wdrożenia nieprodukcyjne nie mają wpływu na środowisko produkcyjne.
Należy utworzyć oddzielne połączenia usług dla każdego środowiska. Każde połączenie usługi powinno używać własnej dedykowanej jednostki usługi z określonymi uprawnieniami do wdrażania tylko w subskrypcji i grupie zasobów używanej przez to środowisko:
Ważne
Użyj oddzielnej jednostki usługi i połączenia usługi dla każdego środowiska, w którym planujesz wdrożyć. Przyznaj jednostce usługi 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 jednostki usługi 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 jednostki usługi wdrażania dla tego środowiska.