Ημέρα κυκλοφορίας στην ανάπτυξη εφαρμογών: ουσία, στάδια και προετοιμασία
Ημέρα κυκλοφορίας (release day) — η προγραμματισμένη ημερομηνία κυκλοφορίας μιας νέας έκδοσης της εφαρμογής για κινητά, που περιλαμβάνει την προετοιμασία του build, την αξιολόγηση από το κατάστημα, το σταδιακό rollout και την παρακολούθηση. Για εφαρμογές iOS, η διαδικασία ξεκινά με τη μεταφόρτωση του build στο App Store Connect 24-48 ώρες πριν από την προγραμματισμένη ημερομηνία κυκλοφορίας λόγω της υποχρεωτικής αξιολόγησης της Apple. Για Android — δημιουργία και μεταφόρτωση στο Google Play Console, όπου η διαδικασία αξιολόγησης συνήθως διαρκεί 1-4 ώρες. Σύμφωνα με το Apple Developer Guidelines (2025), το 90% των builds περνούν την αξιολόγηση εντός 24 ωρών. Staged rollout επιτρέπει την ελαχιστοποίηση των επιπτώσεων σε περίπτωση εντοπισμού σφαλμάτων μετά τη δημοσίευση.
Βασικά σημεία
- Release day — σύνολο ενεργειών από τη δημιουργία build έως την παρακολούθηση μετά το rollout
- Staged rollout — σταδιακή κυκλοφορία: 1%, 10%, 50%, 100%
- Smoke testing — τελικός έλεγχος του build πριν από την αποστολή στο κατάστημα
- Rollback plan — προετοιμασμένο σενάριο επαναφοράς για κρίσιμα σφάλματα
- Release retrospective — ανάλυση της διαδικασίας μετά την ολοκλήρωση του rollout στο 100%
Τι είναι η ημέρα κυκλοφορίας και πώς να προετοιμαστείτε
Ημέρα κυκλοφορίας — δεν είναι απλώς η στιγμή πατήματος του κουμπιού Publish. Είναι μια συντονισμένη διαδικασία στην οποία συμμετέχουν προγραμματιστές, QA, devops, product managers και μερικές φορές η υποστήριξη. Η προετοιμασία ξεκινά 2-3 εβδομάδες πριν από την ημέρα κυκλοφορίας: συμφωνία scope, code freeze, δοκιμές παλινδρόμησης, προετοιμασία release notes και υλικού μάρκετινγκ. Όσο πιο ενδελεχής είναι η προετοιμασία, τόσο πιο ομαλά κυλά η ίδια η ημέρα κυκλοφορίας.
Η λίστα ελέγχου προετοιμασίας για την ημέρα κυκλοφορίας περιλαμβάνει: τελική εκτέλεση QA (regression + smoke suite) στο build κυκλοφορίας· έλεγχο μεταδεδομένων στα καταστήματα (όνομα, περιγραφή, στιγμιότυπα οθόνης, keywords)· συνεννόηση για το ποσοστό σταδιακού rollout με τον product manager· προετοιμασία σχεδίου rollback (ποιο tag να επαναφερθεί, πόσο χρόνο θα πάρει)· ειδοποίηση της ομάδας και των σχετικών υπηρεσιών για την επικείμενη κυκλοφορία. Release checklist πρέπει να αυτοματοποιείται μέσω CI/CD — για παράδειγμα, ως GitHub Actions workflow που ελέγχει όλα τα σημεία πριν από τη δημιουργία του tag κυκλοφορίας.
Ένα σημαντικό στοιχείο προετοιμασίας — περίοδος blackout (περίοδος κατά την οποία απαγορεύονται οι αναπτύξεις στην παραγωγή). Συνήθως το blackout εφαρμόζεται 48 ώρες πριν από την ημέρα κυκλοφορίας και αίρεται 24 ώρες μετά την επιτυχή ολοκλήρωση rollout στο 100%. Αυτό αποτρέπει τυχαίες αναπτύξεις που θα μπορούσαν να διαταράξουν την κυκλοφορία. Change freeze κατά την περίοδο blackout ισχύει για όλες τις υπηρεσίες που σχετίζονται με την κυκλοφορία.
Προετοιμασία build: code freeze, tagging και δημιουργία
24-48 ώρες πριν από την ημέρα κυκλοφορίας εφαρμόζεται code freeze — πλήρης διακοπή αλλαγών στον κώδικα. Οι προγραμματιστές μεταβαίνουν στην προετοιμασία τεκμηρίωσης και release notes. Ο DevOps δημιουργεί το build κυκλοφορίας από ένα σταθερό tag (π.χ. v2.6.0-rc1). Το build περνά από πλήρη σουίτα παλινδρόμησης (αυτόματες + χειροκίνητες δοκιμές). Αν βρεθούν κρίσιμα σφάλματα — διορθώνονται πριν από το code freeze ή η κυκλοφορία αναβάλλεται. Release candidate (RC) — build που έχει περάσει το QA και είναι έτοιμο για αποστολή στο κατάστημα.
Tagging στο Git: δημιουργείται ένα annotated tag (git tag -a v2.6.0 -m "Release v2.6.0"). Το CI/CD pipeline δημιουργεί AAB (Android App Bundle) για το Google Play και IPA (iOS App Store Package) για το Apple App Store. Στο build επισυνάπτονται: αρχείο με αθροίσματα ελέγχου (SHA256), changelog και λίστα γνωστών προβλημάτων (known issues). Reproducible builds — ιδανική πρακτική όπου η εκ νέου δημιουργία από το ίδιο tag δίνει δυαδικά πανομοιότυπο αποτέλεσμα.
bash
# Pipeline κυκλοφορίας — δημιουργία tag και build
# Υποθέτει ότι το code freeze είναι ήδη ενεργό
# Δημιουργήστε branch κυκλοφορίας από το develop
git checkout develop
git pull origin develop
git checkout -b release/v2.6.0
git push origin release/v2.6.0
# Code freeze: οι κανόνες προστασίας branch μπλοκάρουν νέα PR
# Εκτελέστε τη σουίτα παλινδρόμησης στο CI/CD
./gradlew clean testReleaseUnitTest connectedReleaseTest
# Δημιουργήστε tag κυκλοφορίας μετά από επιτυχή QA
git tag -a v2.6.0 -m "Release v2.6.0: payment module, dark mode"
git push origin v2.6.0
# Δημιουργήστε δυαδικό αρχείο κυκλοφορίας μέσω CI/CD
# Το fastlane build_release παράγει AAB + καθολικό APK
fastlane build_releaseΣημαντικό: το version bump (ενημέρωση version code και version name) γίνεται πριν από το code freeze. Μετά το code freeze η έκδοση δεν αλλάζει. Για Android: versionCode — μονότονα αυξανόμενος ακέραιος αριθμός· versionName — σημασιολογική έκδοση (2.6.0). Για iOS: CFBundleVersion (build number) και CFBundleShortVersionString (σημασιολογική έκδοση). Versioning πρέπει να αυτοματοποιείται στο gradle/xcconfig.
Μεταφόρτωση στο κατάστημα και αξιολόγηση
Για iOS: το build μεταφορτώνεται μέσω Xcode, Transporter ή fastlane στο App Store Connect. Μετά τη μεταφόρτωση, το build περνά από αυτόματο έλεγχο Apple (processing), στη συνέχεια αποστέλλεται για χειροκίνητη αξιολόγηση. Μέσος χρόνος αξιολόγησης — 24 ώρες, αλλά μπορεί να κυμαίνεται από 1 ώρα έως 7 ημέρες ανάλογα με τον φόρτο των αξιολογητών Apple και τις απαιτήσεις συμμόρφωσης. Expedited review — αίτημα για επισπευσμένη αξιολόγηση για κρίσιμες διορθώσεις σφαλμάτων (διαθέσιμο το πολύ μία φορά το μήνα, δεν είναι εγγυημένο).
Για Android: το build μεταφορτώνεται μέσω του Google Play Console. Η Google χρησιμοποιεί συνδυαστική προσέγγιση: αυτόματη δοκιμή (accessibility, malware, policy compliance) + επιλεκτική χειροκίνητη αξιολόγηση. Μέσος χρόνος αξιολόγησης — 1-4 ώρες. Internal test track και Closed track επιτρέπουν την τελική δοκιμή πριν από τη δημοσίευση στο Production track. Συνιστάται: 1-2 ημέρες για Internal test → 1 ημέρα για Closed beta → σταδιακό Production rollout.
Και για τις δύο πλατφόρμες, ο έλεγχος των μεταδεδομένων πριν από τη μεταφόρτωση του build είναι κρίσιμος: όνομα εφαρμογής, περιγραφή (short + full), στιγμιότυπα οθόνης για κάθε υποστηριζόμενη συσκευή (iPhone 6.5", 5.5", iPad, Android phone, tablet), keywords (iOS) ή store listing experiments (Android). Ένα σφάλμα στα μεταδεδομένα μπορεί να καθυστερήσει την αξιολόγηση για μια επιπλέον ημέρα. App metadata πρέπει να είναι μεταφρασμένη σε όλες τις υποστηριζόμενες γλώσσες.
Staged rollout: πώς να κυκλοφορήσετε χωρίς ρίσκο
Staged rollout (gradual rollout, staged deployment) — στρατηγική όπου η νέα έκδοση γίνεται διαθέσιμη στους χρήστες όχι άμεσα, αλλά σταδιακά. Τυπικό σχήμα για ώριμη ομάδα: 1% των χρηστών (πρώτες 2-4 ώρες) → 10% (24 ώρες) → 25% (24 ώρες) → 50% (24 ώρες) → 100%. Κάθε στάδιο περιλαμβάνει παρακολούθηση μετρήσεων και έλεγχο απουσίας κρίσιμων σφαλμάτων. Staged rollout — το κύριο εργαλείο ελαχιστοποίησης κινδύνου στις κυκλοφορίες.
Το Google Play Console παρέχει ενσωματωμένο staged rollout: μπορείτε να ορίσετε το ποσοστό χρηστών και να προγραμματίσετε σταδιακή αύξηση. Για iOS App Store Connect δεν υπάρχει τέτοια ενσωματωμένη δυνατότητα — το staged rollout υλοποιείται μέσω Phased Release (αυτόματη αύξηση κάλυψης σε 7 ημέρες με δυνατότητα παύσης) ή μέσω server-side feature flags με γεωγραφική κατανομή. Phased release στο App Store Connect δίνει τη δυνατότητα Παύσης Κυκλοφορίας (Pause Release) σε περίπτωση εντοπισμού προβλημάτων.
Βασικές μετρήσεις για μετάβαση στο επόμενο στάδιο: crash-free rate (≥99.9% για τη νέα κυκλοφορία), ANR rate (Android, ≤0.1%), error rate στο backend API (≤0.5% 5xx), αξιολογήσεις χρηστών (όχι χαμηλότερες από την προηγούμενη έκδοση), apdex score (≥0.94). Αν κάποια μέτρηση υπερβεί το όριο — το rollout αναστέλλεται μέχρι να διευκρινιστούν τα αίτια. Go/no-go gate σε κάθε στάδιο — ευθύνη του release manager ή του on-call μηχανικού.
Παρακολούθηση μετά την κυκλοφορία: τι να ελέγχετε τις πρώτες ώρες
Οι πρώτες 4 ώρες μετά την κυκλοφορία — ο πιο κρίσιμος χρόνος. Η ομάδα παρακολουθεί το crash rate (Sentry, Firebase Crashlytics, App Center), το error rate 5xx στο backend, τα custom events (επιτυχείς πληρωμές, συνδέσεις, εγγραφές), τις αξιολογήσεις χρηστών στο App Store και το Google Play, τις αναφορές στα μέσα κοινωνικής δικτύωσης (Twitter, Reddit). Ο πίνακας ελέγχου παρακολούθησης πρέπει να είναι προετοιμασμένος εκ των προτέρων και διαθέσιμος σε μεγάλη οθόνη στο γραφείο ή σε ειδικό κανάλι Slack. Release dashboard — ενιαίο παράθυρο για όλες τις μετρήσεις της κυκλοφορίας.
Ιδιαίτερη προσοχή — μετρήσεις παλινδρόμησης: σύγκριση του crash rate με την προηγούμενη έκδοση για την ίδια περίοδο. Αν το crash rate αυξηθεί περισσότερο από 0.1% — αυτή είναι κόκκινη σημαία που απαιτεί άμεση ανάλυση. Είναι επίσης σημαντικό να συγκρίνετε τη διάμεση και p95 καθυστέρηση των βασικών τελικών σημείων API: ακόμα και χωρίς crashes, η επιβράδυνση του χρόνου απόκρισης κατά 200ms μπορεί να υποδηλώνει πρόβλημα. Metric comparison (baseline vs current) αυτοματοποιείται στο Datadog ή στο Grafana.
Τα σχόλια χρηστών — εξίσου σημαντικά με τις αριθμητικές μετρήσεις. Τις πρώτες ώρες μετά την κυκλοφορία, οι χρήστες αφήνουν ενεργά κριτικές στα καταστήματα και γράφουν στην υποστήριξη. Σφάλματα που δεν εντοπίστηκαν από τις δοκιμές εμφανίζονται γρήγορα στις κριτικές. Ο team lead ή ο ορισμένος μηχανικός QA παρακολουθεί τις κριτικές κάθε 30 λεπτά τις πρώτες 4 ώρες και τις κατηγοριοποιεί: false positive, known issue (ήδη στη λίστα known issues), new bug. New bugs P0/P1 — έναυσμα για αναστολή του rollout.
Rollback: πότε και πώς να ανατρέξετε την κυκλοφορία
Rollback — επαναφορά στην προηγούμενη σταθερή έκδοση σε περίπτωση εντοπισμού κρίσιμων προβλημάτων. Η απόφαση για rollback λαμβάνεται από τον release manager μαζί με τον tech lead, εάν: το crash-free rate της νέας κυκλοφορίας πέσει κάτω από 99%, εντοπιστεί διαρροή δεδομένων, κρίσιμη λειτουργικότητα (πληρωμές, εξουσιοδότηση) δεν λειτουργεί για >5% των χρηστών, ή το κατάστημα (App Store Review) απορρίψει το build μετά τη δημοσίευση. Rollback trigger πρέπει να ορίζεται πριν από την κυκλοφορία, ώστε η απόφαση να βασίζεται σε γεγονότα, όχι σε συναισθήματα.
Για Android: rollback στο Google Play Console — διακοπή του σταδιακού rollout και εναλλαγή στην προηγούμενη έκδοση. Αν το τρέχον build είναι ήδη στο 100% των χρηστών — δημοσίευση της προηγούμενης έκδοσης ως νέας κυκλοφορίας. Για iOS: μέσω App Store Connect — Phased Release → Pause Release → κυκλοφορία νέας έκδοσης με διόρθωση (το App Store δεν επιτρέπει επαναφορά σε προηγούμενη έκδοση). iOS rollback είναι πιο περίπλοκο: ο προγραμματιστής πρέπει να δημιουργήσει νέο build με revert commits και να περάσει ξανά από την αξιολόγηση.
Μετά το rollback, η ομάδα μεταβαίνει σε λειτουργία συμβάντος: root cause analysis, hotfix ή επόμενη κυκλοφορία με διόρθωση, post-mortem. Rollback — δεν είναι αποτυχία, αλλά συνήθης διαδικασία. Οι ομάδες που δεν έχουν κάνει ποτέ rollback, πιθανότατα δεν παρατηρούν το πρόβλημα, αντί να κυκλοφορούν χωρίς σφάλματα. Rollback rate — μία από τις μετρήσεις DORA: οι ομάδες υψηλής απόδοσης κάνουν rollback σε <10% των κυκλοφοριών και ανακάμπτουν σε <1 ώρα.
Συχνές ερωτήσεις
Ποια ημέρα είναι καλύτερο να κυκλοφορήσετε μια εφαρμογή για κινητά;
Οι καλύτερες ημέρες — Τρίτη, Τετάρτη ή Πέμπτη. Δευτέρα — υψηλή κίνηση από το σαββατοκύριακο, Παρασκευή — κίνδυνος εισόδου στο σαββατοκύριακο με προβληματική κυκλοφορία. Αποφύγετε την Παρασκευή: αν μετά την ανάπτυξη εντοπιστεί πρόβλημα, η ομάδα θα το διορθώνει το σαββατοκύριακο ή θα περιμένει μέχρι τη Δευτέρα.
Τι να κάνετε αν το App Store Review απορρίψει το build;
Διαβάστε τον λόγο απόρριψης στο Resolution Center, διορθώστε και μεταφορτώστε ξανά το build. Συχνές αιτίες: μη λειτουργικοί σύνδεσμοι, μη συμπληρωμένα πεδία, περιεχόμενο χωρίς συνδρομή (αν απαιτείται), παλιά στιγμιότυπα οθόνης. App Review rejection καθυστερεί την κυκλοφορία 24-48 ώρες, γι' αυτό η πρώτη μεταφόρτωση build πρέπει να γίνει 3-5 ημέρες πριν από την προγραμματισμένη ημερομηνία κυκλοφορίας.
Ποιο ποσοστό σταδιακού rollout είναι βέλτιστο για αρχή;
Για μεγάλες κυκλοφορίες (major changes) — 1%. Για patch releases — 5-10%. Το πρώτο στάδιο πρέπει να είναι αρκετά μικρό ώστε σε περίπτωση σφάλματος ο αντίκτυπος να είναι ελάχιστος, αλλά αρκετά μεγάλο ώστε να ληφθούν στατιστικά σημαντικές μετρήσεις. 1% για μια εφαρμογή με 10 εκατομμύρια χρήστες — 100 χιλιάδες άτομα, αρκετά για τον εντοπισμό κρίσιμων προβλημάτων.
Χρειάζεται να κάνετε release party;
Release party (ομαδική γιορτή) — προαιρετικά, αλλά καλό για το ηθικό. Καλύτερα να γίνει μετά την επιτυχή ολοκλήρωση rollout στο 100%, όχι τη στιγμή μεταφόρτωσης του build. Release celebration μπορεί να συνδυαστεί με το release retrospective για να συζητήσετε τι πήγε καλά και τι μπορεί να βελτιωθεί.
Ποιος είναι υπεύθυνος για την απόφαση „κυκλοφορία ή αναβολή”;
Η ευθύνη ανήκει στον release manager (συνήθως senior engineer ή tech lead). Η απόφαση βασίζεται σε δεδομένα από το release dashboard, όχι στην προθεσμία. Release manager έχει την εξουσία να αναβάλει την κυκλοφορία αν οι μετρήσεις δεν περάσουν το go/no-go gate.
Σύνοψη
- Ημέρα κυκλοφορίας — συντονισμένη διαδικασία από το code freeze έως την παρακολούθηση μετά το rollout
- Προετοιμασία — release candidate, εκτέλεση QA, έλεγχος μεταδεδομένων, σχέδιο rollback
- Staged rollout — 1% → 10% → 25% → 50% → 100% με go/no-go gate σε κάθε στάδιο
- Παρακολούθηση — crash-free rate, ANR, error rate 5xx, αξιολογήσεις χρηστών τις πρώτες 4 ώρες
- Rollback — συνήθης διαδικασία όταν το crash-free rate πέσει κάτω από 99%
- Επικοινωνία — ειδοποίηση ομάδας και ενδιαφερομένων πριν και μετά την κυκλοφορία
- Release retrospective — ανάλυση διαδικασίας μετά την ολοκλήρωση rollout στο 100%
Θα αναπτύξουμε μια εφαρμογή για κινητά έτοιμη για χρήση
Η IT Sectr δημιουργεί εφαρμογές iOS και Android για νεοφυείς επιχειρήσεις και επιχειρήσεις από το 2017. Θα σας συμβουλεύσουμε και θα προτείνουμε την καλύτερη λύση.
Διαβάστε επίσης