Από τα σενάρια στη δική μας πλατφόρμα: Πώς αυτοματοποιήσαμε την ανάπτυξη στο CIAN

Στο RIT 2019, ο συνάδελφός μας Αλεξάντερ Κορότκοφ έκανε την έκθεση Σχετικά με τον αυτοματισμό ανάπτυξης στην CIAN: για να απλοποιήσουμε τη ζωή και την εργασία, χρησιμοποιούμε τη δική μας πλατφόρμα Integro. Παρακολουθεί τον κύκλο ζωής των εργασιών, απαλλάσσει τους προγραμματιστές από τις συνήθεις λειτουργίες και μειώνει σημαντικά τον αριθμό των σφαλμάτων στην παραγωγή. Σε αυτήν την ανάρτηση, θα συμπληρώσουμε την αναφορά του Alexander και θα σας πούμε πώς περάσαμε από απλά σενάρια στη συγχώνευση προϊόντων ανοιχτού κώδικα μέσω της δικής μας πλατφόρμας και τι κάνει η ξεχωριστή ομάδα αυτοματισμού μας.
 

Μηδενικό επίπεδο

«Δεν υπάρχει κάτι τέτοιο όπως το μηδενικό επίπεδο, δεν γνωρίζω κανένα.»
Ο Δάσκαλος Σίφου από την ταινία "Κουνγκ Φου Πάντα"

Ο αυτοματισμός στην CIAN ξεκίνησε 14 χρόνια μετά την ίδρυση της εταιρείας. Εκείνη την εποχή, η ομάδα ανάπτυξης αποτελούνταν από 35 άτομα. Δύσκολο να το πιστέψει κανείς, σωστά; Φυσικά, ο αυτοματισμός υπήρχε με κάποια μορφή, αλλά μια ξεχωριστή κατεύθυνση για συνεχή ενσωμάτωση και παράδοση κώδικα άρχισε να διαμορφώνεται το 2015. 

Εκείνη την εποχή, είχαμε αναπτύξει ένα τεράστιο μονόλιθο Python, C# και PHP σε διακομιστές Linux/Windows. Για να αναπτύξουμε αυτό το τέρας, είχαμε ένα σύνολο σεναρίων που εκτελούσαμε χειροκίνητα. Υπήρχε επίσης η συναρμολόγηση μονόλιθου, η οποία έφερνε πόνο και ταλαιπωρία λόγω συγκρούσεων κατά τη συγχώνευση κλάδων, τη διόρθωση ελαττωμάτων και την ανακατασκευή "με ένα διαφορετικό σύνολο εργασιών στην κατασκευή". Απλουστευμένα, η διαδικασία έμοιαζε ως εξής:

Δεν μείναμε ικανοποιημένοι με αυτό και θέλαμε να δημιουργήσουμε μια επαναλήψιμη, αυτοματοποιημένη και ελεγχόμενη διαδικασία συναρμολόγησης και ανάπτυξης. Για αυτό, χρειαζόμασταν ένα σύστημα CI/CD και επιλέξαμε μεταξύ της δωρεάν έκδοσης του Teamcity και του δωρεάν Jenkins, καθώς συνεργαστήκαμε μαζί τους και και τα δύο μας ταίριαζαν όσον αφορά το σύνολο των λειτουργιών. Επιλέξαμε το Teamcity ως ένα πιο πρόσφατο προϊόν. Εκείνη την εποχή, δεν χρησιμοποιούσαμε ακόμη αρχιτεκτονική μικρουπηρεσιών και δεν περιμέναμε μεγάλο αριθμό εργασιών και έργων.

Καταλήγουμε στην ιδέα του δικού μας συστήματος

Η εφαρμογή του Teamcity αφαίρεσε μόνο ένα μέρος της χειροκίνητης εργασίας: υπήρχε ακόμα η δημιουργία αιτημάτων έλξης, η προώθηση εργασιών κατά κατάσταση στο Jira, η επιλογή εργασιών για έκδοση. Το σύστημα Teamcity δεν μπορούσε πλέον να το αντιμετωπίσει αυτό. Ήταν απαραίτητο να επιλέξουμε μια διαδρομή για περαιτέρω αυτοματοποίηση. Εξετάσαμε επιλογές για εργασία με σενάρια στο Teamcity ή μετάβαση σε συστήματα αυτοματισμού τρίτων. Αλλά τελικά, αποφασίσαμε ότι χρειαζόμασταν μέγιστη ευελιξία, την οποία παρέχει μόνο η δική μας λύση. Έτσι εμφανίστηκε η πρώτη έκδοση του εσωτερικού συστήματος αυτοματισμού που ονομάζεται Integro.

