Feature freeze και code freeze στην ανάπτυξη εφαρμογών: ουσία, διαφορές και λειτουργία

Τι είναι το feature freeze;

Feature freeze — η προσωρινή απαγόρευση προσθήκης νέας λειτουργικότητας στην βάση κώδικα, η οποία εφαρμόζεται πριν την προγραμματισμένη κυκλοφορία. Η ομάδα σταματά τη συγχώνευση χαρακτηριστικών και περνάει στη διόρθωση σφαλμάτων, βελτιστοποίηση και απορρύθιση του υπάρχοντος κώδικα. Οι πραγματοποιητές ολοκληρώνουν τα ημιτελή χαρακτηριστικά μόνο στο πλαίσιο διορθώσεων σφαλμάτων, χωρίς επέκταση του εύρους.

Τι είναι το code freeze και πώς διαφέρει από το feature freeze

Code freeze — μια πιο αυστηρή πρακτική κατά την οποία οποιαδήποτε αλλαγή στον κώδικα απαγορεύεται πλήρως. Ακόμα και διορθώσεις σφαλμάτων δεν επιτρέπονται, εκτός αν είναι κρίσιμες. Το code freeze εφαρμόζεται για σύντομο χρονικό διάστημα (συνήθως 24-48 ώρες) και εγγυάται ότι το build κυκλοφορίας κατασκευάζεται από ένα σταθερό σύνολο commit.

Η διαφορά μεταξύ feature freeze και code freeze βρίσκεται στο επίπεδο ελέγχου. Το feature freeze διαχειρίζεται το εύρος: τι ακριβώς θα συμπεριληφθεί στην κυκλοφορία. Το code freeze διαχειρίζεται την ποιότητα: αποκλείεται ο κίνδυνος εισαγωγής νέου σφάλματος μία μέρα πριν την κυκλοφορία. Στην πράξη, πολλές ομάδες χρησιμοποιούν ένα διπλό μοντέλο: 1-2 εβδομάδες πριν την κυκλοφορία — feature freeze, 24-48 ώρες — code freeze. Code freeze είναι ιδιαίτερα σημαντικό για φορητές εφαρμογές, όπου το build πρέπει να ανεβαστεί στο κατάστημα λίγες ημέρες πριν την προγραμματισμένη ημερομηνία κυκλοφορίας.

Εξαίρεση από το code freeze — διορθώσεις ασφάλειας για κρίσιμες ευπάθειες (CVE με βαθμολογία 9+). Τέτοιες αλλαγές διέρχονται μια διαδικασία έκτακτης ανάγκης με ταχύ code review και ειδοποίηση της ομάδας. Όλες οι άλλες αλλαγές αναβάλλονται μέχρι τον επόμενο κύκλο κυκλοφορίας.

Feature freeze vs code freeze: σύγκριση

Η επιλογή μεταξύ feature freeze και code freeze εξαρτάται από την ωριμότητα της ομάδας και τη συχνότητα κυκλοφοριών. Ομάδες με CI/CD και feature flags μπορούν να περιοριστούν μόνο σε code freeze 24 ωρών, ενώ ομάδες με μηνιαίες κυκλοφορίες συνήθως χρησιμοποιούν και τα δύο παγώματα διαδοχικά.

Τύποι παγωμάτων: πλήρης, μερικός και BAU-freeze

Εκτός από το πλήρες feature freeze και το code freeze, υπάρχουν πιο ευέλικτες εκδοχές. Partial feature freeze (μερικό πάγωμα) αποκλείει νέα λειτουργικότητα μόνο σε συγκεκριμένα αρθρώματα — για παράδειγμα, στο άρθρωμα πληρωμών ή στο άρθρωμα ταυτοποίησης, αφήνοντας τα υπόλοιπα συστατικά ανοιχτά για αλλαγές.

BAU-freeze (business as usual freeze) — μία συμβιβαστική εκδοχή κατά την οποία απαγορεύονται μόνο τα μεγάλα χαρακτηριστικά με όγκο αλλαγών άνω από ένα συγκεκριμένο όριο (π.χ. 500 γραμμές κώδικα). Μικρές βελτιώσεις, ρυθμίσεις UI και διορθώσεις σφαλμάτων συνεχίζονται. BAU-freeze είναι χρήσιμος για έργα με continuous delivery, όπου η πλήρης διακοπή της ανάπτυξης για μία εβδομάδα είναι οικονομικά ασύμφορη.

Πότε να εφαρμόζεται πάγωμα και πόσο διαρκεί

Η βελτιστη στιγμή για την εφαρμογή feature freeze — μετά το code complete, όταν όλα τα προγραμματισμένα χαρακτηριστικά έχουν συγχωνευτεί και βρίσκονται σε QA. Το ακριβές χρονικό διάστημα εξαρτάται από τον κύκλο κυκλοφορίας: για sprint δύο εβδομάδων, το feature freeze εφαρμόζεται 3-4 ημέρες πριν την ημερομηνία κυκλοφορίας, για μηνιαία κυκλοφορία — 7-10 ημέρες πριν. Code freeze εφαρμόζεται 24-48 ώρες πριν τον προγραμματισμένο χρόνο κατασκευής του build κυκλοφορίας.

Η διάρκεια του παγώματος πρέπει να είναι η ελάχιστη απαραίτητη για τη σταθεροποίηση του κώδικα. Ένα πολύ μακρό πάγωμα (περισσότερο από 2 εβδομάδες) αποκαρδιώνει την ομάδα και δημιουργεί σωρεύση χαρακτηριστικών που δεν έχουν συγχωνευτεί, κάθε ένα από τα οποία μετά την άρση του παγώματος αυξάνει τον κίνδυνο συγκρούσεων. Ένα πολύ σύντομο πάγωμα (λιγότερο από 24 ώρες για feature freeze) δεν δίνει αρκετό χρόνο για δοκιμές και διορθώσεις.

