Ο γραμμικός μηχανικός Mufeez Amjad δημοσίευσε μια λεπτομερή περιγραφή του τρόπου με τον οποίο η εταιρεία επεξεργάστηκε ξανά τον αγωγό συνεχούς ολοκλήρωσής της, αφού οι πράκτορες κωδικοποίησης AI μετέτρεψαν το CI στο χειρότερο σημείο συμφόρησης - μειώνοντας τον χρόνο αναμονής αιτήματος έλξης από περισσότερα από έξι λεπτά σε λίγο πάνω από πέντε, ενώ οι δοκιμαστικές σουίτες σχεδόν τετραπλασιάστηκαν από την αρχή του έτους.
Η ανάρτηση, που δημοσιεύτηκε στο ιστολόγιο μηχανικής της Linear στις 21 Σεπτεμβρίου, ξεκίνησε, όπως κάνουν συχνά αυτά τα πράγματα, με ένα λακωνικό εισιτήριο από ψηλά. Νωρίτερα αυτό το έτος, ο Amjad άνοιξε τη Linear για να διαπιστώσει ότι ο Tuomas, ο CTO της εταιρείας, του είχε αναθέσει ένα τεύχος με τίτλο "Το κόστος CI είναι υψηλό" — και του ζήτησε να κάνει το CI πιο γρήγορα όσο ήταν σε αυτό. Για περισσότερες πληροφορίες σχετικά με αυτήν την ιστορία, ανατρέξτε στην εν εξελίξει κάλυψη του κλάδου AI.
Όταν οι πράκτορες ξεπερνούν την επικύρωση
Το πρόβλημα είναι δομικό, όχι τυχαίο. «Οι πράκτορες έχουν κάνει εκθετικά ταχύτερη την αποστολή του κωδικού», έγραψε ο Amjad, «αλλά η επικύρωση αυτών των αλλαγών δεν διατηρήθηκε με τον ίδιο ρυθμό». Κάθε αίτημα έλξης πρέπει ακόμα να περάσει από το CI, οπότε καθώς η ανάπτυξη επιταχύνεται, το CI γίνεται το σημείο ασφυξίας — αυξάνοντας το κόστος υποδομής και αφήνοντας τους προγραμματιστές και τους αντιπροσώπους τους να περιμένουν περισσότερο για σχόλια.
Γραμμική βελτιστοποίηση για δύο μετρήσεις: πόσο χρόνο περιμένει ένα PR στο CI και πόσο χρόνο δρομέα καταναλώνει. Τα αποτελέσματα μετά από μήνες εργασίας: παρά το γεγονός ότι οι σουίτες δοκιμών σχεδόν τετραπλασιάστηκαν από τον Ιανουάριο, ο χρόνος αναμονής του αιτήματος έλξης μειώθηκε από περισσότερα από έξι λεπτά σε λίγο περισσότερο από πέντε και ο χρόνος δρομέα ανά δοκιμή μειώθηκε περίπου στο μισό.
Η εργασία εντάσσεται γενικά σε τέσσερις κατηγορίες: αναβαθμισμένη υποδομή και εργαλεία, βελτιστοποίηση των εργασιών που περικλείουν άλλες εργασίες, μείωση επαναλαμβανόμενων ρυθμίσεων και κάνει την εκτέλεση δοκιμών πιο αποτελεσματική. Η βάση κώδικα της Linear είναι κυρίως TypeScript, αλλά πολλές από τις βελτιστοποιήσεις εφαρμόζονται σε γλώσσες και αλυσίδες εργαλείων.
Ταχύτερα μηχανήματα και εγγενής μεταγλωττιστής
Ορισμένα από τα πρώτα κέρδη δεν απαιτούσαν σχεδόν καμία βελτιστοποίηση του ίδιου του CI. Η μεταφορά φόρτου εργασίας από το GitHub Actions σε τρίτους χρήστες με ταχύτερους CPU, αποθήκευση υψηλότερης απόδοσης και καλύτερη υποδομή κρυφής μνήμης απέδωσε αμέσως: σε μια παρόμοια σύγκριση των δύο ημερών και στις δύο πλευρές του διακόπτη, οι εργασίες έτρεξαν 34% πιο γρήγορα κατά μέσο όρο, με ορισμένους φόρτους εργασίας όπως το «tsc» να μειώνονται κατά 52%.
Ο εκσυγχρονισμός της αλυσίδας εργαλείων συνέτεινε τη νίκη. Μεταβαίνοντας στο `tsgo`, τον εγγενή μεταγλωττιστή TypeScript, μείωσε την εβδομαδιαία διάμεσο του πληκτρολογίου κατά 73% — αρκετά μεγάλη ώστε να απομακρύνει εντελώς το σημείο συμφόρησης από τον έλεγχο πληκτρολόγησης.
Linting Without the Type Graph
Το Linting ήταν ένας άλλος πρώιμος στόχος. Μια χούφτα προσαρμοσμένων κανόνων ESLint της Linear εξαρτιόνταν από τις πληροφορίες τύπου TypeScript, οι οποίες ανάγκαζαν κάθε εκτέλεση του lint να δημιουργήσει το πλήρες γράφημα τύπων πριν από την αξιολόγησή τους - καθιστώντας το linting μια από τις εργασίες CI με μεγαλύτερη ένταση μνήμης.
Η ομάδα επανέγραψε τους κανόνες για να χρησιμοποιήσει στατική ανάλυση πάνω από το αφηρημένο συντακτικό δέντρο, εντοπίζοντας δομές που μοιάζουν με συναρτήσεις και μοτίβα προστασίας χωρίς πληροφορίες τύπου. Αυτό επέτρεψε στο ESLint να απορρίψει εντελώς το TypeScript, μειώνοντας τον χρόνο χρωματισμού του API κατά 68% και τον χρόνο χρωματισμού πλήρους αποθήκης κατά 55%, με τη χρήση μνήμης να μειώνεται σημαντικά. Διευκόλυνε επίσης την μετέπειτα μετανάστευση στο Oxlint, η οποία μείωσε περαιτέρω τα λεπτά δρομέα CI που δαπανήθηκαν για το linting.
Συρρίκνωση της κρίσιμης διαδρομής
Με μεμονωμένους ελέγχους γρηγορότερους, το Linear έκανε σμίκρυνση και αντιμετώπισε το CI ως σύστημα. Αυτό τράβηξε την προσοχή στις μικρές εργασίες που βρίσκονται μπροστά από οτιδήποτε άλλο - ανίχνευση αλλαγής διαδρομής και έλεγχοι προσωρινής μνήμης αποτελεσμάτων δοκιμής αυτής της πύλης σε επίπεδο εργασίας, που σημαίνει ότι κανένα από τα οκτώ θραύσματα δοκιμής API δεν μπορεί να ξεκινήσει μέχρι να τελειώσει.
Οι επιδιορθώσεις ήταν κοκκώδεις αλλά πρόσθετες. Η κάλυψη του βάθους ανάκτησης οδήγησε την πιο αργή πύλη από 94 δευτερόλεπτα σε 20. Η εξ ολοκλήρου κατάργηση του ταμείου από εργασίες που δεν χρειάζονταν ποτέ λειτουργικό δέντρο μείωσε αυτές από 27 δευτερόλεπτα σε 7. Ένα αραιό ταμείο χωρίς φυσαλίδες με περιορισμένο ιστορικό εξοικονομούσε άλλα 11 δευτερόλεπτα για συμβάντα ώθησης και συγχώνευσης-ουράς. Συνολικά, η διάμεση διάρκεια της εργασίας ανίχνευσης αλλαγών μειώθηκε από 26 δευτερόλεπτα σε 8, η p90 της από 31 σε 12 και η πιο αργή της εκτέλεση από 138 δευτερόλεπτα σε 37.
Η αξιοπιστία του Checkout χρειαζόταν επίσης δουλειά: επειδή οι δρομείς τρίτου μέρους κάθονται εκτός του δικτύου του GitHub και βασίζονται σε μια άμεση σύνδεση IP, η διακοπτόμενη υποβάθμιση της σύνδεσης περιστασιακά σταματούσε τις ανακτήσεις. Η Linear αντικατέστησε το "actions/checkout" με τη δική του σύνθετη ενέργεια που επαναλαμβάνει με backoff, ορίζει τα "GIT_HTTP_LOW_SPEED_LIMIT" και "GIT_HTTP_LOW_SPEED_TIME", έτσι ώστε μια διακοπείσα σύνδεση διακόπτεται μετά από περίπου 30 δευτερόλεπτα αντί να διακοπεί, και χρησιμοποιεί ένα κολλητό σε μια προσωρινή μνήμη ολοκλήρωσης αγοράς.
Μια λεπτή επιδιόρθωση αφαίρεσε τον χαμένο χρόνο συγχώνευσης-ουράς: οι δείκτες κρυφής μνήμης γράφονταν ως μέρος του τελικού ελέγχου πριν από τη συγχώνευση, έτσι ένας PR μπορούσε να βρίσκεται στην ουρά ακόμη και αφού περάσουν οι δοκιμές του. Η μετακίνηση αυτής της εγγραφής σε μια εργασία χωρίς πύλη ξυρίστηκε 42 δευτερόλεπτα από τη διαδρομή συγχώνευσης για κάθε αίτημα έλξης API και καταχώρηση ουράς συγχώνευσης. Μαζί, αυτές οι αλλαγές χρειάστηκαν περίπου ένα λεπτό από τους απαιτούμενους ελέγχους για τα API PR για τις αποτυχίες της προσωρινής μνήμης, ενώ μειώνονται οι εκκινήσεις δρομέων.
Λιγότερα χαμένα δευτερόλεπτα ανά εργασία
Το κόστος εγκατάστασης της τελευταίας κατηγορίας επιτέθηκε σε κάθε εργασία. Κάθε θραύσμα δοκιμής API ξόδεψε 7 έως 8 δευτερόλεπτα εγκαθιστώντας τον ίδιο πελάτη Postgres με apt σε κάθε εκτέλεση. Μετακινώντας το σε μια μικρή εικόνα βάσης CI δίπλα στο Node σήμαινε ότι τα θραύσματα θα μπορούσαν να ξεκινήσουν να λειτουργούν. Αργότερα, η ομάδα πρόσθεσε κεφαλίδες εγγενούς κατασκευής στην εικόνα, αφού ανακάλυψε ότι η λήψη τους κατά τη διάρκεια της εγκατάστασης θα μπορούσε περιστασιακά να κολλάει.
Γιατί είχε απήχηση
Η ανάρτηση προκάλεσε νευρικότητα στους προγραμματιστές: έφτασε στην πρώτη σελίδα του Hacker News, συγκεντρώνοντας περίπου 250 πόντους και περίπου 280 σχόλια μέσα σε μια μέρα. Η αντίδραση είναι εύκολο να εξηγηθεί — η εμπειρία της Linear αναφέρει ένα κόστος ανάπτυξης με τη βοήθεια τεχνητής νοημοσύνης που οι περισσότεροι μηχανικοί οργανισμοί αντιμετωπίζουν μόλις τώρα. Οι πράκτορες που δημιουργούν αιτήματα έλξης σε λίγα λεπτά εξακολουθούν να περιμένουν σε αγωγούς επικύρωσης που έχουν σχεδιαστεί για ανθρώπινο ρυθμό και κάθε λεπτό αυτής της αναμονής πολλαπλασιάζεται σε κάθε παράγοντα που λειτουργεί παράλληλα.
Το μάθημα από την επανεξέταση της Linear είναι ότι το σημείο συμφόρησης είναι μετακινούμενο, αλλά μόνο μέσω της μη γοητευτικής συσσώρευσης πολλών μικρών επιδιορθώσεων - πιο γρήγοροι δρομείς, φθηνότεροι έλεγχοι τύπων, κανόνες σε επίπεδο σύνταξης, περιορισμένες ανακτήσεις, ελαστικά ταμεία, προκατασκευασμένες εικόνες - αντί οποιασδήποτε μεμονωμένης ασημένιας κουκκίδας.
---
Μείνετε μπροστά από την τεχνητή νοημοσύνηΛάβετε τα τελευταία νέα, αναλύσεις και ανακαλύψεις AI — όλα σε ένα μέρος.
Διαβάστε περισσότερα νέα AI →