Η Teamcity ασχολείται με τον αυτοματισμό στο επίπεδο της έναρξης διαδικασιών κατασκευής και ανάπτυξης, ενώ η Integro επικεντρώθηκε στον αυτοματισμό υψηλού επιπέδου των διαδικασιών ανάπτυξης. Ήταν απαραίτητο να συνδυαστεί η εργασία με προβλήματα στο Jira με την επεξεργασία του σχετικού πηγαίου κώδικα στο Bitbucket. Σε αυτό το στάδιο, η Integro άρχισε να έχει τις δικές της ροές εργασίας για την εργασία με διαφορετικά είδη προβλημάτων. 

Λόγω της αύξησης του αυτοματισμού στις επιχειρηματικές διαδικασίες, ο αριθμός των έργων και των εκτελέσεων στο Teamcity αυξήθηκε. Έτσι, προέκυψε ένα νέο πρόβλημα: μια δωρεάν παρουσία Teamcity δεν ήταν αρκετή (3 agents και 100 έργα), προσθέσαμε μια άλλη παρουσία (άλλοι 3 agents και 100 έργα) και μετά μια άλλη. Ως αποτέλεσμα, αποκτήσαμε ένα σύστημα αρκετών clusters, το οποίο ήταν δύσκολο στη διαχείριση:

Όταν προέκυψε το ζήτημα της 4ης περίπτωσης, συνειδητοποιήσαμε ότι δεν μπορούσαμε να ζήσουμε έτσι άλλο, καθώς το συνολικό κόστος υποστήριξης 4 περιπτώσεων είχε ήδη ξεπεράσει κάθε όριο. Προέκυψε το ερώτημα αν θα αγοράσουμε ένα Teamcity επί πληρωμή ή αν θα επιλέξουμε το δωρεάν Jenkins. Κάναμε υπολογισμούς για τις περιπτώσεις και τα σχέδια αυτοματισμού και αποφασίσαμε ότι θα ζούσαμε με Jenkins. Μερικές εβδομάδες αργότερα, αλλάξαμε στην Jenkins και απαλλαγήκαμε από μερικούς από τους πονοκεφάλους που σχετίζονται με την υποστήριξη πολλαπλών περιπτώσεων Teamcity. Ως εκ τούτου, μπορέσαμε να επικεντρωθούμε στην ανάπτυξη του Integro και στη βελτίωση του Jenkins για εμάς.

Με την ανάπτυξη του βασικού αυτοματισμού (με τη μορφή αυτόματης δημιουργίας Pull Requests, συλλογής και δημοσίευσης κάλυψης κώδικα και άλλων ελέγχων), υπήρξε μια έντονη επιθυμία να εγκαταλειφθούν όσο το δυνατόν περισσότερο οι χειροκίνητες εκδόσεις και να ανατεθεί αυτή η εργασία σε ρομπότ. Επιπλέον, η εταιρεία άρχισε να μεταβαίνει σε μικροϋπηρεσίες, οι οποίες απαιτούσαν συχνές εκδόσεις και ξεχωριστά η μία από την άλλη. Έτσι, σταδιακά φτάσαμε σε αυτόματες εκδόσεις των μικρουπηρεσιών μας (το μονόλιθο εξακολουθεί να κυκλοφορεί χειροκίνητα λόγω της πολυπλοκότητας της διαδικασίας). Αλλά, όπως συμβαίνει συνήθως, προέκυψε μια νέα δυσκολία. 

Αυτοματοποίηση δοκιμών

Λόγω του αυτοματισμού των κυκλοφοριών, οι διαδικασίες ανάπτυξης επιταχύνθηκαν, εν μέρει λόγω της παράλειψης ορισμένων σταδίων δοκιμών. Και αυτό οδήγησε σε προσωρινή απώλεια ποιότητας. Ακούγεται ασήμαντο, αλλά μαζί με την επιτάχυνση των κυκλοφοριών, ήταν απαραίτητο να αλλάξει η μεθοδολογία ανάπτυξης προϊόντων. Ήταν απαραίτητο να σκεφτούμε τον αυτοματισμό δοκιμών, ενσταλάζοντας την προσωπική ευθύνη (εδώ μιλάμε για «αποδοχή της ιδέας στο κεφάλι», όχι για χρηματικά πρόστιμα) του προγραμματιστή για τον κυκλοφορούντα κώδικα και τα σφάλματα σε αυτόν, καθώς και για την απόφαση κυκλοφορίας/μη κυκλοφορίας μιας εργασίας μέσω αυτόματης ανάπτυξης. 

