Μετάφραση του άρθρου που ετοιμάστηκε για φοιτητές του μαθήματος στο εκπαιδευτικό έργο OTUS.
Θα πρέπει να επιλέξετε ένα μονοαποθετήριο επειδή η συμπεριφορά που προωθεί στις ομάδες σας είναι η διαφάνεια και η κοινή ευθύνη, ειδικά καθώς οι ομάδες μεγαλώνουν. Είτε έτσι είτε αλλιώς, θα πρέπει να επενδύσετε σε εργαλεία, αλλά είναι πάντα καλύτερο εάν η προεπιλεγμένη συμπεριφορά είναι η συμπεριφορά που θέλετε στις εντολές σας.
Γιατί μιλάμε για αυτό;
Ο Ματ Κλάιν έγραψε το άρθρο (σημείωση μεταφραστή: μετάφραση στο Habré ). Μου αρέσει ο Matt, νομίζω ότι είναι πολύ έξυπνος και πρέπει να διαβάσετε την άποψή του. Αρχικά δημοσίευσε τη δημοσκόπηση στο Twitter:
Μετάφραση:
Αυτή την Πρωτοχρονιά, θα τσακωθώ για το πόσο γελοία είναι τα μονοαποθετήρια. Το 2019 ξεκίνησε ήσυχα. Στο πνεύμα αυτού, σας προσφέρω μια έρευνα. Ποιοι είναι οι μεγάλοι φανατικοί; Υποστηρικτές:
- Μονόρεπο
- Σκωρία
- Λανθασμένη δημοσκόπηση / και τα δύο
Η απάντησή μου ήταν: «Είμαι κυριολεκτικά και οι δύο αυτοί άνθρωποι». Αντί να μιλάμε για το πώς το Rust είναι ναρκωτικό, ας δούμε γιατί νομίζω ότι κάνει λάθος με τα μονοαποθετήρια. Λίγα λόγια για τον εαυτό σου. Είμαι ο CTO του Chef Software. Έχουμε περίπου 100 μηχανικούς, μια βάση κωδικών που χρονολογείται περίπου 11-12 χρόνια και 4 κύρια προϊόντα. Κάποιος από αυτόν τον κώδικα βρίσκεται σε πολυαποθήκη (η αρχική μου θέση), μερικοί είναι σε μονοαποθήκη (η τρέχουσα θέση μου).
Πριν ξεκινήσω: κάθε επιχείρημα που κάνω εδώ θα ισχύει και για τα δύο είδη αποθετηρίων. Κατά τη γνώμη μου, δεν υπάρχει κανένας τεχνικός λόγος για τον οποίο πρέπει να επιλέξετε έναν τύπο αποθετηρίου έναντι ενός άλλου. Μπορείτε να κάνετε οποιαδήποτε προσέγγιση να λειτουργήσει. Είμαι στην ευχάριστη θέση να μιλήσω για αυτό, αλλά δεν με ενδιαφέρουν τεχνητοί τεχνικοί λόγοι για τους οποίους το ένα είναι ανώτερο από το άλλο.
Συμφωνώ με το πρώτο μέρος της άποψης του Matt:
Επειδή σε κλίμακα, ένα monorepository θα λύσει όλα τα ίδια προβλήματα που λύνει ένα polyrepository, αλλά ταυτόχρονα θα σας αναγκάσει να συνδέσετε στενά τον κώδικά σας και απαιτώντας απίστευτες προσπάθειες για να αυξήσετε την επεκτασιμότητα του συστήματος ελέγχου έκδοσης.
Θα πρέπει να λύσετε τα ίδια προβλήματα ανεξάρτητα από το αν θα επιλέξετε ένα μονοθέσιο ή ένα πολυαποθήκη. Πώς βγάζετε εκδόσεις; Ποια είναι η προσέγγισή σας στις ενημερώσεις; Συμβατότητα προς τα πίσω; Διασταυρούμενες εξαρτήσεις έργων; Ποια αρχιτεκτονικά στυλ είναι αποδεκτά; Πώς διαχειρίζεστε την υποδομή κατασκευής και δοκιμής σας; Η λίστα είναι ατελείωτη. Και θα τα λύσετε όλα καθώς μεγαλώνετε. Δεν υπάρχει δωρεάν τυρί.
Νομίζω ότι το επιχείρημα του Matt είναι παρόμοιο με απόψεις που συμμερίζονται πολλοί μηχανικοί (και διευθυντές) που σέβομαι. Αυτό συμβαίνει από την οπτική γωνία του μηχανικού που εργάζεται στο εξάρτημα ή της ομάδας που εργάζεται στο εξάρτημα. Ακούτε πράγματα όπως:
- Η βάση κωδικών είναι ογκώδης - δεν χρειάζομαι όλα αυτά τα σκουπίδια.
- Είναι πιο δύσκολο να δοκιμάσω γιατί πρέπει να δοκιμάσω όλα αυτά τα σκουπίδια που δεν χρειάζομαι.
- Είναι πιο δύσκολο να δουλέψεις με εξωτερικές εξαρτήσεις.
- Χρειάζομαι τα δικά μου συστήματα ελέγχου εικονικών εκδόσεων.
Φυσικά, όλα αυτά τα σημεία είναι δικαιολογημένα. Αυτό συμβαίνει και στις δύο περιπτώσεις - στο polyrepository έχω τα δικά μου σκουπίδια, εκτός από αυτά που χρειάζονται για την κατασκευή... Μπορεί να χρειαστώ και άλλα σκουπίδια. Έτσι «απλά» δημιουργώ εργαλεία που ελέγχουν ολόκληρο το έργο. Ή δημιουργώ ένα ψεύτικο monorepository με υπομονάδες. Θα μπορούσαμε να περπατάμε γύρω από αυτό όλη την ημέρα. Αλλά νομίζω ότι το επιχείρημα του Matt παραλείπει τον κύριο λόγο, τον οποίο ανέτρεψα αρκετά υπέρ του monorepository:
Προκαλεί επικοινωνία και παρουσιάζει προβλήματα
Όταν διαχωρίζουμε τα αποθετήρια, δημιουργούμε ένα de facto πρόβλημα συντονισμού και διαφάνειας. Αυτό αντιστοιχεί στον τρόπο που σκεφτόμαστε για τις ομάδες (ειδικά τον τρόπο με τον οποίο σκέφτονται τα μεμονωμένα μέλη για αυτές): είμαστε υπεύθυνοι για ένα συγκεκριμένο στοιχείο. Δουλεύουμε σε σχετική απομόνωση. Τα όρια είναι καθορισμένα για την ομάδα μου και το στοιχείο πάνω στο οποίο εργαζόμαστε.
Καθώς η αρχιτεκτονική γίνεται πιο περίπλοκη, μια ομάδα δεν μπορεί πλέον να τη διαχειριστεί μόνη της. Πολύ λίγοι μηχανικοί έχουν ολόκληρο το σύστημα στο κεφάλι τους. Ας υποθέσουμε ότι διαχειρίζεστε ένα κοινόχρηστο στοιχείο Α που χρησιμοποιείται από τις ομάδες B, C και D. Η ομάδα Α αναδιαμορφώνει, βελτιώνει το API και αλλάζει επίσης την εσωτερική υλοποίηση. Ως αποτέλεσμα, οι αλλαγές δεν είναι συμβατές προς τα πίσω. Τι συμβουλή έχετε;
- Βρείτε όλα τα μέρη όπου χρησιμοποιείται το παλιό API.
- Υπάρχουν μέρη όπου το νέο API δεν μπορεί να χρησιμοποιηθεί;
- Μπορείτε να διορθώσετε και να δοκιμάσετε άλλα εξαρτήματα για να βεβαιωθείτε ότι δεν σπάνε;
- Μπορούν αυτές οι ομάδες να δοκιμάσουν τις αλλαγές σας αυτήν τη στιγμή;
Λάβετε υπόψη ότι αυτές οι ερωτήσεις είναι ανεξάρτητες από τον τύπο του αποθετηρίου. Θα χρειαστεί να βρείτε τις ομάδες Β, Γ και Δ. Θα χρειαστεί να μιλήσετε μαζί τους, να μάθετε την ώρα, να κατανοήσετε τις προτεραιότητές τους. Τουλάχιστον ελπίζουμε να το κάνετε.
Κανείς δεν θέλει πραγματικά να το κάνει αυτό. Αυτό είναι πολύ λιγότερο διασκεδαστικό από την απλή διόρθωση του καταραμένου API. Είναι όλα ανθρώπινα και ακατάστατα. Σε ένα πολυαποθετήριο, μπορείτε απλώς να κάνετε αλλαγές, να το δώσετε στα άτομα που εργάζονται σε αυτό το στοιχείο (πιθανότατα όχι B, C ή D) για έλεγχο και να προχωρήσετε. Οι ομάδες B, C και D μπορούν απλώς να παραμείνουν στην τρέχουσα έκδοσή τους προς το παρόν. Θα ανανεωθούν όταν συνειδητοποιήσουν την ιδιοφυΐα σας!
Σε ένα monorepository, η ευθύνη μετατοπίζεται από προεπιλογή. Η ομάδα Α αλλάζει το στοιχείο της και, αν δεν είναι προσεκτική, σπάει αμέσως τα Β, Γ και Δ. Αυτό οδηγεί στο να εμφανιστούν οι Β, Γ και Δ στην πόρτα του Α, αναρωτιούνται γιατί η ομάδα Α διέλυσε τη συναρμολόγηση. Αυτό διδάσκει στον Α ότι δεν μπορούν να παραλείψουν τη λίστα μου παραπάνω. Πρέπει να μιλήσουν για το τι πρόκειται να κάνουν. Μπορούν οι Β, Γ και Δ να κινηθούν; Τι θα γινόταν αν οι B και C μπορούν, αλλά το D ήταν στενά συνδεδεμένο με μια παρενέργεια της συμπεριφοράς του παλιού αλγορίθμου;
Τότε πρέπει να μιλήσουμε για το πώς θα βγούμε από αυτήν την κατάσταση:
- Υποστήριξη για πολλαπλά εσωτερικά API και θα επισημάνει τον παλιό αλγόριθμο ως καταργημένο έως ότου ο D σταματήσει να τον χρησιμοποιεί.
- Υποστήριξη για πολλαπλές εκδόσεις, μία με την παλιά διεπαφή, μία με τη νέα.
- Καθυστέρησε την απελευθέρωση των αλλαγών του A έως ότου οι B, C και D μπορούν να τις αποδεχτούν ταυτόχρονα.
Ας υποθέσουμε ότι έχουμε επιλέξει 1, αρκετά API. Σε αυτή την περίπτωση έχουμε δύο κομμάτια κώδικα. Παλιό και νέο. Αρκετά βολικό σε ορισμένες περιπτώσεις. Ελέγχουμε ξανά τον παλιό κώδικα, τον επισημαίνουμε ως καταργημένο και συμφωνούμε για ένα χρονοδιάγραμμα κατάργησης με την ομάδα D. Ουσιαστικά είναι πανομοιότυπο για τα πολυ και τα μονοφωνικά αποθετήρια.
Για να κυκλοφορήσουμε πολλές εκδόσεις, χρειαζόμαστε ένα υποκατάστημα. Τώρα έχουμε δύο στοιχεία - Α1 και Α2. Οι ομάδες Β και Γ χρησιμοποιούν την Α2 και η Δ χρησιμοποιεί την Α1. Χρειαζόμαστε κάθε στοιχείο να είναι έτοιμο για κυκλοφορία, επειδή ενδέχεται να απαιτούνται ενημερώσεις ασφαλείας και άλλες διορθώσεις σφαλμάτων πριν προχωρήσει το D. Σε ένα πολυαποθήκη, μπορούμε να το κρύψουμε αυτό σε ένα μακρόβιο κλαδί που έχει ωραία αίσθηση. Σε ένα monorepository, αναγκάζουμε τον κώδικα να δημιουργηθεί σε μια νέα ενότητα. Η ομάδα Δ θα πρέπει ακόμα να κάνει αλλαγές στο "παλιό" στοιχείο. Όλοι μπορούν να δουν το κόστος που πληρώνουμε εδώ - τώρα έχουμε διπλάσιο κωδικό και τυχόν διορθώσεις σφαλμάτων που ισχύουν για το A1 και το A2 πρέπει να ισχύουν και για τα δύο. Με την προσέγγιση διακλάδωσης σε ένα πολυαποθήκη, αυτό κρύβεται πίσω από το cherry-pick. Θεωρούμε ότι το κόστος είναι χαμηλότερο γιατί δεν υπάρχει διπλασιασμός. Από πρακτική άποψη, το κόστος είναι το ίδιο: θα δημιουργήσετε, θα απελευθερώσετε και θα διατηρήσετε δύο σε μεγάλο βαθμό πανομοιότυπες βάσεις κωδικών μέχρι να μπορέσετε να διαγράψετε μία από αυτές. Η διαφορά είναι ότι με μια μονοαποθήκη αυτός ο πόνος είναι άμεσος και ορατός. Αυτό είναι ακόμα χειρότερο, και αυτό είναι καλό.
Τελικά, φτάσαμε στο τρίτο σημείο. Καθυστέρηση κυκλοφορίας. Είναι πιθανό οι αλλαγές που έγιναν από τον Α να βελτιώσουν τη ζωή της Ομάδας Α. Σημαντικό, αλλά όχι επείγον. Μπορούμε απλά να καθυστερήσουμε; Σε ένα πολυαποθήκη, το πιέζουμε για να καρφιτσώσει το τεχνούργημα. Φυσικά το λέμε αυτό στην ομάδα D. Απλώς μείνετε στην παλιά έκδοση μέχρι να προλάβετε! Αυτό σε βάζει να παίξεις τον δειλό. Η Ομάδα Α συνεχίζει να εργάζεται στο στοιχείο της, αγνοώντας το γεγονός ότι η Ομάδα Δ χρησιμοποιεί μια ολοένα και πιο ξεπερασμένη έκδοση (αυτό είναι το πρόβλημα της Ομάδας Δ, είναι ανόητοι). Εν τω μεταξύ, η Ομάδα Δ μιλάει άσχημα για την απρόσεκτη στάση της Ομάδας Α ως προς τη σταθερότητα του κώδικα, αν μιλούν καθόλου γι 'αυτό. Οι μήνες περνούν. Τελικά, η Ομάδα Δ αποφασίζει να εξετάσει τη δυνατότητα ενημέρωσης, αλλά η Α έχει μόνο περισσότερες αλλαγές. Η ομάδα Α μετά βίας θυμάται πότε ή πώς έσπασε το D. Η αναβάθμιση είναι πιο επίπονη και θα διαρκέσει περισσότερο. Κάτι που το στέλνει πιο κάτω στη στοίβα προτεραιότητας. Μέχρι τη μέρα που θα έχουμε θέμα ασφαλείας στο Α που μας αναγκάζει να κάνουμε υποκατάστημα. Η ομάδα Α πρέπει να γυρίσει πίσω στο χρόνο, να βρει ένα σημείο όπου ο D ήταν σταθερός, να διορθώσει το πρόβλημα εκεί και να το ετοιμάσει για κυκλοφορία. Αυτή είναι η de facto επιλογή που κάνουν οι άνθρωποι, και είναι μακράν η χειρότερη. Φαίνεται να είναι καλό τόσο για την ομάδα Α όσο και για την ομάδα Δ, εφόσον μπορούμε να αγνοούμε ο ένας τον άλλον.
Σε ένα monorepository, το τρίτο δεν είναι πραγματικά μια επιλογή. Αναγκάζεσαι να αντιμετωπίσεις την κατάσταση με έναν από τους δύο τρόπους. Πρέπει να δείτε το κόστος της ύπαρξης δύο υποκαταστημάτων έκδοσης. Μάθετε να προστατεύεστε από ενημερώσεις που παραβιάζουν τη συμβατότητα προς τα πίσω. Αλλά το πιο σημαντικό: δεν μπορείς να αποφύγεις μια δύσκολη συζήτηση.
Σύμφωνα με την εμπειρία μου, όταν οι ομάδες γίνονται μεγάλες, δεν είναι πλέον δυνατό να έχουμε στο μυαλό μας ολόκληρο το σύστημα και αυτό είναι το πιο σημαντικό κομμάτι. Πρέπει να βελτιώσετε την ορατότητα της διαφωνίας στο σύστημα. Πρέπει να εργαστείτε ενεργά για να κάνετε τις ομάδες να κοιτάξουν μακριά από τα στοιχεία τους και να κοιτάξουν τη δουλειά άλλων ομάδων και καταναλωτών.
Ναι, μπορείτε να δημιουργήσετε εργαλεία που προσπαθούν να λύσουν το πρόβλημα του polyrepository. Αλλά η εμπειρία μου στη διδασκαλία συνεχούς παράδοσης και αυτοματισμού σε μεγάλες επιχειρήσεις μου λέει το εξής: η προεπιλεγμένη συμπεριφορά χωρίς τη χρήση πρόσθετων εργαλείων είναι η συμπεριφορά που περιμένετε να δείτε. Η προεπιλεγμένη συμπεριφορά ενός polyrepository είναι η απομόνωση, αυτό είναι το όλο θέμα. Η προεπιλεγμένη συμπεριφορά ενός μονοαποθετηρίου είναι κοινή ευθύνη και διαφάνεια, αυτό είναι το όλο θέμα. Και στις δύο περιπτώσεις, θα δημιουργήσω ένα εργαλείο που θα εξομαλύνει τις τραχιές άκρες. Ως αρχηγός, θα επιλέγω ένα μονοαποθετήριο κάθε φορά, επειδή τα εργαλεία πρέπει να ενισχύσουν την κουλτούρα που θέλω, και η κουλτούρα προέρχεται από μικροσκοπικές αποφάσεις και την καθημερινή δουλειά της ομάδας.
Μόνο εγγεγραμμένοι χρήστες μπορούν να συμμετάσχουν στην έρευνα. , Σας παρακαλούμε.
Ποιοι είναι οι μεγαλύτεροι φανατικοί; Υποστηρικτές:
-
Μονόρεπο
-
Σκωρία
-
Λανθασμένη δημοσκόπηση / και τα δύο
Ψήφισαν 33 χρήστες. 13 χρήστες απείχαν.
Πηγή: www.habr.com