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

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

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

"Δεν υπάρχει τέτοιο πράγμα όπως μηδενικό επίπεδο, δεν ξέρω κάτι τέτοιο"
Master Shifu από την ταινία "Kung Fu Panda"

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

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

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

Φτάνουμε στην ιδέα του δικού μας συστήματος

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

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

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

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

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

Αυτοματοποιούμε τις δοκιμές

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

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

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

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

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

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

Layer κέικ αυτοματισμού στο CIAN

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

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

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

Αθικτος

Ας εστιάσουμε στο Integro και ας ξεκινήσουμε με τη στοίβα τεχνολογίας:

• CentOS 7
• Docker + Nomad + Consul + Vault
• Java 11 (το παλιό μονόλιθο Integro θα παραμείνει στην Java 8)
• Spring Boot 2.X + Spring Cloud Config
• PostgreSql 11
• RabbitMQ 
• Apache Ignite
• Camunda (ενσωματωμένο)
• Grafana + Graphite + Prometheus + Jaeger + ELK
• Web UI: React (CSR) + MobX
• SSO: Keycloak

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

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

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

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

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

Εργασίες ροής εργασιών

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

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

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

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

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

Κίνηση εργασίας

Ας δούμε τα κύρια βήματα που εκτελούνται όταν μια εργασία μετακινείται στη ροή εργασίας «Δοκιμές DEV + Δοκιμές Καναρίων»:

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

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

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

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

5. Μέσα στην υπηρεσία ροής:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Πηγή: www.habr.com