Ενώ εξαλείφαμε τα προβλήματα ποιότητας, καταλήξαμε σε δύο σημαντικές αποφάσεις: ξεκινήσαμε να κάνουμε δοκιμές Canary και εφαρμόσαμε αυτόματη παρακολούθηση ιστορικού σφαλμάτων με αυτόματη απόκριση στην περίσσεια. Η πρώτη λύση μας επέτρεψε να εντοπίσουμε προφανή σφάλματα πριν ο κώδικας κυκλοφορήσει πλήρως στην παραγωγή, ενώ η δεύτερη μείωσε τον χρόνο απόκρισης σε προβλήματα στην παραγωγή. Φυσικά, συμβαίνουν σφάλματα, αλλά αφιερώνουμε τον περισσότερο χρόνο και την προσπάθειά μας όχι στη διόρθωσή τους, αλλά στην ελαχιστοποίησή τους. 

Ομάδα Αυτοματισμού

Πλέον έχουμε ένα προσωπικό 130 προγραμματιστών και συνεχίζουμε να καλλιεργώΗ ομάδα συνεχούς ολοκλήρωσης και παράδοσης κώδικα (εφεξής καλούμενη ομάδα Ανάπτυξης και Ενσωμάτωσης ή DI) αποτελείται από 7 άτομα και εργάζεται σε 2 κατευθύνσεις: ανάπτυξη της πλατφόρμας αυτοματισμού Integro και DevOps. 

Το DevOps είναι υπεύθυνο για τα περιβάλλοντα Dev/Beta του ιστότοπου CIAN, τα περιβάλλοντα Integro, βοηθά τους προγραμματιστές να επιλύουν προβλήματα και αναπτύσσει νέες προσεγγίσεις για την κλιμάκωση περιβαλλόντων. Η κατεύθυνση ανάπτυξης του Integro ασχολείται τόσο με το ίδιο το Integro όσο και με σχετικές υπηρεσίες, όπως πρόσθετα για Jenkins, Jira, Confluence, και αναπτύσσει επίσης βοηθητικά βοηθητικά προγράμματα και εφαρμογές για ομάδες ανάπτυξης. 

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

Πολυεπίπεδη πίτα αυτοματισμού στο CIAN

Όλα τα συστήματα που εμπλέκονται στον αυτοματισμό μπορούν να χωριστούν σε διάφορα επίπεδα:

1. Εξωτερικά συστήματα (Jira, Bitbucket, κ.λπ.) Οι ομάδες ανάπτυξης συνεργάζονται με αυτά.
2. Πλατφόρμα Integro. Τις περισσότερες φορές, οι προγραμματιστές δεν συνεργάζονται απευθείας με αυτήν, αλλά είναι αυτή που υποστηρίζει τη λειτουργία όλων των αυτοματισμών.
3. Υπηρεσίες παράδοσης, ενορχήστρωσης και ανακάλυψης (π.χ. Jeknins, Consul, Nomad). Με τη βοήθειά τους, αναπτύσσουμε κώδικα σε διακομιστές και διασφαλίζουμε ότι οι υπηρεσίες συνεργάζονται μεταξύ τους.
4. Φυσικό επίπεδο (διακομιστές, λειτουργικό σύστημα, σχετικό λογισμικό). Ο κώδικάς μας λειτουργεί σε αυτό το επίπεδο. Μπορεί να είναι είτε φυσικός διακομιστής είτε εικονικός (LXC, KVM, Docker).

Με βάση αυτήν την έννοια, διαιρούμε τους τομείς ευθύνης εντός της ομάδας DI. Τα δύο πρώτα επίπεδα βρίσκονται υπό την ευθύνη της διεύθυνσης ανάπτυξης Integro, και τα δύο τελευταία επίπεδα βρίσκονται ήδη υπό την ευθύνη του DevOps. Αυτή η διαίρεση μας επιτρέπει να επικεντρωνόμαστε στις εργασίες και δεν παρεμβαίνει στην αλληλεπίδραση, καθώς είμαστε κοντά ο ένας στον άλλον και ανταλλάσσουμε συνεχώς γνώσεις και εμπειρίες.

Αθικτος

Ας επικεντρωθούμε στο Integro και ας ξεκινήσουμε με το τεχνολογικό stack:

