Πρακτικός οδηγός για staging slots, σωστά settings, warm-up, ελέγχους, swap και rollback, με εξήγηση του γιατί σε κάθε βήμα.
Ένα deployment μπορεί να ολοκληρωθεί επιτυχώς και η εφαρμογή να αποτυγχάνει στο πρώτο πραγματικό αίτημα.
Το build πέρασε. Τα αρχεία ανέβηκαν. Το pipeline έγινε πράσινο. Όμως μια σύνδεση με τη βάση, ένα ξεχασμένο secret ή ένα σφάλμα κατά την εκκίνηση αρκεί για να μετατρέψει την επόμενη επίσκεψη ενός χρήστη σε HTTP 500.
Τα Deployment Slots του Azure App Service μας επιτρέπουν να εγκαταστήσουμε και να ελέγξουμε τη νέα έκδοση πριν αναλάβει την εξυπηρέτηση των χρηστών. Έτσι, το deployment και η διάθεση της έκδοσης στο κοινό γίνονται δύο διακριτά βήματα.
Σε αυτόν τον οδηγό θα ακολουθήσουμε μια συγκεκριμένη διαδρομή:
Build → Deploy στο staging → Έλεγχοι → Swap → Παρακολούθηση
↓
Rollback, αν χρειαστεί
Θα δούμε και τον λόγο ύπαρξης κάθε βήματος. Γιατί το ζητούμενο είναι να γνωρίζουμε με ποια στοιχεία αποφασίζουμε ότι μια έκδοση είναι έτοιμη για production.
Τι είναι τα Deployment Slots
Ένα deployment slot είναι μια ενεργή εφαρμογή μέσα στο ίδιο App Service, με δικό της hostname. Συνήθως κρατάμε δύο slots:
- Production, που εξυπηρετεί τους χρήστες.
- Staging, όπου προετοιμάζουμε την επόμενη έκδοση.
Τα deployment slots διατίθενται στα tiers Standard, Premium και Isolated. Το διαθέσιμο πλήθος εξαρτάται από το plan. Microsoft Learn για τα deployment slots.
Ας υποθέσουμε ότι έχουμε την έκδοση v1 σε production και θέλουμε να διαθέσουμε τη v2:
| Στάδιο | Production | Staging |
|---|---|---|
| Πριν από την αλλαγή | v1 | — |
| Μετά το deployment | v1 | v2 |
| Μετά τους ελέγχους | v1 | v2, ελεγμένη |
| Μετά το swap | v2 | v1 |
| Αν κάνουμε rollback με νέο swap | v1 | v2 |
Αυτή είναι μια πρακτική εφαρμογή της λογικής blue-green deployment: προετοιμάζουμε μια δεύτερη έκδοση και αλλάζουμε ποια εξυπηρετεί το production. Η Microsoft προτείνει deployment σε nonproduction slot, ελέγχους και προώθηση μέσω swap. Deployment best practices.
Πώς βοηθούν στην ασφάλεια του release
Σκεφτείτε μια εφαρμογή παραγγελιών. Η νέα έκδοση λειτουργεί τοπικά, αλλά στο Azure δεν μπορεί να διαβάσει ένα απαραίτητο secret.
Με έλεγχο στο staging, έχουμε τη δυνατότητα να εντοπίσουμε το πρόβλημα πριν προωθήσουμε την έκδοση. Η απόφαση για release περιμένει μέχρι να έχουμε λειτουργική εφαρμογή και επιτυχημένους ελέγχους.
Αν εμφανιστεί πρόβλημα μετά την προώθηση, η προηγούμενη έκδοση παραμένει διαθέσιμη στο άλλο slot. Αυτό μας δίνει μια συγκεκριμένη επιλογή επαναφοράς, αντί να αρχίζουμε εκείνη τη στιγμή να αναζητούμε παλιό build.
Οι πόροι του plan παραμένουν κοινόχρηστοι
Τα slots χρησιμοποιούν τους πόρους του ίδιου App Service plan. Ένα βαρύ load test στο staging μπορεί επομένως να επηρεάσει το production. Η δυνατότητα των slots δεν έχει ξεχωριστή χρέωση, αλλά εξακολουθούμε να πληρώνουμε το plan και τις συνδεδεμένες υπηρεσίες. App Service plans.
Για το runbook που ακολουθεί χρησιμοποιούμε το staging για προετοιμασία release και σύντομους λειτουργικούς ελέγχους. Τα απαιτητικά performance tests χρειάζονται κατάλληλο περιβάλλον και χωρητικότητα.
Βήμα 1 Προετοιμάζουμε εφαρμογή και κριτήρια επιτυχίας
Θα θεωρήσουμε ότι έχουμε ήδη:
- Ένα App Service που λειτουργεί, σε plan με υποστήριξη slots.
- Δικαιώματα δημιουργίας slot, αλλαγής ρυθμίσεων, deployment και swap.
- Ένα έτοιμο, ελεγμένο artifact της νέας έκδοσης, εδώ
release.zip. - Runtime στο App Service συμβατό με την εφαρμογή.
- Logs και μετρήσεις για να αξιολογήσουμε το release.
Το παράδειγμα αφορά App Service με deployment κώδικα μέσω ZIP. Οι εντολές γράφονται για Azure Cloud Shell σε Bash. Για custom containers αλλάζει το βήμα εγκατάστασης του artifact.
Πριν ξεκινήσουμε, ορίζουμε τι πρέπει να αποδείξει ο έλεγχος. Για μια εφαρμογή παραγγελιών, για παράδειγμα:
- Η εφαρμογή εκκινεί κανονικά.
- Μπορεί να επικοινωνήσει με τις απαραίτητες υπηρεσίες.
- Ένας χρήστης συνδέεται και βλέπει τις παραγγελίες του.
- Επιστρέφεται το αναμενόμενο release identifier.
Τα /health/ready και /version που χρησιμοποιούμε παρακάτω είναι endpoints που υλοποιούμε στην εφαρμογή μας. Το πρώτο πρέπει να επιστρέφει 200 όταν η εφαρμογή είναι έτοιμη και, για παράδειγμα, 503 όταν αποτυγχάνει μια κρίσιμη εξάρτηση. Το δεύτερο επιστρέφει την έκδοση του build, όπως {"version":"2.0.0"}.
Το readiness endpoint κρατά τους ελέγχους σύντομους, χωρίς εγγραφές ή άλλες παρενέργειες. Η απόκρισή του δεν πρέπει να αποκαλύπτει secrets ή εσωτερικά διαγνωστικά στοιχεία.
Γιατί έχει σημασία: με συγκεκριμένα κριτήρια, το «μου άνοιξε η αρχική σελίδα» παύει να είναι ο μοναδικός έλεγχος πριν από το release.
Βήμα 2 Δημιουργούμε το staging slot
Από το Azure Portal ανοίγουμε το App Service και επιλέγουμε Deployment → Deployment slots → Add. Δίνουμε όνομα staging και επιλέγουμε αντιγραφή configuration από το production.
Η αντιγραφή configuration δεν αντιγράφει τον κώδικα της εφαρμογής. Επίσης, ένα private endpoint δεν αντιγράφεται αυτόματα στο νέο slot. Δημιουργία deployment slot.
Η αντίστοιχη διαδικασία με Azure CLI είναι:
# Οι αποτυχίες σε pipelines εντολών πρέπει να είναι ορατές.
set -o pipefail
# Αντικαθιστούμε τις τιμές με τα δικά μας στοιχεία.
az account set --subscription "<SUBSCRIPTION_ID>"
RG="rg-myapp-prod"
APP="my-existing-app"
SLOT="staging"
az webapp deployment slot create \
--resource-group "$RG" \
--name "$APP" \
--slot "$SLOT" \
--configuration-source "$APP" \
--output none
Στο --configuration-source, το όνομα της εφαρμογής αναφέρεται στο production. Azure CLI για deployment slots.
Γιατί έχει σημασία: χρησιμοποιούμε το production configuration ως αφετηρία. Στο επόμενο βήμα προσαρμόζουμε όσα πρέπει να διαφέρουν, πριν εγκαταστήσουμε κώδικα που θα μπορούσε να χρησιμοποιήσει λάθος υπηρεσίες.
Βήμα 3 Ξεχωρίζουμε σωστά τις ρυθμίσεις κάθε περιβάλλοντος
Αυτό το βήμα χρειάζεται ιδιαίτερη προσοχή.
Ένας έλεγχος στο staging μπορεί να στείλει πραγματικό email ή να γράψει στην production βάση, αν η εφαρμογή χρησιμοποιεί τις αντίστοιχες συνδέσεις.
Για κάθε ρύθμιση αποφασίζουμε αν πρέπει να παραμένει συνδεδεμένη με το περιβάλλον. Στο Portal, μέσα στο αντίστοιχο slot, πηγαίνουμε στις Settings → Environment variables και ενεργοποιούμε Deployment slot setting όπου χρειάζεται. Τα slot-specific settings παραμένουν στο slot μετά την ολοκλήρωση του swap. Ρυθμίσεις εφαρμογής.
Ένα ενδεικτικό πλάνο είναι:
| Ρύθμιση | Production | Staging | Deployment slot setting |
|---|---|---|---|
| Σύνδεση βάσης | Production database | Test database | Ναι |
| Payment provider | Live λογαριασμός | Sandbox λογαριασμός | Ναι |
| Email provider | Κανονική αποστολή | Test inbox | Ναι |
| API εξωτερικής υπηρεσίας | Production endpoint | Test endpoint | Ναι |
Ελέγχουμε τις τιμές και τη σήμανση και στα δύο slots.
Για secrets χρησιμοποιούμε, όπου ταιριάζει, Azure Key Vault references, με διαφορετικά secrets ανά περιβάλλον και slot-specific ρυθμίσεις. Έτσι τα credentials διαχειρίζονται κεντρικά και δεν χρειάζεται να μπουν στο repository. Ελέγχουμε τόσο τα δικαιώματα ανάγνωσης όσο και τη δικτυακή πρόσβαση στο vault. Key Vault references.
Τα managed identities είναι ρυθμίσεις ανά slot. Ελέγχουμε ξεχωριστά τι μπορεί να προσπελάσει κάθε identity. Managed identities στο App Service.
Γιατί έχει σημασία: θέλουμε να προωθήσουμε μια έκδοση της εφαρμογής, διατηρώντας τις σωστές συνδέσεις για το περιβάλλον που θα την εκτελεί.
Οι αλλαγές στα app settings προκαλούν επανεκκίνηση της εφαρμογής. Προγραμματίζουμε την αρχική ρύθμιση του production ως αλλαγή υποδομής και την ολοκληρώνουμε πριν από τα τακτικά releases. Azure CLI configuration.
Βήμα 4 Προστατεύουμε την πρόσβαση στο staging
Το staging έχει δικό του hostname. Το ότι δεν του στέλνουμε production traffic δεν σημαίνει ότι το περιεχόμενό του είναι ιδιωτικό.
Ρυθμίζουμε πρόσβαση για την ομάδα και τον deployment runner μέσω των κατάλληλων access restrictions ή δικτυακών ελέγχων. Ελέγχουμε και το SCM/Kudu endpoint, που έχει δικούς του κανόνες πρόσβασης. App Service access restrictions.
Γιατί έχει σημασία: μια ανέκδοτη λειτουργία μπορεί να είναι προσβάσιμη απευθείας από το hostname του staging. Οι κανόνες πρόσβασης καθορίζουν ποιος μπορεί να τη δει και ποιος μπορεί να εκτελέσει τους ελέγχους μας.
Στο παράδειγμα, τα επόμενα HTTP requests εκτελούνται από επιτρεπόμενο δίκτυο. Αν έχουμε περιορίσει την πρόσβαση σε VNet, χρησιμοποιούμε runner μέσα σε αυτό το δίκτυο.
Βήμα 5 Ρυθμίζουμε ουσιαστικό warm-up
Το warm-up δίνει στη νέα έκδοση χρόνο να προετοιμαστεί πριν αναλάβει production traffic.
Ορίζουμε το endpoint που θα ελέγχεται κατά το swap και απαιτούμε HTTP 200:
# Αρχική ρύθμιση production. Μπορεί να προκαλέσει restart.
az webapp config appsettings set \
--resource-group "$RG" \
--name "$APP" \
--settings \
WEBSITE_SWAP_WARMUP_PING_PATH=/health/ready \
WEBSITE_SWAP_WARMUP_PING_STATUSES=200 \
--output none
# Ίδια πολιτική στο staging.
az webapp config appsettings set \
--resource-group "$RG" \
--name "$APP" \
--slot "$SLOT" \
--settings \
WEBSITE_SWAP_WARMUP_PING_PATH=/health/ready \
WEBSITE_SWAP_WARMUP_PING_STATUSES=200 \
--output none
Χωρίς ρητή ρύθμιση των αποδεκτών statuses, το swap warm-up θεωρεί έγκυρους όλους τους HTTP κωδικούς. Επομένως, ακόμη και μια απόκριση σφάλματος μπορεί να θεωρηθεί επαρκής. App settings για deployment slots.
Το endpoint πρέπει να υπάρχει και στην προηγούμενη και στη νέα έκδοση, ώστε να μπορεί να χρησιμοποιηθεί και κατά την επαναφορά. Ελέγχουμε επίσης ότι τα probes φτάνουν στην εφαρμογή χωρίς redirect σε σελίδα σύνδεσης.
Γιατί έχει σημασία: ο έλεγχος αποδεικνύει όσα έχουμε υλοποιήσει σε αυτόν. Μια στατική απόκριση 200 δεν ελέγχει αν λειτουργεί η σύνδεση με τη βάση.
Το App Service Health check λειτουργεί συμπληρωματικά
Στο Portal, από Monitoring → Health check, μπορούμε να ορίσουμε το ίδιο readiness path για συνεχή παρακολούθηση των instances. Το Health check βοηθά στη δρομολόγηση αιτημάτων μακριά από unhealthy instances και είναι διαφορετικός μηχανισμός από το swap warm-up.
Κρατάμε συνεπή ρύθμιση στα δύο slots: το Health check configuration ανταλλάσσεται στο swap. Για να αξιοποιείται πλήρως η δυνατότητα χρειάζονται τουλάχιστον δύο ενεργά replicas της εφαρμογής και επαρκής χωρητικότητα. App Service Health check.
Βήμα 6 Κάνουμε deploy τη νέα έκδοση στο staging
Το release.zip περιέχει την έτοιμη εφαρμογή στη ρίζα του, χωρίς έναν επιπλέον εξωτερικό φάκελο. Για .NET, για παράδειγμα, πακετάρουμε τα περιεχόμενα του αποτελέσματος του dotnet publish. Δημιουργία ZIP package.
Από τον φάκελο όπου βρίσκεται το artifact εκτελούμε:
az webapp deploy \
--resource-group "$RG" \
--name "$APP" \
--slot "$SLOT" \
--src-path ./release.zip \
--type zip
Το --slot "$SLOT" καθορίζει τον προορισμό του deployment. Azure CLI webapp deploy.
Γιατί έχει σημασία: εγκαθιστούμε τη νέα έκδοση στον χώρο προετοιμασίας. Η απόφαση να την προωθήσουμε στο production ακολουθεί τους ελέγχους.
Στο pipeline κρατάμε το artifact συνδεδεμένο με συγκεκριμένο commit ή release identifier. Η έκδοση που ελέγχουμε είναι αυτή που θα προωθήσουμε, χωρίς ενδιάμεσο rebuild.
Βήμα 7 Ελέγχουμε την εφαρμογή στο staging
Ανακτούμε τα πραγματικά hostnames από το Azure:
STAGING_HOST=$(az webapp show \
--resource-group "$RG" \
--name "$APP" \
--slot "$SLOT" \
--query defaultHostName --output tsv)
PROD_HOST=$(az webapp show \
--resource-group "$RG" \
--name "$APP" \
--query defaultHostName --output tsv)
Έπειτα ελέγχουμε readiness και έκδοση:
curl --fail-with-body --silent --show-error --max-time 20 \
--write-out '\nHTTP %{http_code}\n' \
"https://$STAGING_HOST/health/ready"
curl --fail-with-body --silent --show-error --max-time 20 \
"https://$STAGING_HOST/version" \
| jq -e '.version == "2.0.0"'
Για το readiness περιμένουμε ακριβώς HTTP 200. Στον δεύτερο έλεγχο αντικαθιστούμε το 2.0.0 με την αναμενόμενη έκδοση του artifact. Αν τα endpoints απαιτούν application authentication, τα requests χρειάζονται τα κατάλληλα credentials.
Ακολουθούν τα smoke tests: σύντομοι έλεγχοι βασικών λειτουργιών. Στο παράδειγμά μας δοκιμάζουμε σύνδεση χρήστη, ανάγνωση παραγγελιών και μια ελεγχόμενη δοκιμαστική παραγγελία στο test περιβάλλον.
Ελέγχουμε παράλληλα logs και exceptions. Ένας λειτουργικός έλεγχος μπορεί να φαίνεται επιτυχημένος, ενώ μια δευτερεύουσα διεργασία αποτυγχάνει στο παρασκήνιο.
Γιατί έχει σημασία: ελέγχουμε συμπεριφορά, πρόσβαση στις εξαρτήσεις και ταυτότητα της έκδοσης. Ένα επιτυχημένο upload αποδεικνύει ότι μεταφέρθηκε το artifact.
Βήμα 8 Κάνουμε τελικό έλεγχο και swap
Πριν προχωρήσουμε, σταματάμε παράλληλα deployments ή άλλες αλλαγές στο ίδιο staging slot. Θέλουμε να προωθήσουμε ακριβώς την έκδοση που μόλις ελέγξαμε.
Προαιρετικός έλεγχος με swap with preview
Το preview εφαρμόζει τις σχετικές ρυθμίσεις του target στο source slot και παύει τη διαδικασία πριν από την αλλαγή δρομολόγησης. Έτσι μπορούμε να ελέγξουμε τη νέα έκδοση με τις ρυθμίσεις του production. Δεν υποστηρίζεται όταν είναι ενεργό το App Service Authentication σε οποιοδήποτε από τα δύο slots. Swap with preview.
az webapp deployment slot swap \
--resource-group "$RG" \
--name "$APP" \
--slot "$SLOT" \
--target-slot production \
--action preview
Εδώ το staging μπορεί να χρησιμοποιεί production connections. Περιορίζουμε τους ελέγχους σε ελεγχόμενες ενέργειες χωρίς παρενέργειες και έχουμε ήδη αντιμετωπίσει migrations κατά την εκκίνηση και background workers.
Η identity και η VNet integration παραμένουν του source slot. Συνεπώς ελέγχουμε την πρόσβασή του στις production εξαρτήσεις κατά την προετοιμασία, ακόμη και για swap χωρίς preview. Ρυθμίσεις που δεν ανταλλάσσονται.
Αν αποφασίσουμε να ακυρώσουμε το εκκρεμές preview:
az webapp deployment slot swap \
--resource-group "$RG" \
--name "$APP" \
--slot "$SLOT" \
--target-slot production \
--action reset
Προώθηση στο production
Όταν οι έλεγχοι έχουν ολοκληρωθεί, εκτελούμε:
az webapp deployment slot swap \
--resource-group "$RG" \
--name "$APP" \
--slot "$SLOT" \
--target-slot production \
--action swap
Η εντολή εκτελεί κανονικό swap ή ολοκληρώνει ένα επιτυχημένο preview. Επιλέγουμε source το staging και target το production. Azure CLI slot swap.
Το App Service προετοιμάζει τη νέα έκδοση πριν αλλάξει τη δρομολόγηση. Αυτό περιορίζει τη διακοπή που προκαλεί ένα release. Η συνολική διαθεσιμότητα εξακολουθεί να εξαρτάται από την εφαρμογή, τις εξαρτήσεις και τον χειρισμό επανεκκινήσεων. Αρχιτεκτονικές πρακτικές για το App Service, οδηγός αξιοπιστίας.
Γιατί έχει σημασία: η προώθηση γίνεται ως συγκεκριμένη αλλαγή, αφού έχουμε συγκεντρώσει στοιχεία ότι η έκδοση είναι έτοιμη.
Βήμα 9 Επαληθεύουμε το production και παρακολουθούμε
Μετά το swap επαναλαμβάνουμε τους ελέγχους στο production:
curl --fail-with-body --silent --show-error --max-time 20 \
--write-out '\nHTTP %{http_code}\n' \
"https://$PROD_HOST/health/ready"
curl --fail-with-body --silent --show-error --max-time 20 \
"https://$PROD_HOST/version" \
| jq -e '.version == "2.0.0"'
Αν η εφαρμογή εξυπηρετείται μέσω custom domain, Front Door ή άλλου proxy, ελέγχουμε και το πραγματικό δημόσιο URL. Εκεί επαληθεύουμε ολόκληρη τη διαδρομή που ακολουθούν οι χρήστες.
Στο εργαλείο παρακολούθησης, όπως το Application Insights, συγκρίνουμε με την προηγούμενη κατάσταση:
- Αποτυχημένα requests και νέες exceptions.
- Χρόνους απόκρισης, ιδιαίτερα p95.
- Αποτυχίες επικοινωνίας με εξαρτήσεις.
- CPU, μνήμη και επανεκκινήσεις.
- Επιτυχία βασικών επιχειρησιακών ενεργειών, όπως η ολοκλήρωση παραγγελίας.
Πριν από το release έχουμε ορίσει ποια επιδείνωση απαιτεί επαναφορά και ποιος παίρνει την απόφαση. Το διάστημα παρακολούθησης πρέπει να καλύπτει αντιπροσωπευτική κίνηση και τις σημαντικές διεργασίες της εφαρμογής. Safe deployment practices.
Γιατί έχει σημασία: μια αστοχία μπορεί να εμφανίζεται μόνο σε συγκεκριμένους χρήστες ή δεδομένα. Η παρακολούθηση συνδέει το release με την πραγματική λειτουργία της υπηρεσίας.
Βήμα 10 Κάνουμε rollback όταν χρειάζεται
Αν η προηγούμενη έκδοση παραμένει στο staging και είναι συμβατή με την τρέχουσα κατάσταση των δεδομένων, μπορούμε να ανταλλάξουμε ξανά τα ίδια slots:
az webapp deployment slot swap \
--resource-group "$RG" \
--name "$APP" \
--slot "$SLOT" \
--target-slot production \
--action swap
Ακόμη και για rollback, κρατάμε το production ως target. Η ανταλλαγή επαναφέρει την προηγούμενη έκδοση στο production. Azure CLI slot swap.
Ελέγχουμε ξανά readiness, την προηγούμενη έκδοση στο /version και τις βασικές λειτουργίες. Μέχρι να επιβεβαιωθεί το release, αποφεύγουμε νέο deployment στο staging που θα αντικαταστήσει την έκδοση επαναφοράς. Διατήρηση προηγούμενης έκδοσης για επαναφορά.
Γιατί έχει σημασία: η δυνατότητα rollback είναι χρήσιμη όταν ξέρουμε τι επαναφέρουμε, πότε θα το κάνουμε και πώς θα επιβεβαιώσουμε το αποτέλεσμα.
Η βάση δεδομένων χρειάζεται δικό της σχέδιο
Το slot swap δεν αναιρεί database migrations ή αλλαγές στα δεδομένα.
Ας υποθέσουμε ότι η v2 καταργεί τη στήλη FullName και χρησιμοποιεί τις FirstName και LastName. Αν επαναφέρουμε τη v1, εκείνη θα συνεχίσει να ζητά τη στήλη που έχει ήδη διαγραφεί.
Για τέτοιες αλλαγές σχεδιάζουμε σταδιακή μετάβαση, γνωστή ως expand and contract:
- Προσθέτουμε τα νέα πεδία, διατηρώντας το παλιό schema λειτουργικό.
- Διαθέτουμε έκδοση που υποστηρίζει τη μεταβατική κατάσταση και κρατά τα δεδομένα συμβατά με την προηγούμενη έκδοση για το διάστημα rollback.
- Μεταφέρουμε τα υπάρχοντα δεδομένα και ελέγχουμε τη συνέπειά τους.
- Αφαιρούμε το παλιό πεδίο σε επόμενο release, όταν δεν απαιτείται πλέον η παλιά έκδοση.
Τα migrations εκτελούνται ως ελεγχόμενο βήμα, με δικό τους σχέδιο αποτυχίας. Αποφεύγουμε ανεξέλεγκτες καταστροφικές αλλαγές κατά την εκκίνηση, ιδιαίτερα όταν το preview μπορεί να συνδέσει τη νέα έκδοση με production δεδομένα.
Η επαναφορά αλλαγών σε schema και άλλα stateful στοιχεία απαιτεί ιδιαίτερη πρόβλεψη. Well-Architected guidance για ασφαλή deployments.
Background jobs και κατάσταση εφαρμογής
Δύο ενεργές εκδόσεις μπορούν να εκτελούν δύο φορές μια εργασία, αν δεν έχουμε σχεδιάσει τον συντονισμό τους. Για queue consumers, schedulers και αποστολές email προβλέπουμε απομονωμένες δοκιμαστικές ουρές, συντονισμό εκτέλεσης και idempotency, δηλαδή ασφαλή χειρισμό επαναλαμβανόμενης επεξεργασίας.
Για WebJobs υπάρχουν ειδικές ρυθμίσεις απενεργοποίησης στο staging. Ελέγχουμε όμως ολόκληρη τη συμπεριφορά κατά το swap και το preview: η προσωρινή εφαρμογή production settings χρειάζεται πρόβλεψη και για τυχόν flags που ενεργοποιούν εργασίες. WebJobs στο App Service.
Εξετάζουμε επίσης τι χρειάζεται να επιβιώσει από ένα restart: sessions, αρχεία χρηστών και εργασίες μεγάλης διάρκειας. Τα αποθηκεύουμε και τα διαχειριζόμαστε με τρόπο που επιτρέπει τη μετάβαση μεταξύ εκδόσεων.
Πώς μεταφέρουμε τη διαδικασία σε pipeline
Αφού κατανοήσουμε τη ροή, την αυτοματοποιούμε:
Build και tests
↓
Αποθήκευση artifact με συγκεκριμένη έκδοση
↓
Deploy στο staging
↓
Readiness και smoke tests
↓
Έγκριση ή αυτόματα κριτήρια προώθησης
↓
Swap στο production
↓
Επαλήθευση και παρακολούθηση
↓
Ολοκλήρωση release ή ελεγχόμενο rollback
Κάθε αποτυχία πρέπει να σταματά την προώθηση. Επίσης, επιτρέπουμε ένα release κάθε φορά ανά εφαρμογή, ώστε ένα δεύτερο pipeline να μη μεταβάλει το slot που ελέγχει το πρώτο.
Η αυτοματοποίηση αποκτά αξία όταν επαναλαμβάνει ελέγχους με σαφή κριτήρια. Καταγράφουμε commit, artifact, αποτελέσματα ελέγχων και χρόνο swap, ώστε να γνωρίζουμε τι εκτελείται και γιατί προωθήθηκε.
Checklist πριν από το release
- [ ] Το staging εκτελεί το αναμενόμενο artifact.
- [ ] Οι συνδέσεις, τα secrets και τα slot-specific settings είναι σωστά.
- [ ] Έχουν ελεγχθεί δικαιώματα identity και δικτυακή πρόσβαση.
- [ ] Το readiness endpoint ελέγχει κρίσιμες εξαρτήσεις και το warm-up απαιτεί
200. - [ ] Τα smoke tests έχουν περάσει.
- [ ] Έχουμε αντιμετωπίσει migrations και background jobs.
- [ ] Δεν εκτελείται άλλο deployment στο ίδιο slot.
- [ ] Έχουμε ορίσει κριτήρια rollback και κρατάμε την προηγούμενη έκδοση διαθέσιμη.
- [ ] Μετά το swap θα ελέγξουμε το πραγματικό δημόσιο URL και τη συμπεριφορά των χρηστών.
Τα deployment slots μάς δίνουν χρόνο για έλεγχο πριν από την προώθηση και μια πρακτική διαδρομή επιστροφής μετά από αυτήν. Η σημασία τους φαίνεται τη στιγμή που ένα release παρουσιάζει πρόβλημα: έχουμε ήδη προετοιμάσει τις επόμενες κινήσεις μας.
Top comments (0)