Kompletny przepływ pracy dewelopera
Proszę połączyć GitHub Actions CI/CD, Azure Container Registry, Container Apps i Application Insights w kompletną wewnętrzną pętlę deweloperską — od zatwierdzenia zmian po obserwowalną produkcję.
Kompletny przepływ pracy dewelopera to bezpłatna lekcja Azure Fundamentals 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 Azure Fundamentals, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Azure Fundamentals zawiera 4 lekcji w sumie.
Nowoczesny cykl pracy dewelopera Azure
Nowoczesny przepływ pracy dewelopera Azure łączy kontrolę kodu źródłowego, CI/CD, infrastrukturę kontenerową i obserwowalność w płynny wewnętrzny cykl pracy — od zatwierdzenia kodu po produkcję z pełnym wglądem w jej działanie. Kluczowe elementy to: GitHub (źródło), GitHub Actions (potok kompilowania i wdrażania), Azure Container Registry (magazyn obrazów), Azure Container Apps (środowisko uruchomieniowe) oraz Application Insights (obserwowalność). Każda zmiana automatycznie trafia z laptopa dewelopera do środowiska produkcyjnego w ciągu kilku minut, a na każdym etapie obowiązują bramki jakości.
Krok 1: kontrola kodu źródłowego i strategia rozgałęziania
Uporządkuj swój kod w repozytorium GitHub, stosując strategię tworzenia opartą na głównej gałęzi lub strategię rozgałęziania GitFlow. W przypadku większości mikrousług tworzenie oparte na głównej gałęzi (krótkotrwałe gałęzie funkcji scalane codziennie z main) ogranicza konflikty integracji i upraszcza potok. Zastosuj reguły ochrony gałęzi dla main, aby przed scaleniem wymagać przeglądów pull requestów i pomyślnego przejścia kontroli CI. Plik CODEOWNERS gwarantuje, że zmiany w krytycznych usługach będą wymagały zatwierdzenia przez starszych inżynierów z odpowiedniego zespołu.
# Example .github/CODEOWNERS
# Require payments-team review for any changes under /src/payments/
/src/payments/ @payments-team
/infrastructure/ @platform-teamKrok 2: CI za pomocą GitHub Actions
Potok CI jest uruchamiany przy każdym pull requeście. Typowy przebieg wygląda następująco: pobranie kodu → przywrócenie zależności → uruchomienie testów jednostkowych → uruchomienie testów integracyjnych → zbudowanie obrazu Docker → przesłanie do Azure Container Registry. Obraz jest oznaczany symbolem SHA zatwierdzenia git, co umożliwia jego śledzenie. Użyj uwierzytelniania opartego na OIDC między GitHub Actions a Azure (za pośrednictwem tożsamości federacyjnej), aby uniknąć przechowywania wpisów tajnych jednostki usługi Azure w GitHub — jest to odpowiednik zarządzanej tożsamości dla potoków CI.
# .github/workflows/ci.yml (abbreviated)
name: CI
on: [pull_request]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Login to ACR
uses: azure/docker-login@v1
with:
login-server: myacr.azurecr.io
username: ${{ secrets.AZURE_CLIENT_ID }}
password: ${{ secrets.AZURE_CLIENT_SECRET }}
- name: Build and push image
run: |
docker build -t myacr.azurecr.io/myapi:${{ github.sha }} .
docker push myacr.azurecr.io/myapi:${{ github.sha }}Krok 3: CD do środowiska przejściowego
Po pomyślnym zakończeniu potoku CI po scaleniu z main potok CD automatycznie wdraża aplikację w środowisku przejściowym. Potok aktualizuje znacznik obrazu aplikacji Container App do nowo utworzonego SHA, czeka, aż nowa rewizja będzie działać poprawnie, a następnie uruchamia testy dymne względem adresu URL środowiska przejściowego. Testy dymne sprawdzają, czy krytyczne punkty końcowe interfejsu API zwracają oczekiwane odpowiedzi. Jeśli testy dymne zakończą się niepowodzeniem, potok wycofuje zmianę, przełączając ruch przychodzący z powrotem na poprzednią rewizję bez żadnej ręcznej ingerencji.
# CD stage: update Container App to new image
- name: Deploy to staging
uses: azure/cli@v2
with:
azcliversion: latest
inlineScript: |
az containerapp update \
--name myapi-staging \
--resource-group myRG \
--image myacr.azurecr.io/myapi:${{ github.sha }}
- name: Run smoke tests
run: |
STAGING_URL=$(az containerapp show --name myapi-staging \
--resource-group myRG \
--query 'properties.configuration.ingress.fqdn' -o tsv)
curl -f https://$STAGING_URL/health || exit 1Krok 4: bramka zatwierdzenia dla środowiska produkcyjnego
Po zatwierdzeniu środowiska przejściowego potok CD zatrzymuje się na bramce zatwierdzenia. Funkcja Environment protections w GitHub Actions umożliwia skonfigurowanie wymaganych recenzentów dla środowiska production. Potok wysyła powiadomienie Slack do inżyniera dyżurnego, który przed zatwierdzeniem analizuje wyniki testów środowiska przejściowego, różnice oraz wszystkie otwarte incydenty. Dopiero po zatwierdzeniu potok przechodzi do wdrożenia tego samego obrazu SHA w środowisku produkcyjnym. Ten etap z udziałem człowieka ma kluczowe znaczenie w przypadku usług o dużym ruchu lub podlegających regulacjom.
# In GitHub: create 'production' environment with required reviewers
# .github/workflows/cd.yml (abbreviated)
jobs:
deploy-production:
environment:
name: production
url: https://myapi.contoso.com
needs: deploy-staging
steps:
- name: Deploy to production
uses: azure/cli@v2
with:
inlineScript: |
az containerapp update \
--name myapi \
--resource-group myRG \
--image myacr.azurecr.io/myapi:${{ github.sha }}Krok 5: obserwowalność środowiska produkcyjnego
Po wdrożeniu w środowisku produkcyjnym Application Insights zapewnia wgląd w czasie rzeczywistym. Zestaw SDK App Insights (lub automatyczna instrumentacja w przypadku obsługiwanych środowisk uruchomieniowych) śledzi: częstotliwość żądań, częstotliwość błędów i opóźnienia (trzy złote sygnały), wywołania zależności (do baz danych, Service Bus i innych interfejsów API) oraz wyjątki wraz z pełnymi śladami stosu. Funkcja Application Map wizualizuje sposób wywoływania się usług i wskazuje zależności, które w największym stopniu przyczyniają się do błędów lub opóźnień.
# Python: Add Application Insights SDK
from opencensus.ext.azure.log_exporter import AzureLogHandler
from opencensus.ext.azure.trace_exporter import AzureExporter
from opencensus.trace.samplers import ProbabilitySampler
from opencensus.trace.tracer import Tracer
tracer = Tracer(
exporter=AzureExporter(connection_string='InstrumentationKey=<key>'),
sampler=ProbabilitySampler(1.0)
)Łączenie wdrożeń ze śladami
Użyj funkcji Application Insights Annotations, aby oznaczać zdarzenia wdrożeń na wykresach metryk. Po utworzeniu adnotacji wydania (za pomocą akcji GitHub Actions azure/appinsights-annotation) pojawia się ona jako pionowa linia na wszystkich wykresach metryk App Insights. Dzięki temu od razu widać, czy skok opóźnień lub wzrost liczby błędów koreluje z niedawnym wdrożeniem, co znacznie skraca średni czas diagnozowania (MTTD) podczas incydentów.
# Create a release annotation in Application Insights
- name: Annotate release in App Insights
uses: azure/appinsights-annotation@v1
with:
appInsightsResourceName: myAppInsights
resourceGroupName: myRG
releaseName: '${{ github.run_id }}-${{ github.sha }}'Automatyczne wycofanie przy skoku liczby błędów
W przypadku najbardziej odpornych potoków należy wdrożyć automatyczne wycofanie. Po wdrożeniu w środowisku produkcyjnym potok odczekuje 10 minut, a następnie wysyła do Application Insights zapytanie o częstotliwość błędów. Jeśli częstotliwość błędów przekroczy konfigurowalny próg (np. >5%), potok automatycznie wycofuje zmianę, aktualizując ruch przychodzący Container App tak, aby w 100% kierował go do poprzedniej rewizji. Ten wzorzec wdrażania progresywnego ogranicza zakres skutków nieudanego wdrożenia i pozwala zespołom wdrażać zmiany z większą pewnością, nawet w przypadku złożonych lub wrażliwych modyfikacji.
# Query App Insights error rate via REST (abbreviated)
QUERY='requests | where timestamp > ago(10m) | summarize failed = countif(success == false), total = count() | extend errorRate = round(100.0 * failed / total, 2)'
RESULT=$(az monitor app-insights query \
--apps myAppInsights \
--resource-group myRG \
--analytics-query "$QUERY" \
--query 'tables[0].rows[0][2]' -o tsv)
if [ $(echo '$RESULT > 5' | bc -l) -eq 1 ]; then
echo 'Error rate $RESULT% - rolling back!'
az containerapp ingress traffic set --name myapi --resource-group myRG --revision-weight stable=100
fiProduktywność deweloperów: programowanie lokalne z emulatorami
Deweloperzy powinni mieć możliwość lokalnego uruchamiania i testowania całego stosu bez łączenia się z produkcyjnymi zasobami Azure. Użyj Azure Storage Emulator (Azurite) do lokalnego przechowywania obiektów blob i kolejek, Cosmos DB Emulator do lokalnego testowania bazy danych oraz Service Bus Emulator do lokalnego przesyłania komunikatów. Zmienna środowiskowa AZURE_ENVIRONMENT=local może przełączyć DefaultAzureCredential na używanie parametrów połączenia wskazujących emulatory, podczas gdy ten sam kod w Azure korzysta z zarządzanej tożsamości. Docker Compose orkiestruje wszystkie lokalne zależności za pomocą jednego polecenia docker compose up.
# docker-compose.yml for local development
services:
azurite:
image: mcr.microsoft.com/azure-storage/azurite
ports:
- '10000:10000'
- '10001:10001'
cosmos-emulator:
image: mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator
ports:
- '8081:8081'Bezpieczeństwo w przepływie pracy dewelopera
Integruj zabezpieczenia na każdym etapie przepływu pracy dewelopera: Dependabot skanuje pull requesty w poszukiwaniu podatnych zależności; GitHub Advanced Security (skanowanie kodu za pomocą CodeQL) wykrywa podatności, takie jak SQL injection, oraz zakodowane na stałe wpisy tajne; Microsoft Defender for DevOps integruje się z GitHub, aby przedstawiać zalecenia dotyczące zabezpieczeń Azure wraz ze zmianami kodu; natomiast skanowanie podatności ACR Defender sprawdza obrazy kontenerów pod kątem CVE w systemie operacyjnym i warstwie aplikacji po każdym przesłaniu. Wyniki kontroli bezpieczeństwa pojawiają się jako komentarze w pull requestach, dzięki czemu można się nimi zająć przed scaleniem.
Połączenie wszystkich elementów
Kompletny przepływ pracy dewelopera jest ciągłą pętlą informacji zwrotnych: deweloper zatwierdza kod, CI buduje i testuje obraz kontenera, obraz jest przesyłany do ACR z oznaczeniem SHA zatwierdzenia, CD wdraża go w środowisku przejściowym i uruchamia testy dymne, człowiek zatwierdza wdrożenie produkcyjne, potok wdraża obraz w środowisku produkcyjnym i tworzy adnotację wydania, a Application Insights monitoruje częstotliwość błędów i automatycznie wycofuje zmianę po przekroczeniu progów. Infrastruktura jako kod (Bicep lub Terraform) przechowywana w tym samym repozytorium gwarantuje, że konfiguracja potoku, Container App i monitorowania jest objęta kontrolą wersji wraz z kodem aplikacji.
Szybkie sprawdzenie
Sprawdź swoją znajomość zagadnień Microsoft Azure Fundamentals (AZ-900) omówionych w tej lekcji.
Podsumowanie lekcji
W tej lekcji dowiedzieli się Państwo, że kompleksowy przepływ pracy dewelopera łączy kontrolę kodu źródłowego GitHub, CI/CD GitHub Actions, Azure Container Registry, Container Apps i Application Insights, adnotacje wydań korelują wdrożenia ze zmianami metryk, przyspieszając diagnozowanie incydentów, a automatyczne wycofanie na podstawie zapytań o częstotliwość błędów ogranicza zakres skutków nieudanych wdrożeń. W następnej części przejdziemy do przygotowania do egzaminu, obejmującego kompleksowy przegląd pojęć związanych z chmurą i architekturą Azure.
Ucz się Azure Fundamentals 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
- 30
- Lekcje
- 120
Często zadawane pytania
Czy lekcja „Kompletny przepływ pracy dewelopera” jest bezpłatna?
Tak — pełny tekst „Kompletny przepływ pracy dewelopera” 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 Azure Fundamentals, przejdź na CoddyKit PRO. Kurs Azure Fundamentals zawiera 4 lekcji w sumie.
Co nauczysz się w „Kompletny przepływ pracy dewelopera”?
Proszę połączyć GitHub Actions CI/CD, Azure Container Registry, Container Apps i Application Insights w kompletną wewnętrzną pętlę deweloperską — od zatwierdzenia zmian po obserwowalną produkcję. Ćwiczysz Azure Fundamentals 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ąć Azure Fundamentals?
Nie wymagamy żadnego doświadczenia. Azure Fundamentals 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 „Kompletny przepływ pracy dewelopera”?
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 Azure Fundamentals?
Tak. Każda lekcja Azure Fundamentals 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
- Tożsamość zarządzana do uwierzytelniania bez haseł
- Azure Service Bus do komunikacji rozdzielonej
- Azure Container Apps
- Kompletny przepływ pracy dewelopera