Σπάσιμο του build: τι είναι, αίτια και πώς να αποφύγετε στο έργο

Τι σημαίνει το σπάσιμο του build στην ανάπτυξη

Το σπάσιμο του build είναι η κατάσταση όταν μετά από την εισαγωγή αλλαγών, το έργο σταματάει να κατασκευάζεται. Στο πλαίσιο του CI/CD, αυτό σημαίνει ότι το pipeline μεταγλωττισης τερματίζει με σφάλμα και το τεχνίτευργημα δεν δημιουργείται.

Στον κόσμο της κινητής και της ανάπτυξης web, το build είναι η διαδικασία μετατροπής του πηγαίου κώδικα σε εκτελέσιμο αρχείο ή πακέτο. Για Android είναι η μεταγλώττιση APK ή AAB μέσω Gradle, για iOS — η μεταγλώττιση μέσω Xcode, για web έργα — η κατασκευή μέσω Webpack ή Vite. Το build μπορεί να σπάσει σε οποιοδήποτε από αυτά τα στάδια.

Τα σύγχρονα συστήματα ελέγχου εκδόσεων και τα εργαλεία CI/CD, όπως Jenkins, GitHub Actions και GitLab CI, εντοπίζουν αυτόματα ένα σπασμένο build και ειδοποιούν την ομάδα. Στα περισσότερα έργα υπάρχει κανόνας: αν το build είναι σπασμένο, η προτεραιότητα όλων των άλλων εργασιών μειώνεται μέχρι να επισκευαστεί η μεταγλώττιση.

fun main() {
    val message: String = "Build successful"
    println(message)
    
    // Αυτή η γραμμή σπάει το build
    val number: Int = "not a number"
}

Σε αυτό το παράδειγμα, η αναθεση ενός string σε μεταβλητή τύπου Int προκαλεί σφάλμα μεταγλώττισης. Type mismatch — μία από τις πιο συνηθισμένες αιτίες σπασίματος του build σε στατικά τυποποιημένες γλώσσες.

Κύριες αιτίες σπασίματος της μεταγλωττισης

Υπάρχουν αρκετές κατηγορίες σφαλμάτων που οδηγούν σε σπασμένο build. Σύμφωνα με την αναλυτική του GitLab για το 2024, η κατανομή των αιτίων είναι η εξής.

Η πιο δολερή κατηγορία — προβλήματα εξαρτήσεων. Η ενημέρωση μιας βιβλιοθήκης σε ένα module μπορεί να σπάσει το build σε ένα γειτονικό module, εάν έχει αλλάξει το API ή η συμπεριφορά των μεθόδων.

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

Πώς επηρεάζει το σπασμένο build την ομάδα

Το σπασμένο build επηρεάζει άμεσα την παραγωγικότητα της ομάδας. Όταν η μεταγλώττιση αποτυγχάνει, οι προγραματιστές δεν μπορούν να λάβουν την τρέχουσα έκδοση του έργου από το αποθετήριο, και το pipeline CI είναι αποκλεισμένο για όλες τις επόμενες αλλαγές.

Έρευνα της Atlassian το 2023 έδειξε ότι τα έργα όπου το build παραμένει σπασμένο για περισσότερες από τέσσερις ώρες χάνουν κατά μέσο όρο 25% του παραγωγικού χρόνου της ομάδας. Οι προγραματιστές αναγκάζονται να ασχολούνται με τη διάγνωση του προβλήματος αντί να εκτελούν τις εργασίες τους.

Εκτός από την παραγωγικότητα, υποφέρει και το ηθικό κλίμα. Ο προγραματιστής που έσπασε το build αισθάνεται πίεση από τους συναδέλφους. Σε υγιείς ομάδες ισχύει ο κανόνας: μην τιμωρείτε για σπασμένο build, αλλά απαιτείτε άμεση διόρθωση. Blameless culture — η προσέγγιση όπου το περιστατικό αναλύεται ως συστημικό πρόβλημα, όχι ως λάθος κάποιου.