• CentOS 7
• Λιμενεργάτης + Νομάδας + Πρόξενος + Θησαυροφυλάκιο
• Java 11 (ο παλιός μονόλιθος Integro θα παραμείνει στην Java 8)
• Spring Boot 2.X + Διαμόρφωση Spring Cloud
• PostgreSQL 11
• RabbitMQ 
• Apache Ignite
• Camunda (ενσωματωμένο)
• Grafana + Graphite + Prometheus + Jaeger + ELK
• UI ιστού: React (CSR) + MobX
• SSO: Κλειδομάντη

Τηρούμε την αρχή της ανάπτυξης μικροϋπηρεσιών, αν και έχουμε την κληρονομιά με τη μορφή ενός μονόλιθου μιας πρώιμης έκδοσης του Integro. Κάθε μικροϋπηρεσία εκτελείται στο δικό της κοντέινερ Docker, οι υπηρεσίες επικοινωνούν μεταξύ τους μέσω αιτημάτων HTTP και μηνυμάτων RabbitMQ. Οι μικροϋπηρεσίες εντοπίζουν η μία την άλλη μέσω του Consul και υποβάλλουν ένα αίτημα σε αυτό, μεταβιβάζοντας εξουσιοδότηση μέσω SSO (Keycloak, OAuth 2/OpenID Connect).

Ως πραγματικό παράδειγμα, ας εξετάσουμε την αλληλεπίδραση με την Jenkins, η οποία αποτελείται από τα ακόλουθα βήματα:

1. Η μικρουπηρεσία διαχείρισης ροής εργασίας (εφεξής καλούμενη μικρουπηρεσία Flow) θέλει να ξεκινήσει μια κατασκευή στο Jenkins. Για να το κάνει αυτό, χρησιμοποιεί το Consul για να βρει το IP:PORT της μικρουπηρεσίας ενοποίησης Jenkins (εφεξής καλούμενη μικρουπηρεσία Jenkins) και της στέλνει ένα ασύγχρονο αίτημα για να ξεκινήσει μια κατασκευή στο Jenkins.
2. Αφού λάβει ένα αίτημα, η μικρουπηρεσία Jenkins δημιουργεί και επιστρέφει ένα Job ID ως απάντηση, το οποίο μπορεί στη συνέχεια να χρησιμοποιηθεί για τον προσδιορισμό του αποτελέσματος της εργασίας. Ταυτόχρονα, εκκινεί την κατασκευή στο Jenkins μέσω μιας κλήσης REST API.
3. Ο Jenkins εκτελεί την κατασκευή και, μόλις ολοκληρωθεί, στέλνει ένα webhook με τα αποτελέσματα εκτέλεσης στην μικρουπηρεσία Jenkins.
4. Η μικρουπηρεσία Jenkins, αφού λάβει το webhook, δημιουργεί ένα μήνυμα σχετικά με το τέλος της επεξεργασίας αιτήματος και επισυνάπτει τα αποτελέσματα εκτέλεσης σε αυτό. Το δημιουργημένο μήνυμα αποστέλλεται στην ουρά RabbitMQ.
5. Μέσω του RabbitMQ, το δημοσιευμένο μήνυμα φτάνει στην μικρουπηρεσία Flow, η οποία μαθαίνει για το αποτέλεσμα της επεξεργασίας της εργασίας της αντιστοιχίζοντας το Job ID από το αίτημα και το ληφθέν μήνυμα.

Αυτή τη στιγμή διαθέτουμε περίπου 30 μικροϋπηρεσίες, οι οποίες μπορούν να χωριστούν σε διάφορες ομάδες:

1. Διαχείριση διαμόρφωσης.
2. Ενημέρωση και αλληλεπίδραση με χρήστες (messenger, αλληλογραφία).
3. Εργασία με τον πηγαίο κώδικα.
4. Ενσωμάτωση με εργαλεία ανάπτυξης (jenkins, nomad, consul, κ.λπ.).
5. Παρακολούθηση (εκδόσεις, σφάλματα κ.λπ.).
6. Βοηθητικά προγράμματα ιστού (UI για τη διαχείριση περιβαλλόντων δοκιμών, τη συλλογή στατιστικών στοιχείων κ.λπ.).
7. Ενσωμάτωση με συστήματα παρακολούθησης εργασιών και παρόμοια συστήματα.
8. Διαχείριση ροής εργασίας για διαφορετικές εργασίες.

Εργασίες ροής εργασίας

