Wdrażanie na produkcję z bramkami akceptacji
Dowiedz się, jak bezpiecznie promować kompilacje ze środowiska staging na produkcję, korzystając z reguł ochrony środowisk GitHub Actions, ręcznych akceptacji i bramek wdrożeniowych.
Wdrażanie na produkcję z bramkami akceptacji to bezpłatna lekcja CI/CD with GitHub Actions & DevOps Pipelines na CoddyKit. To lekcja 4 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej CI/CD with GitHub Actions & DevOps Pipelines, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs CI/CD with GitHub Actions & DevOps Pipelines zawiera 4 lekcji w sumie.
Dlaczego produkcja wymaga bramek
Ciągłe wdrażanie dostarcza kod automatycznie, ale bezpośrednie wysyłanie go na produkcję bez żadnego punktu kontrolnego jest ryzykowne. Nieudane wydanie może natychmiast wpłynąć na wszystkich użytkowników.
Bramka zatwierdzająca to celowa pauza, podczas której człowiek lub automatyczna kontrola potwierdza, że wdrożenie powinno być kontynuowane.
- Ogranicza zasięg skutków błędów
- Tworzy ślad audytowy wskazujący, kto i co zatwierdził
- Pozwala oddzielić poziomy zaufania środowisk
stagingiproduction
Środowiska GitHub
GitHub Actions udostępnia funkcję o nazwie Środowiska. Środowisko, takie jak production, może mieć własne sekrety, zmienne i reguły ochrony.
Środowisko wskazuje się dla zadania za pomocą klucza environment. To podstawa dodawania bramek zatwierdzających.
jobs:
deploy:
runs-on: ubuntu-latest
environment: production
steps:
- run: echo 'Deploying to production'Wymagane osoby zatwierdzające
W ustawieniach repozytorium, w sekcji Settings > Environments > production, można włączyć opcję Required reviewers.
Gdy zadanie jest kierowane do tego środowiska, uruchomienie przepływu pracy zostaje wstrzymane i oczekuje na kliknięcie przycisku Approve przez jedną z wymienionych osób zatwierdzających.
- Można skonfigurować maksymalnie 6 osób zatwierdzających
- Jedno zatwierdzenie (domyślnie) odblokowuje zadanie
- Osoba zatwierdzająca nie może być osobą, która uruchomiła przepływ pracy, zależnie od ustawień
Kompletny przepływ pracy z bramką
W tym przykładzie zadanie build uruchamia się najpierw, a następnie zadanie deploy zależy od niego za pośrednictwem needs i jest kierowane do chronionego środowiska production.
Wdrożenie nie rozpocznie się, dopóki wymagana osoba zatwierdzająca nie zaakceptuje go w interfejsie Actions.
name: Deploy
on:
push:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- run: echo 'build artifact'
deploy:
needs: build
runs-on: ubuntu-latest
environment:
name: production
url: https://myapp.example.com
steps:
- run: echo 'deploy to prod'Timery oczekiwania
Oprócz osób zatwierdzających środowiska obsługują również timer oczekiwania. Wymusza on opóźnienie (do 30 dni), zanim wdrożenie będzie mogło się rozpocząć.
Krótki timer oczekiwania jest przydatny jako czas na bezpieczne wycofanie: daje zespołowi możliwość anulowania uruchomienia, zanim dotrze ono na produkcję.
Ograniczenia gałęzi wdrażania
Środowiska mogą ograniczać gałęzie, z których można wdrażać. W przypadku production zazwyczaj zezwala się wyłącznie na main lub tagi wydań.
Zapobiega to przypadkowemu wdrożeniu na produkcję z gałęzi funkcjonalnej.
- Chronione gałęzie — tylko gałęzie z regułami ochrony
- Wybrane gałęzie — jawna lista dozwolonych gałęzi lub wzorzec tagów
Sekrety przypisane do środowiska
Każde środowisko ma własne sekrety. Środowisko production może przechowywać PROD_DB_URL, a środowisko staging — STAGING_DB_URL.
Sekrety zdefiniowane dla środowiska są dostępne wyłącznie zadaniom kierowanym do tego środowiska, co zapewnia dodatkową warstwę izolacji.
steps:
- name: Deploy
env:
DB_URL: ${{ secrets.PROD_DB_URL }}
run: ./deploy.shŚledzenie stanu wdrożenia
Ustawienie właściwości url dla środowiska dodaje klikalny odnośnik do wdrożenia w interfejsie GitHub i rejestruje obiekt wdrożenia za pośrednictwem interfejsu Deployments API.
Zapewnia to widoczną historię: który commit trafił na produkcję, kiedy to nastąpiło i kto tego dokonał.
environment:
name: production
url: https://myapp.example.comZatwierdzanie oczekującego uruchomienia
Gdy zadanie z bramką oczekuje, na stronie uruchomienia przepływu pracy zobaczysz żółty baner Review deployments.
- Otwórz uruchomienie na karcie Actions
- Kliknij
Review deployments - Wybierz środowisko i kliknij
Approve and deploylubReject
Możesz również dodać komentarz wyjaśniający decyzję.
Łączenie wielu bramek
Najsilniejsza bramka produkcyjna łączy kilka reguł:
- Wymagane osoby zatwierdzające (zatwierdzenie przez człowieka)
- Timer oczekiwania (czas na bezpieczne wycofanie)
- Ograniczenia gałęzi (tylko
main) - Sekrety środowiska (izolacja)
Połączenie tych mechanizmów tworzy solidny proces promowania zmian ze stagingu na produkcję.
Bezpieczne omijanie bramek
Czasami potrzebujesz awaryjnego hotfixu. Zamiast usuwać reguły ochrony, rozważ osobny, odpowiednio ograniczony przepływ pracy dla hotfixu z własnym rejestrowaniem i bardziej rygorystycznymi osobami zatwierdzającymi.
Nigdy nie wyłączaj bramek na stałe dla wygody — niweczy to cel mechanizmu bezpieczeństwa.
Szybki test
Sprawdź swoją wiedzę na temat bramek zatwierdzających wdrożenia na produkcję.
Podsumowanie
Dowiedziałeś się, jak dodawać bramki zatwierdzające dla wdrożeń na produkcję za pomocą środowisk GitHub.
- Używaj klucza
environment, aby wskazać chronione środowisko - Wymagane osoby zatwierdzające dodają zatwierdzenie przez człowieka
- Timery oczekiwania dodają czas na bezpieczne wycofanie
- Ograniczenia gałęzi i sekrety środowiska zapewniają izolację
Wspólnie te bramki sprawiają, że promowanie zmian ze stagingu na produkcję jest bezpieczne i możliwe do prześledzenia.
Ucz się CI/CD with GitHub Actions & DevOps Pipelines dzięki korepetycjom AI — za darmo
Pisz i uruchamiaj kod w przeglądarce, otrzymuj natychmiastową pomoc od korepetytora AI dostępnego 24/7 i kontynuuj naukę w sieci lub w aplikacji.
- Kursy
- 12
- Lekcje
- 48
Często zadawane pytania
Czy lekcja „Wdrażanie na produkcję z bramkami akceptacji” jest bezpłatna?
Tak — pełny tekst „Wdrażanie na produkcję z bramkami akceptacji” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu CI/CD with GitHub Actions & DevOps Pipelines, przejdź na CoddyKit PRO. Kurs CI/CD with GitHub Actions & DevOps Pipelines zawiera 4 lekcji w sumie.
Co nauczysz się w „Wdrażanie na produkcję z bramkami akceptacji”?
Dowiedz się, jak bezpiecznie promować kompilacje ze środowiska staging na produkcję, korzystając z reguł ochrony środowisk GitHub Actions, ręcznych akceptacji i bramek wdrożeniowych. Ćwiczysz CI/CD with GitHub Actions & DevOps Pipelines z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.
Czy potrzebuję doświadczenia, aby zacząć CI/CD with GitHub Actions & DevOps Pipelines?
Nie wymagamy żadnego doświadczenia. CI/CD with GitHub Actions & DevOps Pipelines w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 4 z 4.
Ile czasu zajmuje lekcja „Wdrażanie na produkcję z bramkami akceptacji”?
Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.
Czy mogę pisać i uruchamiać kod w tej lekcji CI/CD with GitHub Actions & DevOps Pipelines?
Tak. Każda lekcja CI/CD with GitHub Actions & DevOps Pipelines zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.
Wszystkie lekcje w tym kursie
- Wprowadzenie do Continuous Deployment
- Wdrażanie do środowiska stagingowego
- Zmienne środowiskowe i sekrety
- Wdrażanie na produkcję z bramkami akceptacji