Συστηνόμενη πρακτική — να ορίζεται το πάγωμα όχι βάσει ημερομηνίας, αλλά βάσει της κατάστασης της βάσης κώδικα. Το feature freeze εφαρμόζεται όταν ο αριθμός των ανοιχτών bug για την κυκλοφορία υπερβαίνει ένα κατώφλι (π.χ. 10 κρίσιμα bug). Code freeze — όταν το build περνάει με επιτυχία τα smoke tests και το regression suite. Time-based freeze (σταθερή ημερομηνία) παραμένει πρότυπο για ρυθμιζόμενες βιομηχανίες (χρηματοοικονομικό, ιατρικό), όπου η ημερομηνία κυκλοφορίας έχει εγκριθεί από τον ρυθμιστή.

Αυτοματοποίηση παγωμάτων μέσω CI/CD και Git

Ο χειροκίνητος έλεγχος των παγωμάτων είναι πηγή σφαλμάτων: ένας πραγματοποιητής μπορεί κατά λάθος να συγχωνεύσει ένα PR που πρέπει να περιμένει την άρση του παγώματος. Η αυτοματοποίηση λύνει το πρόβλημα μέσω κανόνων προστασίας κλάδου Git και pipeline CI/CD. Στον πάροχο Git (GitHub, GitLab, Bitbucket) ορίζονται κανόνες που αποκλείουν τη συγχώνευση στον κλάδο κυκλοφορίας χωρίς ειδική ετικέτα ή έγκριση από τον release manager.

CI/CD pipeline ελέγχει την κατάσταση του παγώματος πριν την κατασκευή του build. Στο Jenkins, GitLab CI ή GitHub Actions, προστίθεται ένα βήμα που διαβάζει ένα αρχείο ρυθμίσεων με το χρονοδιάγραμμα παγωμάτων και απορρίπτει τα build εάν η τρέχουσα ημερομηνία εμπίπτει στην περίοδο παγώματος. Εναλλακτική — feature flag στον πίνακα διαχείρισης που αποκλείει την ανάπτυξη στην παραγωγή.

# .github/workflows/check-freeze.yml
name: Check Freeze Status
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  check-freeze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Check freeze status
        run: node .github/scripts/freeze-check.js
      - name: Block PR if frozen
        if: failure()
        run: echo "Το feature freeze είναι ενεργό. PR αποκλείστηκε." && exit 1

Το παράδειγμα σκριπτ freeze-check.js διαβάζει JSON με το χρονοδιάγραμμα παγωμάτων από τη ρίζα του αποθετηρίου. Εάν η τρέχουσα ημερομηνία εμπίπτει στο διάστημα μεταξύ start_date και end_date για τον καθορισμένο κλάδο — το pipeline αποτυγχάνει με ένα μήνυμα σχετικά με την κατάσταση του παγώματος. Git branch protection προσθέτει ένα δεύτερο εμπόδιο: ακόμα και αν το pipeline δεν λειτουργήσει, ο κανόνας δεν επιτρέπει τη συγχώνευση PR χωρίς έγκριση.

Συνηθισμένα λάθη κατά την εφαρμογή παγωμάτων

Πρώτο λάθος — πάγωμα χωρίς σαφή κριτήρια άρσης. Η ομάδα παγώνει τον κώδικα αλλά δεν καθορίζει ποιες συνθήκες πρέπει να εκπληρωθούν για την απόψυξη: μηδέν κρίσιμο bug, επιτυχημένο regression suite, έγκριση από τον product manager. Χωρίς κριτήρια, το πάγωμα μπορεί να διαρκέσει εβδομάδες. Definition of done για το πάγωμα πρέπει να είναι τεκμηριωμένο και γνωστό σε κάθε πραγματοποιητή.

Δεύτερο λάθος — πάρα πολλές εξαιρέσεις από το πάγωμα. Κάθε exception (“αυτό το PR δεν είναι χαρακτηριστικό, αλλά τεχνικό χρέος”) θολώνει το όριο του παγώματος. Εάν οι exceptions υπερβαίνουν το 20% της φυσιολογικής ροής PR — το πάγωμα δεν λειτουργεί. Η ομάδα απλώς μετονομάζει τα χαρακτηριστικά σε διορθώσεις σφαλμάτων για να παρακάμψει τον αποκλεισμό.

Τρίτο λάθος — παράβλεψη των release candidate. Εάν η ομάδα δεν κατασκευάζει release candidate build και αναπτύσσει αμέσως στην παραγωγή μετά το code freeze, η έννοια του παγώματος χάνεται: τα σφάλματα ανακαλύπτονται από τους χρήστες. Release candidate πρέπει να κατασκευάζεται πριν το code freeze, να δοκιμάζεται από QA και στο staging, και μόνο μετά την επιβεβαίωση της ποιότητας να εφαρμόζεται το code freeze.

Τέταρτο λάθος — ο ανθρώπινος παράγοντας στον χειροκίνητο έλεγχο. Ένας πραγματοποιητής μπορεί να ξεχάσει να ελέγξει την κατάσταση του παγώματος πριν τη συγχώνευση, ο release manager μπορεί να χάσει την ειδοποίηση. Η μόνη αξιόπιστη λύση — αυτόματος αποκλεισμός σε επίπεδο Git provider ή CI/CD που αποκλείει το ανθρώπινο λάθος.