Η εισαγωγή μιας νέας έκδοσης έργου στην παραγωγή απαιτεί προσεκτική ισορροπία μεταξύ της ταχύτητας ανάπτυξης και της αξιοπιστίας της λύσης. Το Slack αποτιμά τις γρήγορες επαναλήψεις, τους σύντομους κύκλους ανάδρασης και την άμεση απάντηση στα αιτήματα των χρηστών. Επιπλέον, η εταιρεία έχει εκατοντάδες προγραμματιστές που προσπαθούν να είναι όσο το δυνατόν πιο παραγωγικοί.
Οι συντάκτες του υλικού, τη μετάφραση του οποίου δημοσιεύουμε σήμερα, λένε ότι μια εταιρεία που προσπαθεί να τηρεί τέτοιες αξίες και ταυτόχρονα αναπτύσσεται πρέπει να βελτιώνει συνεχώς το σύστημα ανάπτυξης του έργου της. Η εταιρεία πρέπει να επενδύσει στη διαφάνεια και την αξιοπιστία των διαδικασιών εργασίας, ώστε να διασφαλίσει ότι αυτές οι διαδικασίες αντιστοιχούν στην κλίμακα του έργου. Εδώ θα μιλήσουμε για τις ροές εργασιών που έχουν αναπτυχθεί στο Slack και για μερικές από τις αποφάσεις που οδήγησαν την εταιρεία να χρησιμοποιήσει το σύστημα ανάπτυξης έργου που υπάρχει σήμερα.
Πώς λειτουργούν οι διαδικασίες ανάπτυξης έργων σήμερα
Κάθε PR (αίτημα έλξης) στο Slack πρέπει να υπόκειται σε έλεγχο κώδικα και πρέπει να περάσει επιτυχώς όλες τις δοκιμές. Μόνο αφού πληρούνται αυτές οι προϋποθέσεις μπορεί ο προγραμματιστής να συγχωνεύσει τον κώδικά του στον κύριο κλάδο του έργου. Ωστόσο, αυτός ο κωδικός αναπτύσσεται μόνο κατά τις εργάσιμες ώρες, ώρα Βόρειας Αμερικής. Ως αποτέλεσμα, λόγω του γεγονότος ότι οι υπάλληλοί μας βρίσκονται στους χώρους εργασίας τους, είμαστε πλήρως προετοιμασμένοι να λύσουμε τυχόν απροσδόκητα προβλήματα.
Κάθε μέρα πραγματοποιούμε περίπου 12 προγραμματισμένες αναπτύξεις. Κατά τη διάρκεια κάθε ανάπτυξης, ο προγραμματιστής που ορίζεται ως επικεφαλής ανάπτυξης είναι υπεύθυνος για τη μεταφορά της νέας κατασκευής στην παραγωγή. Αυτή είναι μια διαδικασία πολλαπλών σταδίων που διασφαλίζει ότι η συναρμολόγηση τίθεται στην παραγωγή ομαλά. Χάρη σε αυτήν την προσέγγιση, μπορούμε να εντοπίσουμε σφάλματα προτού επηρεάσουν όλους τους χρήστες μας. Εάν υπάρχουν πάρα πολλά σφάλματα, η ανάπτυξη του συγκροτήματος μπορεί να επαναφερθεί. Εάν ένα συγκεκριμένο ζήτημα ανακαλυφθεί μετά την κυκλοφορία, μπορεί εύκολα να κυκλοφορήσει μια επιδιόρθωση για αυτό.
Διεπαφή του συστήματος Checkpoint, το οποίο χρησιμοποιείται στο Slack για την ανάπτυξη έργων
Η διαδικασία ανάπτυξης μιας νέας έκδοσης στην παραγωγή μπορεί να θεωρηθεί ότι αποτελείται από τέσσερα βήματα.
▍1. Δημιουργία κλάδου απελευθέρωσης
Κάθε κυκλοφορία ξεκινά με ένα νέο κλάδο κυκλοφορίας, ένα σημείο στην ιστορία μας στο Git. Αυτό σας επιτρέπει να αντιστοιχίσετε ετικέτες στην κυκλοφορία και παρέχει ένα μέρος όπου μπορείτε να κάνετε ζωντανές διορθώσεις για σφάλματα που εντοπίστηκαν στη διαδικασία προετοιμασίας της κυκλοφορίας για κυκλοφορία στην παραγωγή.
▍2. Ανάπτυξη σε περιβάλλον σταδιοποίησης
Το επόμενο βήμα είναι να αναπτύξετε τη συναρμολόγηση σε διακομιστές σταδιοποίησης και να εκτελέσετε μια αυτόματη δοκιμή για τη συνολική απόδοση του έργου (δοκιμή καπνού). Το περιβάλλον σκηνής είναι ένα περιβάλλον παραγωγής που δεν δέχεται εξωτερική κίνηση. Σε αυτό το περιβάλλον, εκτελούμε πρόσθετες χειροκίνητες δοκιμές. Αυτό μας δίνει επιπλέον εμπιστοσύνη ότι το τροποποιημένο έργο λειτουργεί σωστά. Οι αυτοματοποιημένες δοκιμές από μόνες τους δεν αρκούν για να παρέχουν αυτό το επίπεδο εμπιστοσύνης.
▍3. Ανάπτυξη σε περιβάλλον εσωτερικών τροφών και καναρίνι
Η ανάπτυξη στην παραγωγή ξεκινά με ένα περιβάλλον εσωτερικών δοκιμών, που αντιπροσωπεύεται από ένα σύνολο κεντρικών υπολογιστών που εξυπηρετούν τους εσωτερικούς χώρους εργασίας του Slack. Δεδομένου ότι είμαστε πολύ ενεργοί χρήστες του Slack, η εφαρμογή αυτής της προσέγγισης μας βοήθησε να εντοπίσουμε πολλά σφάλματα νωρίς στην ανάπτυξη. Αφού βεβαιωθούμε ότι δεν έχει σπάσει η βασική λειτουργικότητα του συστήματος, το συγκρότημα αναπτύσσεται στο περιβάλλον του καναρινιού. Αντιπροσωπεύει συστήματα που αντιπροσωπεύουν περίπου το 2% της κίνησης παραγωγής.
▍4. Σταδιακή απελευθέρωση στην παραγωγή
Εάν οι δείκτες παρακολούθησης για τη νέα έκδοση αποδειχθούν σταθεροί και εάν μετά την ανάπτυξη του έργου στο περιβάλλον καναρίνι δεν έχουμε λάβει παράπονα, συνεχίζουμε να μεταφέρουμε σταδιακά τους διακομιστές παραγωγής στη νέα έκδοση. Η διαδικασία ανάπτυξης χωρίζεται στα ακόλουθα στάδια: 10%, 25%, 50%, 75% και 100%. Ως αποτέλεσμα, μπορούμε σιγά σιγά να μεταφέρουμε την κυκλοφορία παραγωγής στη νέα έκδοση του συστήματος. Ταυτόχρονα, έχουμε χρόνο να διερευνήσουμε την κατάσταση εάν εντοπιστούν ανωμαλίες.
▍Τι γίνεται αν κάτι πάει στραβά κατά την ανάπτυξη;
Η πραγματοποίηση τροποποιήσεων στον κώδικα είναι πάντα ένας κίνδυνος. Αλλά το αντιμετωπίζουμε αυτό χάρη στην παρουσία καλά εκπαιδευμένων «ηγετών ανάπτυξης» που διαχειρίζονται τη διαδικασία εισαγωγής μιας νέας έκδοσης στην παραγωγή, παρακολουθούν δείκτες παρακολούθησης και συντονίζουν το έργο των προγραμματιστών που απελευθερώνουν κώδικα.
Σε περίπτωση που κάτι πάει στραβά, προσπαθούμε να εντοπίσουμε το πρόβλημα όσο το δυνατόν νωρίτερα. Ερευνούμε το πρόβλημα, βρίσκουμε το PR που προκαλεί τα σφάλματα, το επαναφέρουμε, το αναλύουμε διεξοδικά και δημιουργούμε μια νέα έκδοση. Είναι αλήθεια ότι μερικές φορές το πρόβλημα περνά απαρατήρητο έως ότου το έργο μπει στην παραγωγή. Σε μια τέτοια κατάσταση, το πιο σημαντικό πράγμα είναι να επαναφέρετε την υπηρεσία. Επομένως, προτού ξεκινήσουμε τη διερεύνηση του προβλήματος, επιστρέφουμε αμέσως στην προηγούμενη έκδοση εργασίας.
Δομικά στοιχεία ενός συστήματος ανάπτυξης
Ας δούμε τις τεχνολογίες που αποτελούν τη βάση του συστήματος ανάπτυξης του έργου μας.
▍Γρήγορες αναπτύξεις
Η ροή εργασίας που περιγράφεται παραπάνω μπορεί να φαίνεται, εκ των υστέρων, κάπως προφανής. Αλλά το σύστημα ανάπτυξής μας δεν έγινε αμέσως έτσι.
Όταν η εταιρεία ήταν πολύ μικρότερη, ολόκληρη η εφαρμογή μας μπορούσε να εκτελεστεί σε 10 περιπτώσεις Amazon EC2. Η ανάπτυξη του έργου σε αυτήν την κατάσταση σήμαινε τη χρήση του rsync για τον γρήγορο συγχρονισμό όλων των διακομιστών. Προηγουμένως, ο νέος κώδικας βρισκόταν μόνο ένα βήμα μακριά από την παραγωγή, αντιπροσωπευόμενος από ένα περιβάλλον σταδιοποίησης. Σε ένα τέτοιο περιβάλλον δημιουργήθηκαν και δοκιμάστηκαν συγκροτήματα και μετά πήγαν κατευθείαν στην παραγωγή. Ήταν πολύ εύκολο να κατανοήσουμε ένα τέτοιο σύστημα· επέτρεπε σε κάθε προγραμματιστή να αναπτύξει τον κώδικα που είχε γράψει ανά πάσα στιγμή.
Καθώς όμως ο αριθμός των πελατών μας μεγάλωνε, αυξανόταν και η κλίμακα της υποδομής που απαιτείται για την υποστήριξη του έργου. Σύντομα, δεδομένης της συνεχούς ανάπτυξης του συστήματος, το μοντέλο ανάπτυξης μας, βασισμένο στην προώθηση νέου κώδικα στους διακομιστές, δεν έκανε πλέον τη δουλειά του. Δηλαδή, η προσθήκη κάθε νέου διακομιστή σήμαινε αύξηση του χρόνου που απαιτείται για την ολοκλήρωση της ανάπτυξης. Ακόμη και οι στρατηγικές που βασίζονται στην παράλληλη χρήση του rsync έχουν ορισμένους περιορισμούς.
Καταλήξαμε να λύσουμε αυτό το πρόβλημα μεταβαίνοντας σε ένα εντελώς παράλληλο σύστημα ανάπτυξης, το οποίο σχεδιάστηκε διαφορετικά από το παλιό σύστημα. Δηλαδή, τώρα δεν στείλαμε κώδικα στους διακομιστές χρησιμοποιώντας σενάριο συγχρονισμού. Τώρα κάθε διακομιστής κατέβασε ανεξάρτητα τη νέα διάταξη, γνωρίζοντας ότι έπρεπε να το κάνει παρακολουθώντας την αλλαγή του κλειδιού Consul. Οι διακομιστές φόρτωσαν τον κώδικα παράλληλα. Αυτό μας επέτρεψε να διατηρήσουμε υψηλή ταχύτητα ανάπτυξης ακόμη και σε περιβάλλον σταθερής ανάπτυξης του συστήματος.
1. Οι διακομιστές παραγωγής παρακολουθούν το κλειδί Consul. 2. Το κλειδί αλλάζει, αυτό λέει στους διακομιστές ότι πρέπει να ξεκινήσουν τη λήψη νέου κώδικα. 3. Διακομιστές κατεβάζουν αρχεία tarball με κωδικό εφαρμογής
▍Ατομικές αναπτύξεις
Μια άλλη λύση που μας βοήθησε να φτάσουμε σε ένα σύστημα ανάπτυξης πολλαπλών επιπέδων ήταν η ατομική ανάπτυξη.
Πριν χρησιμοποιήσετε ατομικές αναπτύξεις, κάθε ανάπτυξη θα μπορούσε να οδηγήσει σε μεγάλο αριθμό μηνυμάτων σφάλματος. Το γεγονός είναι ότι η διαδικασία αντιγραφής νέων αρχείων σε διακομιστές παραγωγής δεν ήταν ατομική. Αυτό είχε ως αποτέλεσμα ένα σύντομο χρονικό διάστημα όπου ο κώδικας που καλούσε νέες συναρτήσεις ήταν διαθέσιμος πριν οι ίδιες οι συναρτήσεις ήταν διαθέσιμες. Όταν κλήθηκε τέτοιος κωδικός, είχε ως αποτέλεσμα την επιστροφή εσωτερικών σφαλμάτων. Αυτό εκδηλώθηκε σε αποτυχημένα αιτήματα API και κατεστραμμένες ιστοσελίδες.
Η ομάδα που εργάστηκε σε αυτό το πρόβλημα το έλυσε εισάγοντας την έννοια των καταλόγων "hot" και "cold". Ο κωδικός στον hot κατάλογο είναι υπεύθυνος για την επεξεργασία της κυκλοφορίας παραγωγής. Και σε «ψυχρούς» καταλόγους, ο κώδικας, ενώ το σύστημα εκτελείται, προετοιμάζεται μόνο για χρήση. Κατά την ανάπτυξη, ο νέος κώδικας αντιγράφεται σε έναν αχρησιμοποίητο ψυχρό κατάλογο. Στη συνέχεια, όταν δεν υπάρχουν ενεργές διεργασίες στον διακομιστή, εκτελείται ένας άμεσος διακόπτης καταλόγου.
1. Αποσυσκευασία του κωδικού της εφαρμογής σε έναν "κρύο" κατάλογο. 2. Αλλαγή του συστήματος σε έναν "κρύο" κατάλογο, ο οποίος γίνεται "hot" (ατομική λειτουργία)
Αποτελέσματα: μετατόπιση της έμφασης στην αξιοπιστία
Το 2018, το έργο αυξήθηκε σε τέτοια κλίμακα που η πολύ γρήγορη ανάπτυξη άρχισε να βλάπτει τη σταθερότητα του προϊόντος. Είχαμε ένα πολύ προηγμένο σύστημα ανάπτυξης στο οποίο επενδύσαμε πολύ χρόνο και προσπάθεια. Το μόνο που χρειαζόταν να κάνουμε ήταν να ξαναχτίσουμε και να βελτιώσουμε τις διαδικασίες ανάπτυξής μας. Έχουμε εξελιχθεί σε μια αρκετά μεγάλη εταιρεία, της οποίας οι εξελίξεις έχουν χρησιμοποιηθεί σε όλο τον κόσμο για την οργάνωση αδιάλειπτων επικοινωνιών και την επίλυση σημαντικών προβλημάτων. Ως εκ τούτου, η αξιοπιστία έγινε το επίκεντρο της προσοχής μας.
Έπρεπε να κάνουμε τη διαδικασία ανάπτυξης νέων εκδόσεων Slack πιο ασφαλή. Αυτή η ανάγκη μας οδήγησε να βελτιώσουμε το σύστημα ανάπτυξής μας. Στην πραγματικότητα, συζητήσαμε αυτό το βελτιωμένο σύστημα παραπάνω. Στα βάθη του συστήματος, συνεχίζουμε να χρησιμοποιούμε τεχνολογίες γρήγορης και ατομικής ανάπτυξης. Ο τρόπος με τον οποίο γίνεται η ανάπτυξη έχει αλλάξει. Το νέο μας σύστημα έχει σχεδιαστεί για να αναπτύσσει σταδιακά νέο κώδικα σε διαφορετικά επίπεδα, σε διαφορετικά περιβάλλοντα. Τώρα χρησιμοποιούμε πιο προηγμένα εργαλεία υποστήριξης και εργαλεία παρακολούθησης συστήματος από πριν. Αυτό μας δίνει τη δυνατότητα να εντοπίσουμε και να διορθώσουμε σφάλματα πολύ πριν έχουν την ευκαιρία να φτάσουν στον τελικό χρήστη.
Αλλά δεν πρόκειται να σταματήσουμε εκεί. Βελτιώνουμε συνεχώς αυτό το σύστημα, χρησιμοποιώντας πιο προηγμένα βοηθητικά εργαλεία και εργαλεία αυτοματισμού εργασίας.
Αγαπητοί αναγνώστες! Πώς λειτουργεί η διαδικασία ανάπτυξης νέων εκδόσεων έργων όπου εργάζεστε;
Πηγή: www.habr.com