Σε αποκεντρωμένες ομάδες, ένα σπασμένο build μπορεί να εμποδίσει την εργασία των εργαζομένων σε διαφορετική χρονική ζώνη. Εάν ένας προγραματιστής από την Ευρώπη έσπασε το build πριν φύγει, η ομάδα από την Ασία μπορεί να χάσει μια ολόκληρη εργάσιμη ημέρα περιμένοντας επισκευή.

Πώς να αποφύγετε το σπασμένο build

Η αποφυγή του σπασμένου build ξεκινά με τοπικούς ελέγχους πριν από το commit. Κάθε προγραματιστής πρέπει να εκτελεί δοκιμές και μεταγλώττιση πριν την αποστολή αλλαγών. Οι κύριες μέθοδοι πρόληψης χωρίζονται σε αρκετά επίπεδα.

• Pre-commit hooks — αυτόματοι έλεγχοι πριν τη δημιουργία commit, συμπεριλαμβανομένων linter και formatter
• Τοπική μεταγλώττιση — εκτέλεση της μεταγλωττισης πριν το push, ειδικά για στατικά τυποποιημένες γλώσσες
• Unit tests — καλύψη βασικών module με δοκιμές για έγκαιρη ανίχνευση regressions
• Code review — έλεγχος αλλαγών από έναν συνάδελφο πριν το merge στο κύριο branch

Δεύτερο επίπεδο — ρύθμιση του pipeline CI/CD. Κάθε Pull Request πρέπει να περνά από αυτόματη μεταγλώττιση και δοκιμή πριν το merge. Εάν η μεταγλώττιση αποτυχάνει, το PR αποκλείεται μέχρι την επισκευή. Αυτή η προσέγγιση ονομάζεται gated commit και χρησιμοποιείται σε πολλά σύγχρονα έργα.

Τρίτο επίπεδο — παρακολούθηση και στατιστική. Οι ομάδες παρακολουθούν τη μετρική χρόνου αποκατάστασης της μεταγλωττισης — MTTR (Mean Time To Repair). Όσο χαμηλότερος είναι αυτός ο δείκτης, τόσο πιο γρήγορα αντιδρά η ομάδα σε ένα σπασμένο build. Τιμή στόχου — όχι περισσότερο από 30 λεπτά.

Τι να κάνετε αν το build είναι σπασμένο

Όταν το build είναι σπασμένο, το πρώτο βήμα είναι να καθορίσετε ποιος προγραματιστής έκανε τις τελευταίες αλλαγές. Το Git παρέχει το εργαλείο git bisect που σας επιτρέπει να βρείτε το commit που έσπασε τη μεταγλωττιση μέσω δυαδικής αναζήτησης.

# Ξινάρξη bisect με γνωστά καλά και κακά commits
git bisect start
git bisect bad HEAD
git bisect good abc1234

# Ο Git ελέγχει ένα commit στη μέση
# Χτίσε και δοκίμασε, έπειτα σημείωσε:
git bisect good  # if build passes
git bisect bad   # if build fails

# Μετά από ~log2(n) βήματα, ο Git δείχνει τον ένοχο
git bisect reset

Μετά την εύρεση του προβληματικού commit, υπάρχουν δύο επιλογές. Πρώτη — αναίρεση των αλλαγών μέσω git revert, εάν η επισκευή απαιτεί χρόνο. Αυτή είναι η πιο ασφαλής προσέγγιση, ειδικά όταν το build εμποδίζει ολόκληρη την ομάδα.

Δεύτερη επιλογή — άμεση επισκευή με νέο commit. Αυτή η προσέγγιση είναι προτιμητέα αν το πρόβλημα είναι τοπικό και σαφές. Μετά την επισκευή, κάνετε push τις αλλαγές και βεβαιωθείτε ότι το build περάσε επιτυχώς. Σε κάθε περίπτωση, ο χρόνος αποκατάστασης της μεταγλωττισης δεν πρέπει να υπερβαίνει τημία ώρα.