Το Integro αυτοματοποιεί ενέργειες που σχετίζονται με τον κύκλο ζωής των εργασιών. Με απλά λόγια, ο κύκλος ζωής των εργασιών είναι η ροή εργασίας στο Jira. Στις διαδικασίες ανάπτυξής μας, υπάρχουν αρκετές παραλλαγές ροής εργασίας ανάλογα με το έργο, τον τύπο της εργασίας και τις επιλογές που έχουν επιλεγεί σε μια συγκεκριμένη εργασία. 

Ας δούμε τη ροή εργασίας που χρησιμοποιούμε πιο συχνά:

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

Πλήρως χειροκίνητες δοκιμές σε DEV+BETA χωρίς δοκιμές Canary (συνήθως έτσι κυκλοφορούμε ένα μονόλιθο):

Ενδέχεται να υπάρχουν και άλλοι συνδυασμοί μετάβασης. Μερικές φορές, η διαδρομή που θα ακολουθήσει μια εργασία μπορεί να επιλεγεί μέσω επιλογών στο Jira.

Κίνηση εργασιών

Ας δούμε τα κύρια βήματα που εκτελούνται όταν μια εργασία μετακινείται μέσω της ροής εργασίας "DEV Testing + Canary Tests":

1. Ο προγραμματιστής ή ο διαχειριστής έργου δημιουργεί μια εργασία.

2. Ο προγραμματιστής αναλαμβάνει την εργασία. Μετά την ολοκλήρωσή της, τη μεταφέρει στην κατάσταση ΣΕ ΑΝΑΘΕΩΡΗΣΗ.

3. Το Jira στέλνει ένα Webhook προς την μικρουπηρεσία Jira (υπεύθυνη για την ενσωμάτωση με το Jira).

4. Η μικρουπηρεσία Jira στέλνει ένα αίτημα στην υπηρεσία Flow (υπεύθυνη για τις εσωτερικές ροές εργασίας στις οποίες εκτελείται εργασία) για να ξεκινήσει η ροή εργασίας.

5. Μέσα στην υπηρεσία Flow:

• Οι αναθεωρητές αναλαμβάνουν την εργασία (μικροϋπηρεσία χρηστών, η οποία γνωρίζει τα πάντα για τους χρήστες + μικροϋπηρεσία Jira).
• Η μικρουπηρεσία Source (γνωρίζει τα αποθετήρια και τα κλαδιά, αλλά δεν λειτουργεί με τον ίδιο τον κώδικα) αναζητά αποθετήρια που έχουν ένα κλαδί της εργασίας μας (για απλοποίηση της αναζήτησης, το όνομα του κλάδου ταιριάζει με τον αριθμό της εργασίας στο Jira). Τις περισσότερες φορές, μια εργασία έχει μόνο ένα κλαδί σε ένα αποθετήριο, κάτι που απλοποιεί τη διαχείριση της ουράς ανάπτυξης και μειώνει τη σύνδεση μεταξύ των αποθετηρίων.
• Για κάθε κλάδο που βρέθηκε, εκτελείται η ακόλουθη ακολουθία ενεργειών:

  i) Συγχώνευση του κύριου κλάδου (μικροϋπηρεσία Git για εργασία με κώδικα).
  ii) Ο κλάδος είναι κλειδωμένος από αλλαγές από τον προγραμματιστή (μικροϋπηρεσία Bitbucket).
  iii) Δημιουργείται ένα αίτημα έλξης για αυτόν τον κλάδο (μικροϋπηρεσία Bitbucket).
  iv) Ένα μήνυμα σχετικά με ένα νέο αίτημα έλξης αποστέλλεται στις συνομιλίες των προγραμματιστών (Ειδοποίηση μικρουπηρεσίας για εργασία με ειδοποιήσεις).
  v) Ξεκινά η δημιουργία, ο έλεγχος και η ανάπτυξη εργασιών στο DEV (μικροϋπηρεσία Jenkins για εργασία με Jenkins).
  vi) Εάν όλα τα προηγούμενα βήματα ολοκληρωθούν με επιτυχία, τότε το Integro θέτει την Έγκριση στο Αίτημα Έλξης (μικροϋπηρεσία Bitbucket).

• Το Integro αναμένει έγκριση στο αίτημα λήψης από τους καθορισμένους αναθεωρητές.
• Μόλις ληφθούν όλες οι απαραίτητες εγκρίσεις (συμπεριλαμβανομένων των αυτοματοποιημένων δοκιμών που έχουν περάσει με επιτυχία), το Integro μετακινεί την εργασία στην κατάσταση Δοκιμή σε Ανάπτυξη (μικροϋπηρεσία Jira).

