Kontrolowanie wdrożeń za pomocą środowisk GitHub
Usługa Proseware automatyzuje wdrażanie modelu, ale zespół nie chce, aby każde pomyślne uruchomienie przepływu pracy natychmiast zmieniło ruch produkcyjny. Testy automatyczne powinny najpierw zweryfikować wdrożenie. Recenzent powinien następnie zdecydować, czy dowody popierają podwyższenie poziomu.
Reprezentacja etapów wdrażania
Środowisko GitHub jest nazwanym obiektem docelowym wdrożenia w repozytorium, takim jak staging lub production. Zadanie w przepływie pracy odnosi się do środowiska, na które jest kierowane. GitHub ocenia reguły ochrony tego środowiska przed uruchomieniem zadania lub uzyskaniem dostępu do sekretów środowiska.
Nazwa środowiska nie tworzy zasobu Azure. Decydujesz, jak każde środowisko GitHub mapuje Azure Machine Learning zasoby. Na przykład środowiska testowe i produkcyjne mogą używać oddzielnych obszarów roboczych dla lepszej izolacji albo oddzielnych punktów końcowych w jednym obszarze roboczym, aby zmniejszyć narzut administracyjny.
Uwaga / Notatka
Środowisko GitHub kontroluje zadania wdrażania. Środowisko Azure Machine Learning definiuje system operacyjny, pakiety i inne zależności używane do uruchamiania kodu uczenia maszynowego. Te dwie koncepcje są niezależne.
Ochrona podwyższania poziomu produkcji
Reguły ochrony środowiska GitHub mogą wymagać zatwierdzającego, ograniczać wdrożenia do wybranych branchy lub tagów albo dodawać czas oczekiwania. W przypadku Proseware tylko uruchomienia z main mogą być kierowane do środowiska produkcyjnego. Wymagany recenzent sprawdza wyniki testu przejściowego przed zezwoleniem na kontynuowanie zadania podwyższania poziomu produkcji.
Ta brama oddziela dwie decyzje. Zautomatyzowane kontrole określają, czy wdrożenie spełnia zdefiniowane wymagania. Recenzent decyduje, czy wydanie powinno być teraz kontynuowane, biorąc pod uwagę dowody i kontekst operacyjny.
Konfiguracja zakresu i dostęp
Zmienne środowiskowe mogą zawierać niewrażliwe ustawienia docelowe, takie jak nazwy obszarów roboczych Azure Machine Learning i punktów końcowych. Sekrety środowiska są dostępne tylko dla zadań, które odwołują się do tego środowiska, i dopiero po spełnieniu jego reguł ochrony.
W OIDC nie przechowujesz klucza tajnego klienta. Nadal można używać różnych tożsamości federacyjnych dla środowiska testowego i produkcyjnego, a następnie przyznać każdej tożsamości tylko te uprawnienia platformy Azure, których wymaga jej rola. Takie podejście uniemożliwia tymczasowemu zadaniu uzyskanie dostępu produkcyjnego po prostu dlatego, że oba zadania używają tego samego repozytorium.
Praktyczny przepływ pracy oddziela wdrażanie od promowania. Jedno zadanie wdraża i testuje nowy model bez ruchu produkcyjnego. Kolejne zadanie odwołuje się do chronionego środowiska production i przełącza ruch dopiero po zatwierdzeniu.
Wskazówka
Przed dodaniem zatwierdzenia zidentyfikuj dowody wymagane przez recenzenta. Brama bez wyraźnych kryteriów akceptacji opóźnia wdrażanie bez poprawy decyzji.
Dowiedz się więcej o zarządzaniu środowiskami GitHub na potrzeby wdrażania.