Στο GitLab, επεξεργαζόμαστε επιδιορθώσεις λογισμικού με δύο τρόπους: χειροκίνητα και αυτόματα. Διαβάστε παρακάτω για να μάθετε για τη δουλειά του διαχειριστή εκδόσεων για τη δημιουργία και την παράδοση σημαντικών ενημερώσεων μέσω αυτοματοποιημένης ανάπτυξης στο gitlab.com, καθώς και ενημερώσεων κώδικα με τις οποίες οι χρήστες μπορούν να εργαστούν στις δικές τους εγκαταστάσεις.
Συνιστώ να ορίσετε μια υπενθύμιση στο smartwatch σας: κάθε μήνα στις 22, οι χρήστες που εργάζονται με το GitLab στις εγκαταστάσεις τους μπορούν να βλέπουν ενημερώσεις για την τρέχουσα έκδοση του προϊόντος μας. Η μηνιαία έκδοση περιέχει νέες δυνατότητες, εξελίξεις υπαρχόντων και συχνά εμφανίζει το τελικό αποτέλεσμα αιτημάτων κοινότητας για εργαλεία ή συγχωνεύσεις.
Όμως, όπως δείχνει η πρακτική, η ανάπτυξη λογισμικού σπάνια είναι χωρίς ελαττώματα. Όταν ανακαλύπτεται ένα σφάλμα ή μια ευπάθεια ασφαλείας, ο διαχειριστής έκδοσης στην ομάδα παράδοσης δημιουργεί μια ενημέρωση κώδικα για τους χρήστες μας με τις εγκαταστάσεις τους. Το Gitlab.com ενημερώνεται κατά τη διαδικασία του CD. Ονομάζουμε αυτή τη διαδικασία CD αυτόματη ανάπτυξη για να αποφευχθεί η σύγχυση με τη δυνατότητα CD στο GitLab. Αυτή η διαδικασία μπορεί να ενσωματώσει προτάσεις από αιτήματα έλξης που υποβάλλονται από χρήστες, πελάτες και την εσωτερική μας ομάδα ανάπτυξης, έτσι ώστε η επίλυση του βαρετού προβλήματος της έκδοσης ενημερώσεων κώδικα να επιλύεται με δύο πολύ διαφορετικούς τρόπους.
«Διασφαλίζουμε ότι ό,τι φτιάχνουν οι προγραμματιστές αναπτύσσεται σε όλα τα περιβάλλοντα κάθε μέρα πριν το διαθέσουμε στο GitLab.com», εξηγεί , Ανώτερος Τεχνικός Διευθυντής, Τμήμα Υποδομών. "Σκεφτείτε τις εκδόσεις για τις εγκαταστάσεις σας ως στιγμιότυπα για τις αναπτύξεις του gitlab.com, για τις οποίες έχουμε προσθέσει ξεχωριστά βήματα για τη δημιουργία ενός πακέτου, ώστε οι χρήστες μας να μπορούν να το χρησιμοποιήσουν για εγκατάσταση στις εγκαταστάσεις τους».
Ανεξάρτητα από το σφάλμα ή την ευπάθεια, οι πελάτες του gitlab.com θα λάβουν διορθώσεις λίγο μετά τη δημοσίευσή τους, κάτι που αποτελεί πλεονέκτημα της αυτοματοποιημένης διαδικασίας CD. Οι ενημερώσεις κώδικα για χρήστες με τις δικές τους εγκαταστάσεις απαιτούν ξεχωριστή προετοιμασία από τον διαχειριστή έκδοσης.
Η ομάδα παράδοσης εργάζεται σκληρά για να αυτοματοποιήσει τις περισσότερες από τις διαδικασίες που εμπλέκονται στη δημιουργία εκδόσεων για μείωση (μέσος χρόνος μέχρι την παραγωγή, δηλαδή χρόνος που δαπανάται για την παραγωγή), η χρονική περίοδος από την επεξεργασία ενός αιτήματος συγχώνευσης από έναν προγραμματιστή έως την ανάπτυξη στο gitlab.com.
«Ο στόχος της ομάδας παράδοσης είναι να διασφαλίσει ότι μπορούμε να κινηθούμε πιο γρήγορα ως εταιρεία ή τουλάχιστον να κάνουμε τους ανθρώπους παράδοσης να λειτουργούν πιο γρήγορα, σωστά?, λέει ο Μάριν.
Τόσο οι πελάτες του gitlab.com όσο και οι χρήστες των εγκαταστάσεων τους επωφελούνται από τις προσπάθειες της ομάδας παράδοσης να μειώσει τους χρόνους κύκλου και να επιταχύνει τις αναπτύξεις. Σε αυτό το άρθρο θα εξηγήσουμε τις ομοιότητες και τις διαφορές μεταξύ αυτών των δύο μεθόδων. , και θα περιγράψουμε επίσης πώς η ομάδα παράδοσης προετοιμάζει ενημερώσεις κώδικα για χρήστες που εργάζονται στις εγκαταστάσεις τους, καθώς και πώς διασφαλίζουμε ότι το gitlab.com είναι ενημερωμένο χρησιμοποιώντας την αυτοματοποιημένη ανάπτυξη.
Τι κάνει ένας διαχειριστής έκδοσης;
Τα μέλη της ομάδας μηνιαίως τις εκδόσεις μας στους χρήστες στις εγκαταστάσεις τους, συμπεριλαμβανομένων των ενημερώσεων κώδικα και των εκδόσεων ασφαλείας που ενδέχεται να προκύψουν μεταξύ των εκδόσεων. Είναι επίσης υπεύθυνοι για την καθοδήγηση της μετάβασης της εταιρείας στην αυτοματοποιημένη, συνεχή ανάπτυξη.
Οι εκδόσεις αυτο-εγκατάστασης και οι εκδόσεις του gitlab.com χρησιμοποιούν παρόμοιες ροές εργασίας, αλλά εκτελούνται σε διαφορετικούς χρόνους, εξηγεί ο Marin.
Πρώτα και κύρια, ο διαχειριστής έκδοσης, ανεξάρτητα από τον τύπο έκδοσης, διασφαλίζει ότι το GitLab είναι διαθέσιμο και ασφαλές από τη στιγμή που εκκινείται η εφαρμογή στο gitlab.com, συμπεριλαμβανομένης της διασφάλισης ότι τα ίδια ζητήματα δεν καταλήγουν στην υποδομή των πελατών με τους δικές του ικανότητες.
Μόλις ένα σφάλμα ή μια ευπάθεια επισημανθεί ως διορθωμένη στο GitLab, ο διαχειριστής εκδόσεων πρέπει να αξιολογήσει ότι θα συμπεριληφθεί στις ενημερώσεις κώδικα ή τις ενημερώσεις ασφαλείας για τους χρήστες με τις εγκαταστάσεις τους. Εάν αποφασίσει ότι ένα σφάλμα ή μια ευπάθεια αξίζει μια ενημέρωση, ξεκινά η προπαρασκευαστική εργασία.
Ο διαχειριστής έκδοσης πρέπει να αποφασίσει εάν θα προετοιμάσει μια επιδιόρθωση ή πότε θα την αναπτύξει - και αυτό εξαρτάται σε μεγάλο βαθμό από το πλαίσιο της κατάστασης, "Εν τω μεταξύ, οι μηχανές δεν είναι τόσο καλές στη διαχείριση του πλαισίου όσο οι άνθρωποι" λέει ο Μάριν.
Είναι όλα σχετικά με τις διορθώσεις
Τι είναι τα patches και γιατί τα χρειαζόμαστε;
Ο διαχειριστής έκδοσης αποφασίζει εάν θα κυκλοφορήσει μια επιδιόρθωση με βάση τη σοβαρότητα του σφάλματος.
Τα σφάλματα ποικίλλουν ανάλογα με τη σοβαρότητά τους. Έτσι, τα σφάλματα S4 ή S3 μπορεί να είναι στυλιστικά, όπως η μετατόπιση εικονοστοιχείων ή εικονιδίων. Αυτό δεν είναι λιγότερο σημαντικό, αλλά δεν υπάρχει σημαντικός αντίκτυπος στη ροή εργασίας κανενός, πράγμα που σημαίνει ότι η πιθανότητα να δημιουργηθεί μια επιδιόρθωση για τέτοια σφάλματα S3 ή S4 είναι μικρή, εξηγεί ο Marin.
Ωστόσο, τα τρωτά σημεία S1 ή S2 σημαίνουν ότι ο χρήστης δεν πρέπει να ενημερώσει στην πιο πρόσφατη έκδοση ή υπάρχει ένα σημαντικό σφάλμα που επηρεάζει τη ροή εργασίας του χρήστη. Εάν περιλαμβάνονται στο tracker, πολλοί χρήστες τα έχουν συναντήσει, επομένως ο διαχειριστής έκδοσης ξεκινά αμέσως την προετοιμασία μιας επιδιόρθωσης.
Μόλις είναι έτοιμη μια ενημερωμένη έκδοση κώδικα για ευπάθειες S1 ή S2, ο διαχειριστής έκδοσης ξεκινά την έκδοση της ενημέρωσης κώδικα.
Για παράδειγμα, η ενημερωμένη έκδοση κώδικα GitLab 12.10.1 δημιουργήθηκε αφού εντοπίστηκαν πολλά ζητήματα αποκλεισμού και οι προγραμματιστές διόρθωσαν το υποκείμενο ζήτημα που τα προκαλούσε. Ο υπεύθυνος έκδοσης αξιολόγησε την ορθότητα των επιπέδων σοβαρότητας που έχουν εκχωρηθεί και, μετά την επιβεβαίωση, ξεκίνησε η διαδικασία έκδοσης μιας επιδιόρθωσης, η οποία ήταν έτοιμη εντός XNUMX ωρών μετά την ανακάλυψη των προβλημάτων αποκλεισμού.
Όταν συγκεντρώνονται πολλά S4, S3 και S2, ο διαχειριστής έκδοσης εξετάζει το πλαίσιο για να προσδιορίσει τον επείγοντα χαρακτήρα της κυκλοφορίας μιας επιδιόρθωσης και όταν επιτευχθεί ένας συγκεκριμένος αριθμός από αυτά, συνδυάζονται και απελευθερώνονται όλα. Οι διορθώσεις μετά την κυκλοφορία ή οι ενημερώσεις ασφαλείας συνοψίζονται σε αναρτήσεις ιστολογίου.
Πώς ένας διαχειριστής έκδοσης δημιουργεί ενημερώσεις κώδικα
Χρησιμοποιούμε το GitLab CI και άλλες δυνατότητες όπως το ChatOps μας για τη δημιουργία ενημερώσεων κώδικα. Το Release Manager ξεκινά την κυκλοφορία της επιδιόρθωσης ενεργοποιώντας την ομάδα ChatOps στο εσωτερικό μας κανάλι #releases στο Slack.
/chatops run release prepare 12.10.1Το ChatOps λειτουργεί μέσα στο Slack για να ενεργοποιήσει διαφορετικά συμβάντα, τα οποία στη συνέχεια επεξεργάζονται και εκτελούνται από το GitLab. Για παράδειγμα, η ομάδα παράδοσης δημιούργησε το ChatOps για να αυτοματοποιήσει διάφορα πράγματα για την έκδοση ενημερώσεων κώδικα.
Μόλις ο διαχειριστής έκδοσης ξεκινήσει την ομάδα ChatOps στο Slack, η υπόλοιπη εργασία γίνεται αυτόματα στο GitLab χρησιμοποιώντας το CICD. Υπάρχει αμφίδρομη επικοινωνία μεταξύ ChatOps στο Slack και GitLab κατά τη διαδικασία έκδοσης, καθώς ο διαχειριστής έκδοσης ενεργοποιεί μερικά από τα κύρια βήματα της διαδικασίας.
Το παρακάτω βίντεο δείχνει την τεχνική διαδικασία προετοιμασίας ενός patch για το GitLab.
Πώς λειτουργεί η αυτόματη ανάπτυξη στο gitlab.com
Η διαδικασία και τα εργαλεία που χρησιμοποιούνται για την ενημέρωση του gitlab.com είναι παρόμοια με αυτά που χρησιμοποιούνται για τη δημιουργία ενημερώσεων κώδικα. Η ενημέρωση του gitlab.com απαιτεί λιγότερη χειρωνακτική εργασία από την πλευρά του διαχειριστή έκδοσης.
Αντί να εκτελούμε αναπτύξεις χρησιμοποιώντας ChatOps, χρησιμοποιούμε χαρακτηριστικά CI π.χ. , με το οποίο ο διαχειριστής έκδοσης μπορεί να προγραμματίσει ορισμένες ενέργειες που θα εκτελεστούν την απαιτούμενη ώρα. Αντί για μη αυτόματη διαδικασία, υπάρχει μια διοχέτευση που εκτελείται περιοδικά μία φορά την ώρα που κατεβάζει τις νέες αλλαγές που έγιναν στα έργα GitLab, τις συσκευάζει και προγραμματίζει την ανάπτυξη και εκτελεί αυτόματα δοκιμές, QA και άλλα απαραίτητα βήματα.
"Έχουμε λοιπόν πολλές αναπτύξεις που εκτελούνται σε διαφορετικά περιβάλλοντα πριν από το gitlab.com και αφού αυτά τα περιβάλλοντα είναι σε καλή κατάσταση και οι δοκιμές δείξουν καλά αποτελέσματα, ο διαχειριστής έκδοσης ξεκινά τις ενέργειες ανάπτυξης του gitlab.com", λέει ο Marin.
Η τεχνολογία CICD για την υποστήριξη ενημερώσεων του gitlab.com αυτοματοποιεί ολόκληρη τη διαδικασία στο σημείο όπου ο διαχειριστής έκδοσης πρέπει να εκκινήσει με μη αυτόματο τρόπο την ανάπτυξη του περιβάλλοντος παραγωγής στο gitlab.com.
Ο Marin αναφέρει λεπτομερώς τη διαδικασία ενημέρωσης του gitlab.com στο παρακάτω βίντεο.
Τι άλλο κάνει η ομάδα παράδοσης;
Η κύρια διαφορά μεταξύ των διαδικασιών ενημέρωσης του gitlab.com και της έκδοσης ενημερώσεων κώδικα σε πελάτες εσωτερικού είναι ότι η τελευταία διαδικασία απαιτεί περισσότερο χρόνο και περισσότερη χειρωνακτική εργασία από τον διαχειριστή έκδοσης.
«Μερικές φορές καθυστερούμε την έκδοση ενημερώσεων κώδικα σε πελάτες με τις εγκαταστάσεις τους λόγω αναφερόμενων προβλημάτων, προβλημάτων εργαλείων και επειδή υπάρχουν πολλές αποχρώσεις που πρέπει να ληφθούν υπόψη κατά την κυκλοφορία μιας ενημερωμένης ενημέρωσης κώδικα», λέει ο Marin.
Ένας από τους βραχυπρόθεσμους στόχους της ομάδας παράδοσης είναι να μειώσει τον όγκο της χειρωνακτικής εργασίας από την πλευρά του υπεύθυνου έκδοσης για να επιταχύνει την κυκλοφορία. Η ομάδα εργάζεται για την απλοποίηση, τον εξορθολογισμό και την αυτοματοποίηση της διαδικασίας έκδοσης, η οποία θα βοηθήσει στη λήψη επιδιορθώσεων σε ζητήματα χαμηλής σοβαρότητας (S3 και S4, περίπου. μεταφράστης). Η εστίαση στην ταχύτητα είναι ένας βασικός δείκτης απόδοσης: είναι απαραίτητο να μειωθεί το MTTP - ο χρόνος από τη λήψη ενός αιτήματος συγχώνευσης έως την ανάπτυξη του αποτελέσματος στο gitlab.com - από τις τρέχουσες 50 ώρες σε 8 ώρες.
Η ομάδα παράδοσης εργάζεται επίσης για τη μετεγκατάσταση του gitlab.com σε μια υποδομή που βασίζεται στο Kubernetes.
Συντάκτης n.b.: Εάν έχετε ήδη ακούσει για την τεχνολογία Kubernetes (και δεν έχω καμία αμφιβολία ότι έχετε), αλλά δεν την έχετε αγγίξει ακόμα με τα χέρια σας, σας προτείνω να πάρετε μέρος σε διαδικτυακά εντατικά μαθήματα , που θα διεξαχθεί 28-30 Σεπτεμβρίου, και , που θα πραγματοποιηθεί 14–16 Οκτωβρίου. Αυτό θα σας επιτρέψει να πλοηγηθείτε με σιγουριά και να εργαστείτε με την τεχνολογία.
Αυτές είναι δύο προσεγγίσεις που επιδιώκουν τον ίδιο στόχο: γρήγορη παράδοση ενημερώσεων, τόσο για το gitlab.com όσο και για πελάτες στις εγκαταστάσεις τους.
Κάποιες ιδέες ή προτάσεις για εμάς;
Όλοι είναι ευπρόσδεκτοι να συνεισφέρουν στο GitLab και καλωσορίζουμε τα σχόλια των αναγνωστών μας. Εάν έχετε οποιεσδήποτε ιδέες για την ομάδα παράδοσης μας, μη διστάσετε με ειδοποίηση team: Delivery.
Πηγή: www.habr.com