6. Οι δοκιμαστές δοκιμάζουν την εργασία. Εάν δεν υπάρχουν προβλήματα, μεταφέρουν την εργασία στην κατάσταση Έτοιμη για κατασκευή.

7. Το Integro "βλέπει" ότι η εργασία είναι έτοιμη για κυκλοφορία και ξεκινά την ανάπτυξή της σε λειτουργία canary (μικροϋπηρεσία Jenkins). Η ετοιμότητα για κυκλοφορία καθορίζεται από ένα σύνολο κανόνων. Για παράδειγμα, η εργασία βρίσκεται στην απαιτούμενη κατάσταση, δεν υπάρχουν κλειδώματα σε άλλες εργασίες, δεν υπάρχουν ενεργές αναπτύξεις αυτής της μικρουπηρεσίας αυτήν τη στιγμή, κ.λπ.

8. Η εργασία μεταφέρεται σε κατάσταση Canary (μικροϋπηρεσία Jira).

9. Ο Jenkins εκκινεί μια εργασία ανάπτυξης σε λειτουργία canary μέσω του Nomad (συνήθως 1-3 παρουσίες) και ειδοποιεί την υπηρεσία παρακολούθησης εκδόσεων (μικροϋπηρεσία DeployWatch) σχετικά με την ανάπτυξη.

10. Η μικρουπηρεσία DeployWatch συλλέγει το φόντο σφάλματος και αντιδρά σε αυτό, εάν είναι απαραίτητο. Όταν ξεπεραστεί το φόντο σφάλματος (ο ρυθμός φόντου υπολογίζεται αυτόματα), οι προγραμματιστές ειδοποιούνται μέσω της μικρουπηρεσίας Notify. Εάν ο προγραμματιστής δεν έχει απαντήσει εντός 5 λεπτών (πατώντας Επαναφορά ή Παραμονή), τότε ξεκινά μια αυτόματη επαναφορά των στιγμιότυπων του canary. Εάν δεν ξεπεραστεί το φόντο, τότε ο προγραμματιστής πρέπει να ξεκινήσει χειροκίνητα την ανάπτυξη εργασιών στην Παραγωγή (πατώντας το κουμπί στο περιβάλλον χρήστη). Εάν ο προγραμματιστής δεν έχει ξεκινήσει την ανάπτυξη στην Παραγωγή εντός 60 λεπτών, τότε οι στιγμιότυπα του canary θα επαναφερθούν επίσης για λόγους ασφαλείας.

11. Μετά την έναρξη της ανάπτυξης στην Παραγωγή:

• Η εργασία μεταφέρεται σε κατάσταση Παραγωγής (μικροϋπηρεσία Jira).
• Η μικρουπηρεσία Jenkins ξεκινά τη διαδικασία ανάπτυξης και ειδοποιεί την μικρουπηρεσία DeployWatch σχετικά με την ανάπτυξη.
• Η μικρουπηρεσία DeployWatch ελέγχει ότι όλα τα κοντέινερ στο Production έχουν ενημερωθεί (υπήρξαν περιπτώσεις όπου δεν ενημερώθηκαν όλα).
• Οι ειδοποιήσεις σχετικά με τα αποτελέσματα ανάπτυξης αποστέλλονται στην Παραγωγή μέσω της μικρουπηρεσίας Notify.

12. Οι προγραμματιστές θα έχουν 30 λεπτά για να ξεκινήσουν την επαναφορά της εργασίας από την Παραγωγή εάν εντοπιστεί λανθασμένη συμπεριφορά της μικρουπηρεσίας. Μετά από αυτό το χρονικό διάστημα, η εργασία θα συγχωνευθεί αυτόματα στην κύρια (μικροϋπηρεσία Git).

13. Μετά από μια επιτυχημένη συγχώνευση με την κύρια, η κατάσταση της εργασίας θα αλλάξει σε Κλειστή (μικροϋπηρεσία Jira).

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

Ποιο είναι το επόμενο

Έχουμε μεγάλα σχέδια για την ανάπτυξη αυτοματισμού, για παράδειγμα, την εξάλειψη των χειροκίνητων λειτουργιών κατά τη διάρκεια των κυκλοφοριών monolith, τη βελτίωση της παρακολούθησης κατά την αυτόματη ανάπτυξη και τη βελτίωση της αλληλεπίδρασης με τους προγραμματιστές.

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

Πηγή: www.habr.com