Ας συζητήσουμε γιατί τα εργαλεία CI και το CI είναι τελείως διαφορετικά πράγματα.
Τι πόνο σκοπεύει να λύσει το CI, από πού προέκυψε η ιδέα, ποιες είναι οι τελευταίες επιβεβαιώσεις ότι λειτουργεί, πώς να καταλάβετε ότι έχετε μια πρακτική και όχι απλώς εγκατεστημένο το Jenkins.
Η ιδέα να κάνω μια αναφορά για τη Συνεχή Ένταξη εμφανίστηκε πριν από ένα χρόνο, όταν πήγαινα για συνεντεύξεις και έψαχνα για δουλειά. Μίλησα με 10-15 εταιρείες, μόνο μία από αυτές μπόρεσε να απαντήσει ξεκάθαρα τι είναι το CI και να εξηγήσει πώς κατάλαβαν ότι δεν το είχαν. Οι υπόλοιποι μιλούσαν ακατάληπτες βλακείες για τον Jenkins :) Λοιπόν, έχουμε Jenkins, κάνει build, CI! Κατά τη διάρκεια της έκθεσης, θα προσπαθήσω να εξηγήσω τι είναι στην πραγματικότητα η Συνεχής Ολοκλήρωση και γιατί το Jenkins και παρόμοια εργαλεία έχουν πολύ αδύναμη σχέση με αυτό.
Λοιπόν, τι συνήθως σας έρχεται στο μυαλό όταν ακούτε τη λέξη CI; Οι περισσότεροι άνθρωποι θα σκεφτούν τους Jenkins, Gitlab CI, Travis κ.λπ.
Ακόμα κι αν το γκουγκλάρουμε, θα μας δώσει αυτά τα εργαλεία.
Εάν είστε εξοικειωμένοι με το ερώτημα, τότε αμέσως μετά την καταχώριση των εργαλείων, θα σας πουν ότι το CI είναι όταν δημιουργείτε και εκτελείτε δοκιμές σε ένα αίτημα έλξης για μια δέσμευση.
Το Continuous Integration δεν έχει να κάνει με εργαλεία, ούτε με συγκροτήματα με δοκιμές σε κλάδο! Η συνεχής ολοκλήρωση είναι η πρακτική της πολύ συχνής ενσωμάτωσης νέου κώδικα και για τη χρήση του δεν είναι καθόλου απαραίτητο να περιφράξεις Jenkins, GitLab κ.λπ.
Πριν καταλάβουμε πώς μοιάζει με ένα ολοκληρωμένο CI, ας βουτήξουμε πρώτα στο πλαίσιο των ανθρώπων που το σκέφτηκαν και ας νιώσουμε τον πόνο που προσπαθούσαν να λύσουν.
Και έλυσαν τον πόνο της συνεργασίας σαν ομάδα!
Ας δούμε παραδείγματα των δυσκολιών που αντιμετωπίζουν οι προγραμματιστές όταν αναπτύσσονται σε ομάδες. Εδώ έχουμε ένα έργο, έναν κύριο κλάδο στο git και δύο προγραμματιστές.
Και πήγαν στη δουλειά όπως τους είχαν συνηθίσει από καιρό. Πήραμε μια εργασία στο μεγάλο σχήμα των πραγμάτων, δημιουργήσαμε έναν κλάδο χαρακτηριστικών και γράψαμε τον κώδικα.
Ο ένας ολοκλήρωσε τη δυνατότητα πιο γρήγορα και τη συγχώνευσε στην κύρια.
Το δεύτερο χρειάστηκε περισσότερο χρόνο, ενώθηκε αργότερα και κατέληξε σε σύγκρουση. Τώρα, αντί να γράφει τα χαρακτηριστικά που χρειάζεται η επιχείρηση, ο προγραμματιστής ξοδεύει τον χρόνο και την ενέργειά του για την επίλυση συγκρούσεων.
Όσο πιο δύσκολο είναι να συνδυάσετε το χαρακτηριστικό σας με ένα κοινό κύριο, τόσο περισσότερο χρόνο αφιερώνουμε σε αυτό. Και αυτό το έδειξα με ένα αρκετά απλό παράδειγμα. Αυτό είναι ένα παράδειγμα όπου υπάρχουν μόνο 2 προγραμματιστές. Φανταστείτε αν 10 ή 15 ή 100 άτομα σε μια εταιρεία γράφουν σε ένα αποθετήριο. Θα τρελαθείτε να επιλύσετε όλες αυτές τις συγκρούσεις.
Υπάρχει μια ελαφρώς διαφορετική περίπτωση. Έχουμε έναν κύριο και κάποιους προγραμματιστές που κάνουν κάτι.
Δημιούργησαν ένα κλαδάκι.
Ένας πέθανε, όλα ήταν καλά, πέρασε το έργο.
Ο δεύτερος προγραμματιστής, εν τω μεταξύ, παρέδωσε το έργο του. Ας πούμε ότι το έστειλε για έλεγχο. Πολλές εταιρείες έχουν μια πρακτική που ονομάζεται αναθεώρηση. Αφενός αυτή η πρακτική είναι καλή και χρήσιμη, αφετέρου μας επιβραδύνει με πολλούς τρόπους. Δεν θα υπεισέλθουμε σε αυτό, αλλά εδώ είναι ένα εξαιρετικό παράδειγμα του τι μπορεί να οδηγήσει μια κακή ιστορία κριτικής. Έχετε υποβάλει αίτημα έλξης για έλεγχο. Δεν υπάρχει τίποτα άλλο για τον προγραμματιστή να κάνει. Τι αρχίζει να κάνει; Αρχίζει να αναλαμβάνει άλλα καθήκοντα.
Κατά τη διάρκεια αυτής της περιόδου, ο δεύτερος προγραμματιστής έκανε κάτι άλλο.
Ο πρώτος ολοκλήρωσε την τρίτη εργασία.
Και μετά από αρκετό καιρό, η κριτική του δοκιμάστηκε και προσπαθεί να συμβιβαστεί. Λοιπόν τι συμβαίνει? Πιάνει έναν τεράστιο αριθμό συγκρούσεων. Γιατί; Διότι ενώ το αίτημα έλξης του κρεμόταν στην κριτική, πολλά πράγματα είχαν ήδη αλλάξει στον κώδικα.
Εκτός από την ιστορία με τις συγκρούσεις, υπάρχει μια ιστορία με τις επικοινωνίες. Ενώ το νήμα σας κρέμεται από την αναθεώρηση, ενώ περιμένει κάτι, ενώ εργάζεστε σε μια λειτουργία για μεγάλο χρονικό διάστημα, σταματάτε να παρακολουθείτε τι άλλο αλλάζει στη βάση κώδικα της υπηρεσίας σας. Ίσως αυτό που προσπαθείτε να λύσετε τώρα είχε ήδη λυθεί χθες και μπορείτε να χρησιμοποιήσετε κάποια μέθοδο και να την επαναχρησιμοποιήσετε. Αλλά αυτό δεν θα το δείτε επειδή εργάζεστε πάντα με ένα παρωχημένο υποκατάστημα. Και αυτός ο ξεπερασμένος κλάδος έχει πάντα ως αποτέλεσμα να πρέπει να επιλύσετε μια διένεξη συγχώνευσης.
Αποδεικνύεται ότι εάν εργαζόμαστε ως ομάδα, δηλαδή, δεν υπάρχει ένα άτομο στο αποθετήριο, αλλά 5-10 άτομα, τότε όσο περισσότερο δεν προσθέτουμε τον κωδικό μας στον κύριο, τόσο περισσότερο υποφέρουμε επειδή τελικά χρειαζόμαστε κάτι στη συνέχεια συγχωνεύστε το. Και όσες περισσότερες συγκρούσεις έχουμε, και με την παλαιότερη έκδοση δουλεύουμε, τόσο περισσότερα προβλήματα έχουμε.
Το να κάνετε κάτι μαζί είναι επώδυνο! Πάντα μπαίνουμε στον δρόμο του άλλου.
Αυτό το πρόβλημα παρατηρήθηκε πριν από περισσότερα από 20 χρόνια. Βρήκα την πρώτη αναφορά στην πρακτική της Συνεχούς Ενσωμάτωσης στον Ακραίο Προγραμματισμό.
Το Extreme Programming είναι το πρώτο ευέλικτο πλαίσιο. Η σελίδα εμφανίστηκε το 96. Και η ιδέα ήταν να χρησιμοποιήσουμε κάποιου είδους πρακτικές προγραμματισμού, προγραμματισμού και άλλα πράγματα, ώστε η ανάπτυξη να είναι όσο το δυνατόν πιο ευέλικτη, ώστε να μπορούμε να ανταποκρινόμαστε γρήγορα σε τυχόν αλλαγές ή απαιτήσεις των πελατών μας. Και άρχισαν να αντιμετωπίζουν αυτό πριν από 24 χρόνια, ότι αν κάνεις κάτι για πολύ καιρό και στο περιθώριο, τότε ξοδεύεις περισσότερο χρόνο σε αυτό γιατί έχεις συγκρούσεις.
Τώρα θα αναλύσουμε τη φράση «Συνεχής Ένταξη» ξεχωριστά. Αν το μεταφράσουμε απευθείας, έχουμε συνεχή ολοκλήρωση. Αλλά το πόσο συνεχής είναι δεν είναι πολύ ξεκάθαρο· είναι πολύ ασυνεχές. Αλλά το πόση ενσωμάτωση έχει δεν είναι επίσης πολύ προφανές.
Και γι' αυτό σας δίνω τώρα αποσπάσματα από τον Extreme Programming. Και θα αναλύσουμε και τις δύο λέξεις ξεχωριστά.
Ενσωμάτωση - Όπως είπα ήδη, προσπαθούμε να διασφαλίσουμε ότι κάθε μηχανικός θα λειτουργεί με την πιο πρόσφατη έκδοση του κώδικα, ώστε να προσπαθεί να προσθέτει τον κωδικό του όσο το δυνατόν συχνότερα σε έναν κοινό κλάδο, ώστε να είναι μικρά υποκαταστήματα. Γιατί αν είναι μεγάλα, τότε μπορούμε εύκολα να κολλήσουμε με συγκρούσεις συγχώνευσης για μια εβδομάδα. Αυτό ισχύει ιδιαίτερα εάν έχουμε έναν μακρύ κύκλο ανάπτυξης, όπως το waterfall, όπου ο προγραμματιστής έφυγε για ένα μήνα για να κόψει κάποιο τεράστιο χαρακτηριστικό. Και θα μείνει κολλημένος στο στάδιο της ένταξης για πολύ καιρό.
Ενσωμάτωση είναι όταν παίρνουμε τον κλάδο μας και τον ενσωματώνουμε με τον κύριο, τον συγχωνεύουμε. Υπάρχει μια απόλυτη επιλογή όταν είμαστε προγραμματιστής transbase, όπου προσπαθούμε να διασφαλίσουμε ότι θα γράφουμε αμέσως στον κύριο χωρίς επιπλέον διακλαδώσεις.
Γενικά, ενσωμάτωση σημαίνει να παίρνετε τον κωδικό σας και να τον σύρετε στο κύριο.
Τι εννοείται εδώ με τη λέξη «συνεχής», τι ονομάζεται συνέχεια; Η πρακτική συνεπάγεται ότι ο προγραμματιστής προσπαθεί να ενσωματώσει τον κώδικά του όσο το δυνατόν γρηγορότερα. Αυτός είναι ο στόχος του όταν εκτελεί οποιαδήποτε εργασία - να μεταφέρει τον κώδικά του σε κύριο όσο το δυνατόν γρηγορότερα. Σε έναν ιδανικό κόσμο, οι προγραμματιστές θα το έκαναν αυτό κάθε λίγες ώρες. Δηλαδή, παίρνεις ένα μικρό πρόβλημα και το συγχωνεύεις στο κύριο. Ολα είναι υπέροχα. Αυτό είναι που προσπαθείς. Και αυτό πρέπει να γίνεται συνεχώς. Μόλις κάνετε κάτι, το βάζετε αμέσως στον κύριο.
Και ο προγραμματιστής που φτιάχνει κάτι είναι υπεύθυνος για αυτό που έκανε για να λειτουργήσει και να μην σπάσει τίποτα. Αυτό είναι όπου συνήθως βγαίνει η δοκιμαστική ιστορία. Θέλουμε να εκτελέσουμε κάποιες δοκιμές στην δέσμευσή μας, στη συγχώνευσή μας, για να βεβαιωθούμε ότι λειτουργεί. Και εδώ μπορεί να σας βοηθήσει ο Jenkins.
Αλλά με τις ιστορίες: ας κάνουμε τις αλλαγές μικρές, ας αφήσουμε τις εργασίες να είναι μικρές, ας δημιουργήσουμε ένα πρόβλημα και ας προσπαθήσουμε αμέσως να το ενσωματώσουμε με κάποιο τρόπο στον κύριο - κανένας Jenkins δεν θα βοηθήσει εδώ. Επειδή το Jenkins θα σας βοηθήσει μόνο να εκτελέσετε δοκιμές.
Μπορείτε να κάνετε χωρίς αυτά. Αυτό δεν θα σας βλάψει καθόλου. Γιατί ο στόχος της εξάσκησης είναι να μετράμε όσο το δυνατόν συχνότερα, ώστε να μην χάνουμε τεράστιο χρόνο σε τυχόν συγκρούσεις στο μέλλον.
Ας φανταστούμε ότι για κάποιο λόγο βρισκόμαστε στο 2020 χωρίς Διαδίκτυο. Και δουλεύουμε τοπικά. Δεν έχουμε Τζένκινς. Είναι εντάξει. Μπορείτε ακόμα να προχωρήσετε και να δημιουργήσετε ένα τοπικό υποκατάστημα. Έγραψες κάποιο κώδικα σε αυτό. Ολοκληρώσαμε την εργασία σε 3-4 ώρες. Περάσαμε στο master, κάναμε ένα git pull και ενώσαμε το κλαδί μας εκεί. Ετοιμος. Εάν το κάνετε συχνά, συγχαρητήρια, έχετε Συνεχή Ένταξη!
Ποια στοιχεία υπάρχουν στον σύγχρονο κόσμο ότι αξίζει να ξοδέψετε ενέργεια; Γιατί γενικά είναι δύσκολο. Αν προσπαθήσετε να δουλέψετε έτσι, θα καταλάβετε ότι θα επηρεαστεί πλέον κάποιος προγραμματισμός, θα πρέπει να αφιερώσετε περισσότερο χρόνο σε εργασίες αποσύνθεσης. Γιατί αν κάνεις φίλε..., τότε δεν θα μπορέσεις να συνεννοηθείς γρήγορα και, ανάλογα, θα μπεις σε μπελάδες. Δεν θα έχετε πλέον πρακτική.
Και θα είναι ακριβό. Δεν θα είναι δυνατή η άμεση εργασία από αύριο χρησιμοποιώντας τη Συνεχή Ενοποίηση. Θα χρειαστεί πολύς χρόνος για να το συνηθίσετε, θα χρειαστεί πολύς χρόνος για να συνηθίσετε στην αποσύνθεση εργασιών, θα χρειαστεί πολύς χρόνος για να συνηθίσετε να επαναλαμβάνετε την πρακτική αναθεώρησης, εάν έχετε . Γιατί στόχος μας είναι να λιώσει σήμερα. Και αν κάνετε μια αναθεώρηση εντός τριών ημερών, τότε έχετε προβλήματα και η Συνεχής ενσωμάτωση δεν λειτουργεί για εσάς.
Έχουμε, όμως, κάποια σχετική απόδειξη αυτή τη στιγμή που να μας λέει ότι η επένδυση σε αυτή την πρακτική έχει νόημα;
Το πρώτο πράγμα που μου ήρθε στο μυαλό ήταν το State of DevOps. Αυτή είναι μια μελέτη που κάνουν τα παιδιά εδώ και 7 χρόνια. Τώρα το κάνουν ως ανεξάρτητος οργανισμός, αλλά υπό την Google.
Και η μελέτη του 2018 έδειξε μια συσχέτιση μεταξύ εταιρειών που προσπαθούν να χρησιμοποιήσουν βραχύβια υποκαταστήματα που ενσωματώνονται γρήγορα, ενσωματώνονται συχνά και έχουν καλύτερους δείκτες απόδοσης πληροφορικής.
Ποιοι είναι αυτοί οι δείκτες; Αυτές είναι 4 μετρήσεις που λαμβάνουν από όλες τις εταιρείες στα ερωτηματολόγιά τους: συχνότητα ανάπτυξης, χρόνος παράδοσης για αλλαγές, χρόνος επαναφοράς της υπηρεσίας, ποσοστό αποτυχίας αλλαγής.
Και, πρώτον, υπάρχει αυτή η συσχέτιση, γνωρίζουμε ότι οι εταιρείες που μετρούν συχνά έχουν πολύ καλύτερες μετρήσεις. Και έχουν μια διαίρεση εταιρειών σε διάφορες κατηγορίες: αυτές είναι αργές εταιρείες που παράγουν κάτι αργά, μεσαίας απόδοσης, υψηλής απόδοσης και ελίτ. Η ελίτ είναι το Netflix, το Amazon, που είναι εξαιρετικά γρήγορα, κάνουν τα πάντα γρήγορα, όμορφα και αποτελεσματικά.
Η δεύτερη ιστορία, που συνέβη μόλις πριν από ένα μήνα. Το Technology Radar έχει ένα υπέροχο άρθρο για το Gitflow. Το Gitflow διαφέρει από όλα τα άλλα στο ότι τα κλαδιά του είναι μακρόβια. Υπάρχουν κλάδοι απελευθέρωσης που ζουν για μεγάλο χρονικό διάστημα και διαθέτουν κλάδους που ζουν επίσης για μεγάλο χρονικό διάστημα. Αυτή η πρακτική στο Technology Radar έχει μεταφερθεί στο HOLD. Γιατί; Γιατί οι άνθρωποι αντιμετωπίζουν τον πόνο της ένταξης.
Εάν το κλαδί σας ζει για πολύ καιρό, κολλάει, σαπίζει και αρχίζουμε να ξοδεύουμε περισσότερο χρόνο προσπαθώντας να κάνουμε κάποιου είδους αλλαγή σε αυτό.
Και πρόσφατα ο συγγραφέας του Gitflow είπε ότι εάν ο στόχος σας είναι η Συνεχής Ενσωμάτωση, εάν ο στόχος σας είναι να θέλετε να κάνετε ρολά όσο πιο συχνά γίνεται, τότε το Gitflow είναι κακή ιδέα. Πρόσθεσε ξεχωριστά στο άρθρο ότι εάν έχετε ένα backend όπου μπορείτε να προσπαθήσετε για αυτό, τότε το Gitflow είναι περιττό για εσάς, επειδή το Gitflow θα σας επιβραδύνει, το Gitflow θα σας δημιουργήσει προβλήματα με την ενοποίηση.
Αυτό δεν σημαίνει ότι το Gitflow είναι κακό και δεν πρέπει να χρησιμοποιείται. Είναι για άλλες περιπτώσεις. Για παράδειγμα, όταν χρειάζεται να υποστηρίξετε πολλές εκδόσεις μιας υπηρεσίας ή μιας εφαρμογής, δηλαδή όπου χρειάζεστε υποστήριξη για μεγάλο χρονικό διάστημα.
Αλλά αν μιλήσετε με άτομα που υποστηρίζουν τέτοιες υπηρεσίες, θα ακούσετε πολύ πόνο για το γεγονός ότι αυτή η έκδοση ήταν 3.2, που ήταν πριν από 4 μήνες, αλλά αυτή η επιδιόρθωση δεν συμπεριλήφθηκε σε αυτήν και τώρα, προκειμένου να την φτιάξουμε, πρέπει να κάνετε ένα σωρό αλλαγές. Και τώρα έχουν κολλήσει ξανά, και τώρα ασχολούνται για μια εβδομάδα προσπαθώντας να εφαρμόσουν κάποια νέα δυνατότητα.
Όπως σημείωσε σωστά ο Alexander Kovalev στη συνομιλία, η συσχέτιση δεν είναι ίδια με την αιτιότητα. Αυτό είναι αλήθεια. Δηλαδή, δεν υπάρχει άμεση σύνδεση ότι αν έχετε Συνεχή Ενσωμάτωση, τότε όλες οι μετρήσεις θα είναι υπέροχες. Αλλά υπάρχει μια θετική συσχέτιση ότι αν το ένα είναι το ένα, τότε πιθανότατα είναι και το άλλο. Δεν είναι γεγονός, αλλά πιθανότατα. Είναι απλώς ένας συσχετισμός.
Φαίνεται ότι ήδη κάνουμε κάτι, φαίνεται ότι ήδη συγχωνευόμαστε, αλλά πώς μπορούμε να καταλάβουμε ότι έχουμε ακόμα Συνεχή Ένταξη, ότι συγχωνευόμαστε αρκετά συχνά;
Ο Jez Humble είναι ο συγγραφέας του Handbook, Accelerate, του ιστότοπου Continuous Delivery και του βιβλίου Continuous Delivery. Προσφέρει αυτό το τεστ:
- Ο κωδικός του μηχανικού φτάνει στον πλοίαρχο κάθε μέρα.
- На каждый коммит вы запускаете unit-тесты.
- Έπεσε η κατασκευή στο master, φτιάχτηκε σε 10 λεπτά περίπου.
Προτείνει να χρησιμοποιήσετε ένα τεστ όπως αυτό για να βεβαιωθείτε ότι έχετε αρκετή εξάσκηση.
Το τελευταίο το βρίσκω λίγο αμφιλεγόμενο. Δηλαδή, αν μπορείς να το φτιάξεις σε 10 λεπτά, τότε έχεις Continuous Integration, ακούγεται λίγο περίεργο, κατά τη γνώμη μου, αλλά είναι λογικό. Γιατί; Γιατί αν παγώνεις συχνά, σημαίνει ότι οι αλλαγές σου είναι μικρές. Εάν μια μικρή αλλαγή σημαίνει ότι η κύρια έκδοση σας έχει χαλάσει, τότε μπορείτε να βρείτε ένα παράδειγμα γρήγορα επειδή η αλλαγή είναι μικρή. Εδώ είχατε μια μικρή συγχώνευση, άλλαξαν 20-30 γραμμές. Και, κατά συνέπεια, μπορείτε γρήγορα να καταλάβετε ποιος ήταν ο λόγος, επειδή οι αλλαγές είναι μικροσκοπικές, έχετε μια πολύ μικρή περιοχή για να αναζητήσετε το πρόβλημα.
Και ακόμα κι αν το prod μας καταρρεύσει μετά την κυκλοφορία, τότε αν έχουμε την πρακτική της Συνεχούς Ενσωμάτωσης, είναι πολύ πιο εύκολο για εμάς να ενεργήσουμε, γιατί οι αλλαγές είναι μικροσκοπικές. Ναι, αυτό θα επηρεάσει τον προγραμματισμό. Αυτό θα πονέσει. Και, πιθανώς, το πιο δύσκολο πράγμα σε αυτή την πρακτική είναι να συνηθίσεις να αναλύεις εργασίες, δηλαδή πώς να το κάνεις έτσι ώστε να μπορείς να πάρεις κάτι και να το κάνεις σε λίγες ώρες και ταυτόχρονα να περάσεις μια αναθεώρηση, αν έχεις ένα. Η αναθεώρηση είναι ξεχωριστός πόνος.
Οι δοκιμές μονάδας είναι απλώς ένας βοηθός που σας βοηθά να καταλάβετε εάν η ενσωμάτωσή σας ήταν επιτυχής και εάν τίποτα δεν είχε χαλάσει. Κατά τη γνώμη μου, αυτό δεν είναι επίσης απολύτως υποχρεωτικό, γιατί δεν είναι αυτό το νόημα της πρακτικής.
Αυτή είναι μια σύντομη εισαγωγή στο Continuous Integration. Αυτό είναι το μόνο που υπάρχει σε αυτή την πρακτική. Είμαι έτοιμος για ερωτήσεις.
Θα συνοψίσω και πάλι εν συντομία:
- Το Continuous Integration δεν είναι Jenkins, δεν είναι Gitlab.
- Αυτό δεν είναι εργαλείο, είναι μια πρακτική να συγχωνεύουμε τον κώδικά μας στο κύριο όσο πιο συχνά γίνεται.
- Αυτό το κάνουμε για να αποφύγουμε τον τεράστιο πόνο που προκύπτει με τις συγχωνεύσεις στο μέλλον, δηλαδή νιώθουμε λίγο πόνο τώρα για να μην βιώσουμε περισσότερο στο μέλλον. Αυτό είναι το όλο θέμα.
- Στο πλάι υπάρχει επικοινωνία μέσω κώδικα, αλλά πολύ σπάνια το βλέπω αυτό, αλλά και για αυτό σχεδιάστηκε.
ερωτήσεις
Τι να κάνετε με εργασίες που δεν έχουν αποσυντεθεί;
Αναλύω. Ποιο είναι το πρόβλημα? Μπορείτε να δώσετε ένα παράδειγμα ότι υπάρχει μια εργασία και δεν αποσυντίθεται;
Υπάρχουν εργασίες που δεν μπορούν να αποσυντεθούν από τη λέξη «εντελώς», για παράδειγμα, εκείνες που απαιτούν πολύ βαθιά εξειδίκευση και οι οποίες μπορούν πραγματικά να επιλυθούν μέσα σε ένα μήνα για να επιτευχθεί κάποιο εύπεπτο αποτέλεσμα.
Αν κατάλαβα καλά, τότε υπάρχει κάποια μεγάλη και πολύπλοκη εργασία, το αποτέλεσμα της οποίας θα είναι ορατό μόνο σε ένα μήνα;
Ναι, σωστά. Ναι, θα είναι δυνατό να αξιολογηθεί το αποτέλεσμα όχι νωρίτερα από ένα μήνα.
Πρόστιμο. Γενικά αυτό δεν είναι πρόβλημα. Γιατί; Γιατί σε αυτή την περίπτωση, όταν μιλάμε για κλαδάκια, δεν μιλάμε για κλαδάκι με χαρακτηριστικό. Τα χαρακτηριστικά μπορεί να είναι μεγάλα και πολύπλοκα. Μπορούν να επηρεάσουν μεγάλο αριθμό εξαρτημάτων. Και ίσως δεν μπορούμε να τα κάνουμε εντελώς σε έναν κλάδο. Είναι εντάξει. Απλώς πρέπει να αναλύσουμε αυτήν την ιστορία. Εάν ένα χαρακτηριστικό δεν είναι εντελώς έτοιμο, αυτό δεν σημαίνει ότι ορισμένα κομμάτια του κώδικά του δεν μπορούν να συγχωνευθούν. Προσθέσατε, ας πούμε, τη μετεγκατάσταση και υπάρχουν μερικά στάδια μέσα στη δυνατότητα. Ας υποθέσουμε ότι έχετε ένα στάδιο - κάντε μια μετεγκατάσταση, προσθέστε μια νέα μέθοδο. Και μπορείτε ήδη να μετράτε αυτά τα πράγματα κάθε μέρα.
Πρόστιμο. Τι νόημα έχει τότε;
Τι νόημα έχει να σκοτώνεις μικροπράγματα κάθε μέρα;
Ναι.
Αν σπάσουν κάτι, το βλέπεις αμέσως. Έχετε ένα μικρό κομμάτι που έχει σπάσει κάτι, είναι πιο εύκολο για εσάς να το διορθώσετε. Το θέμα είναι ότι η συγχώνευση ενός μικρού κομματιού τώρα είναι πολύ πιο εύκολη από τη συγχώνευση κάτι μεγάλου σε λίγες εβδομάδες. Και το τρίτο σημείο είναι ότι άλλοι μηχανικοί θα εργαστούν με την τρέχουσα έκδοση του κώδικα. Θα δουν ότι ορισμένες μετεγκαταστάσεις έχουν προστεθεί εδώ και, στη συνέχεια, εμφανίστηκε κάποια μέθοδος που μπορεί επίσης να θέλουν να χρησιμοποιήσουν. Όλοι θα δουν τι συμβαίνει στον κώδικά σας. Για αυτά τα τρία πράγματα γίνεται η πρακτική.
Ευχαριστώ, το θέμα έκλεισε!
(Oleg Soroka) Μπορώ να προσθέσω; Τα είπες όλα σωστά, θέλω μόνο να προσθέσω μια φράση.
Έτσι
Με τη Συνεχή ενσωμάτωση, ο κώδικας συγχωνεύεται σε έναν κοινό κλάδο όχι όταν το χαρακτηριστικό είναι εντελώς έτοιμο, αλλά όταν το build σταματήσει να σπάει. Και μπορείτε με ασφάλεια να δεσμευτείτε να κυριαρχήσετε όσες φορές την ημέρα θέλετε. Η δεύτερη πτυχή είναι ότι εάν για κάποιο λόγο δεν μπορείτε να χωρίσετε τη μηνιαία εργασία σε εργασίες για τουλάχιστον τρεις ημέρες, είμαι σιωπηλός περίπου τρεις ώρες, τότε έχετε τεράστιο πρόβλημα. Και το γεγονός ότι δεν έχετε Συνεχή Ενσωμάτωση είναι το λιγότερο από αυτά τα προβλήματα. Αυτό σημαίνει ότι έχετε προβλήματα με την αρχιτεκτονική και μηδενικές πρακτικές μηχανικής. Γιατί ακόμα κι αν πρόκειται για έρευνα, τότε σε κάθε περίπτωση πρέπει να διατυπωθεί με τη μορφή υποθέσεων ή ενός κύκλου.
Μιλήσαμε για 4 μετρήσεις που ξεχωρίζουν τις επιτυχημένες εταιρείες από τις υστερούντες. Πρέπει ακόμα να ζήσουμε για να δούμε αυτές τις 4 μετρήσεις. Εάν ο μέσος όρος της εργασίας σας χρειάζεται έναν μήνα για να ολοκληρωθεί, τότε θα εστιάσω πρώτα σε αυτήν τη μέτρηση. Θα το χαμήλωσα πρώτα στις 3 μέρες. Και μετά από αυτό άρχισα να σκέφτομαι το Continuous.
Σε κατάλαβα καλά ότι πιστεύεις ότι γενικά δεν έχει νόημα να επενδύεις σε μηχανολογικές πρακτικές αν κάποια εργασία χρειάζεται ένα μήνα για να ολοκληρωθεί;
Έχετε Συνεχή Ενσωμάτωση. Και υπάρχει ένα τέτοιο θέμα που σε 10 λεπτά μπορείτε είτε να διορθώσετε μια λύση είτε να την επαναφέρετε. Φανταστείτε ότι το κυκλοφόρησε. Επιπλέον, έχετε ακόμη και συνεχή ανάπτυξη, το βάλατε σε ώθηση και μόνο τότε παρατηρήσατε ότι κάτι πήγε στραβά. Και πρέπει να το επαναφέρετε, αλλά έχετε ήδη μετεγκαταστήσει τη βάση δεδομένων σας. Έχετε ήδη το σχήμα βάσης δεδομένων της επόμενης έκδοσης, επιπλέον, είχατε και κάποιο είδος αντιγράφου ασφαλείας και τα δεδομένα γράφτηκαν επίσης εκεί.
Και τι εναλλακτική έχετε; Εάν επαναφέρετε τον κώδικα, τότε δεν μπορεί πλέον να λειτουργήσει με αυτήν την ενημερωμένη βάση δεδομένων.
Η βάση προχωρά μόνο μπροστά, ναι.
Οι άνθρωποι που έχουν κακές πρακτικές μηχανικής πιθανότατα δεν έχουν διαβάσει το χοντρό βιβλίο για…. Τι να κάνετε με το αντίγραφο ασφαλείας; Εάν κάνετε επαναφορά από ένα αντίγραφο ασφαλείας, σημαίνει ότι χάνετε τα δεδομένα που έχετε συγκεντρώσει εκείνη τη στιγμή. Για παράδειγμα, δουλέψαμε για τρεις ώρες με τη νέα έκδοση της βάσης δεδομένων, χρήστες που εγγράφηκαν εκεί. Απορρίπτετε το παλιό αντίγραφο ασφαλείας επειδή το σχήμα δεν λειτουργεί με τη νέα έκδοση, επομένως έχετε χάσει αυτούς τους χρήστες. Και είναι δυσαρεστημένοι, βρίζουν.
Για να κατακτήσετε το πλήρες φάσμα των πρακτικών που υποστηρίζουν τη Συνεχή Ενσωμάτωση και τη Συνεχή Παράδοση, δεν αρκεί απλώς να μάθετε πώς να γράφετε.... Πρώτον, μπορεί να υπάρχουν πολλά από αυτά, δεν θα είναι πρακτικό. Επιπλέον, υπάρχουν ένα σωρό άλλες πρακτικές όπως το Scientific. Υπάρχει μια τέτοια πρακτική, το GitHub την έκανε δημοφιλή κάποτε. Αυτό συμβαίνει όταν εκτελείτε ταυτόχρονα τον παλιό και τον νέο κώδικα. Αυτό συμβαίνει όταν δημιουργείτε μια ημιτελή λειτουργία, αλλά μπορεί να επιστρέψει κάποια τιμή: είτε ως συνάρτηση είτε ως Rest API. Εκτελείτε και τον νέο και τον παλιό κώδικα και συγκρίνετε τη διαφορά μεταξύ τους. Και αν υπάρχει διαφορά, τότε καταγράφετε αυτό το συμβάν. Με αυτόν τον τρόπο ξέρετε ότι έχετε μια νέα δυνατότητα έτοιμη να κυκλοφορήσει πάνω από την παλιά, εάν δεν είχατε ασυμφωνία μεταξύ των δύο για συγκεκριμένο χρονικό διάστημα.
Υπάρχουν εκατοντάδες τέτοιες πρακτικές. Θα πρότεινα να ξεκινήσετε με την ανάπτυξη transbase. Δεν είναι 100% στη Συνεχή Ενσωμάτωση, αλλά οι πρακτικές είναι ίδιες, η μία δεν μπορεί να ζήσει καλά χωρίς την άλλη.
Δώσατε την ανάπτυξη transbase ως παράδειγμα όπου μπορείτε να δείτε πρακτικές ή προτείνετε στους ανθρώπους να αρχίσουν να χρησιμοποιούν την debelopment transbase;
Ρίξτε μια ματιά, γιατί δεν θα μπορούν να το χρησιμοποιήσουν. Για να τα χρησιμοποιήσετε, πρέπει να διαβάσετε πολύ. Και όταν κάποιος ρωτά: «Τι να κάνει με ένα χαρακτηριστικό που διαρκεί ένα μήνα, σημαίνει ότι δεν έχει διαβάσει για την ανάπτυξη transbase». Δεν θα το συνιστούσα ακόμα. Θα συμβούλευα να εστιάσουμε αποκλειστικά στο θέμα του πώς να χωρίσουμε σωστά αρχιτεκτονικά τις μεγάλες εργασίες σε μικρότερες. Αυτή είναι η ουσία της αποσύνθεσης.
Η αποσύνθεση είναι ένα από τα εργαλεία του αρχιτέκτονα. Πρώτα κάνουμε ανάλυση, μετά αποσύνθεση, μετά σύνθεση και μετά ολοκλήρωση. Και κάπως έτσι μας πάνε όλα. Και πρέπει ακόμα να εξελιχθούμε στη Συνεχή Ολοκλήρωση μέσω της αποσύνθεσης. Προκύπτουν ερωτήματα στο πρώτο στάδιο, και ήδη μιλάμε για το τέταρτο στάδιο, δηλαδή όσο πιο συχνά κάνουμε ενσωμάτωση, τόσο το καλύτερο. Είναι ακόμη πολύ νωρίς για να το κάνετε αυτό· θα ήταν ωραίο να κόψετε πρώτα το μονόπετρό σας.
Πρέπει να σχεδιάσετε έναν αριθμό βελών και τετραγώνων σε κάποιο διάγραμμα. Δεν μπορείτε να πείτε ότι τώρα θα δείξω το αρχιτεκτονικό διάγραμμα μιας νέας εφαρμογής και θα δείξω ένα τετράγωνο, μέσα στο οποίο υπάρχει ένα πράσινο κουμπί για την εφαρμογή. Σε κάθε περίπτωση, θα υπάρχουν περισσότερα τετράγωνα και βέλη. Κάθε διάγραμμα που είδα είχε περισσότερα από ένα. Και η αποσύνθεση, ακόμη και σε επίπεδο γραφικής αναπαράστασης, ήδη γίνεται. Επομένως, τα τετράγωνα μπορούν να γίνουν ανεξάρτητα. Αν όχι, τότε έχω μεγάλες ερωτήσεις για τον αρχιτέκτονα.
Υπάρχει μια ερώτηση από τη συνομιλία: "Εάν μια αναθεώρηση είναι υποχρεωτική και διαρκεί πολύ, ίσως μια μέρα ή περισσότερο;"
Έχετε προβλήματα με την εξάσκηση. Η αναθεώρηση δεν πρέπει να διαρκεί μια μέρα ή περισσότερο. Αυτή είναι η ίδια ιστορία με την προηγούμενη ερώτηση, μόνο λίγο πιο ήπια. Εάν μια αναθεώρηση συνεχιστεί για μια μέρα, τότε πιθανότατα αυτή η αναθεώρηση θα έχει κάποια πολύ μεγάλη αλλαγή. Αυτό σημαίνει ότι πρέπει να γίνει μικρότερο. Στην ανάπτυξη transbase, την οποία συνέστησε ο Oleg, υπάρχει μια ιστορία που ονομάζεται συνεχής ανασκόπηση. Η ιδέα της είναι ότι κάνουμε ένα τόσο μικρό αίτημα έλξης επίτηδες, επειδή προσπαθούμε να συγχωνευόμαστε συνεχώς και λίγο τη φορά. Και έτσι το αίτημα έλξης αλλάζει μία αφαίρεση ή 10 γραμμές. Χάρη σε αυτήν την κριτική, μας παίρνει μερικά λεπτά.
Εάν η αναθεώρηση διαρκεί μία ημέρα ή περισσότερο, κάτι δεν πάει καλά. Πρώτον, μπορεί να έχετε κάποια προβλήματα με την αρχιτεκτονική. Ή αυτό είναι ένα μεγάλο κομμάτι κώδικα, 1 γραμμές, για παράδειγμα. Ή η αρχιτεκτονική σας είναι τόσο περίπλοκη που ένα άτομο δεν μπορεί να το καταλάβει. Αυτό είναι ένα ελαφρώς λοξό πρόβλημα, αλλά θα πρέπει επίσης να λυθεί. Ίσως δεν χρειάζεται καθόλου αναθεώρηση. Πρέπει να το σκεφτούμε και αυτό. Η αναθεώρηση είναι αυτό που σε επιβραδύνει. Έχει τα πλεονεκτήματά του γενικά, αλλά πρέπει να καταλάβεις γιατί το κάνεις. Είναι αυτός ένας τρόπος για να μεταφέρετε γρήγορα πληροφορίες, είναι αυτός ένας τρόπος για να ορίσετε κάποια πρότυπα εσωτερικά ή κάτι τέτοιο; Γιατί το χρειάζεστε αυτό; Γιατί ο έλεγχος πρέπει να γίνει είτε πολύ γρήγορα είτε να ακυρωθεί εντελώς. Είναι σαν ανάπτυξη transbase - η ιστορία είναι πολύ όμορφη, αλλά μόνο για ώριμα παιδιά.
Όσον αφορά τις 4 μετρήσεις, θα συνιστούσα να τις αφαιρέσετε για να καταλάβετε σε τι οδηγεί αυτό. Δείτε τους αριθμούς, δείτε την εικόνα, πόσο άσχημα είναι όλα.
(Ντιμίτρι) Είμαι έτοιμος να ξεκινήσω μια συζήτηση για αυτό μαζί σας. Οι αριθμοί και οι μετρήσεις είναι όλα υπέροχα, οι πρακτικές είναι εξαιρετικές. Πρέπει όμως να καταλάβετε αν το χρειάζεται η επιχείρηση. Υπάρχουν επιχειρήσεις που δεν χρειάζονται τέτοιου είδους ταχύτητα αλλαγής. Γνωρίζω εταιρείες όπου δεν μπορούν να γίνουν αλλαγές κάθε 15 λεπτά. Και όχι επειδή είναι τόσο κακοί. Αυτός είναι ένας τέτοιος κύκλος ζωής. Και για να κάνετε τα κλαδιά να διαθέτουν, τη δυνατότητα εναλλαγής, χρειάζεστε βαθιά γνώση.
Είναι περίπλοκο. Εάν θέλετε να διαβάσετε την ιστορία σχετικά με τη δυνατότητα εναλλαγής με περισσότερες λεπτομέρειες, το συνιστώ ανεπιφύλακτα . Και υπάρχει ένα υπέροχο άρθρο του Martin Fowler σχετικά με τις δυνατότητες εναλλαγής: ποιοι τύποι υπάρχουν, κύκλοι ζωής κ.λπ. Η δυνατότητα εναλλαγής είναι περίπλοκη.
Και ακόμα δεν έχετε απαντήσει στην ερώτηση: «Χρειάζεται ή όχι ο Τζένκινς;»
Ο Jenkins δεν χρειάζεται σε καμία περίπτωση πραγματικά. Σοβαρά όμως, τα εργαλεία: Jenkins, Gitlab θα σας φέρουν ευκολία. Θα δείτε ότι το συγκρότημα είναι συναρμολογημένο ή όχι. Μπορούν να σας βοηθήσουν, αλλά δεν θα σας κάνουν πρακτική. Μπορούν να σας δώσουν μόνο έναν κύκλο - Ok, όχι Ok. Και μετά, αν γράφεις και τεστ, γιατί αν δεν υπάρχουν τεστ, τότε είναι σχεδόν άσκοπο. Επομένως, είναι απαραίτητο γιατί είναι πιο βολικό, αλλά γενικά μπορείτε να ζήσετε χωρίς αυτό, δεν θα χάσετε πολλά.
Δηλαδή, αν έχεις πρακτικές, αυτό σημαίνει ότι δεν το χρειάζεσαι;
Σωστά. Συνιστώ το τεστ Jez Humble. Εκεί έχω μια αμφίθυμη στάση απέναντι στο τελευταίο σημείο. Αλλά γενικά, αν έχετε τρία πράγματα, συγχωνεύεστε συνεχώς, εκτελείτε δοκιμές σε δεσμεύσεις στο master, διορθώνετε γρήγορα το build στο master, τότε ίσως δεν χρειάζεστε τίποτα άλλο.
Ενώ περιμένουμε ερωτήσεις από τους συμμετέχοντες, έχω μια ερώτηση. Μιλούσαμε μόνο για τον κωδικό προϊόντος. Το έχετε χρησιμοποιήσει για κωδικό υποδομής; Είναι ο ίδιος κώδικας, έχει τις ίδιες αρχές και τον ίδιο κύκλο ζωής ή υπάρχουν διαφορετικοί κύκλοι ζωής και αρχές; Συνήθως, όταν όλοι μιλούν για Συνεχή Ένταξη και Ανάπτυξη, όλοι ξεχνούν ότι υπάρχει και κώδικας υποδομής. Και τον τελευταίο καιρό είναι όλο και περισσότερο. Και όλοι αυτοί οι κανόνες πρέπει να τεθούν εκεί;
Ούτε ότι θα έπρεπε, θα ήταν υπέροχο γιατί θα έκανε τη ζωή πιο εύκολη με τον ίδιο τρόπο. Από τη στιγμή που δουλεύουμε με κώδικα, όχι με σενάρια bash, αλλά έχουμε κανονικό κώδικα.
Stop, stop, ένα σενάριο bash είναι επίσης κώδικας. Μην αγγίζεις την παλιά μου αγάπη.
Εντάξει, δεν θα πατήσω τις αναμνήσεις σου. Έχω μια προσωπική αντιπάθεια για το bash. Σπάει άσχημο και τρομακτικό όλη την ώρα. Και συχνά σπάει απρόβλεπτα, γι' αυτό δεν μου αρέσει. Αλλά εντάξει, ας πούμε ότι έχετε κωδικό bash. Ίσως πραγματικά δεν καταλαβαίνω και υπάρχουν κανονικά πλαίσια δοκιμών εκεί έξω. Απλώς δεν είμαι ενήμερος. Και έχουμε τα ίδια οφέλη.
Μόλις εργαζόμαστε με την υποδομή ως κώδικα, αντιμετωπίζουμε όλα τα ίδια προβλήματα με τους προγραμματιστές. Πριν από λίγους μήνες, αντιμετώπισα μια κατάσταση όπου ένας συνάδελφος μου έστειλε αίτημα έλξης για 1 γραμμές στο bash. Και κάνεις παρέα στο review για 000 ώρες. Τα ίδια προβλήματα προκύπτουν. Είναι ακόμα κωδικός. Και είναι ακόμα μια συνεργασία. Κολλάμε με το αίτημα έλξης και κολλάμε με το γεγονός ότι επιλύουμε τις ίδιες διενέξεις συγχώνευσης στο ίδιο bash, για παράδειγμα.
Τώρα κοιτάζω πολύ ενεργά όλο αυτό το θέμα στον πιο όμορφο προγραμματισμό υπερύθρων. Έφερα τώρα το Pulumi στην υποδομή. Αυτός είναι ο προγραμματισμός στην πιο καθαρή του μορφή. Εκεί είναι ακόμα πιο ωραίο, γιατί έχω όλες τις δυνατότητες μιας γλώσσας προγραμματισμού, δηλαδή έκανα μια όμορφη εναλλαγή από το μπλε με τα ίδια if και όλα είναι καλά. Δηλαδή η αλλαγή μου είναι ήδη στο master. Όλοι μπορούν ήδη να τον δουν. Άλλοι μηχανικοί το γνωρίζουν. Εκεί έχει ήδη επηρεάσει κάτι. Ωστόσο, δεν ενεργοποιήθηκε για όλες τις υποδομές. Ενεργοποιήθηκε για τους πάγκους δοκιμών μου, για παράδειγμα. Επομένως, για να απαντήσω ξανά στην ερώτησή σας, είναι απαραίτητο. Μας κάνει τη ζωή πιο εύκολη για εμάς, ως μηχανικούς που εργαζόμαστε με κώδικα, με τον ίδιο τρόπο.
Αν κάποιος άλλος έχει ερωτήσεις;
Εχω μία ερώτηση. Θέλω να συνεχίσω τη συζήτηση με τον Όλεγκ. Γενικά πιστεύω ότι έχεις δίκιο, ότι αν μια εργασία θέλει ένα μήνα για να ολοκληρωθεί, τότε έχεις πρόβλημα με την αρχιτεκτονική, έχεις πρόβλημα ανάλυσης, αποσύνθεσης, σχεδιασμού κλπ. Αλλά έχω την αίσθηση ότι αν ξεκινήσεις προσπαθώντας να ζήσετε σύμφωνα με τη Συνεχή Ολοκλήρωση, τότε θα αρχίσετε να διορθώνετε τον πόνο με προγραμματισμό, γιατί δεν θα ξεφύγετε από αυτό πουθενά αλλού.
(Oleg) Ναι, έτσι είναι. Αυτή η πρακτική είναι συγκρίσιμη σε προσπάθεια με οποιαδήποτε άλλη σοβαρή πρακτική που αλλάζει την κουλτούρα. Το πιο δύσκολο πράγμα που πρέπει να ξεπεραστεί είναι οι συνήθειες, ειδικά οι κακές συνήθειες. Και αν για να εφαρμόσετε αυτή την πρακτική απαιτείται μια σοβαρή αλλαγή στις συνήθειες των γύρω σας: προγραμματιστές, διοίκηση, διευθυντής παραγωγής, τότε σας περιμένουν εκπλήξεις.
Τι εκπλήξεις μπορεί να υπάρχουν; Ας πούμε ότι αποφασίσατε ότι θα ενσωματώνεστε πιο συχνά. Και έχετε κάποια άλλα πράγματα που συνδέονται με την ενοποίηση, για παράδειγμα, τεχνουργήματα. Και στην εταιρεία σας, για παράδειγμα, υπάρχει μια πολιτική σύμφωνα με την οποία κάθε τεχνούργημα πρέπει να λαμβάνεται υπόψη με κάποιο τρόπο σε κάποιο είδος συστήματος αποθήκευσης αντικειμένων. Και χρειάζεται λίγος χρόνος. Ένα άτομο πρέπει να ελέγξει το πλαίσιο ότι, ως υπεύθυνος κυκλοφορίας, έχει δοκιμάσει αυτό το τεχνούργημα για να διασφαλίσει ότι είναι έτοιμο για κυκλοφορία στην παραγωγή. Εάν χρειάζονται 5-10-15 λεπτά, αλλά κάνετε τη διάταξη μία φορά την εβδομάδα, τότε το να ξοδεύετε μισή ώρα μία φορά την εβδομάδα είναι ένας μικρός φόρος.
Εάν κάνετε Συνεχή Ενσωμάτωση 10 φορές την ημέρα, τότε οι 10 φορές πρέπει να πολλαπλασιαστούν επί 30 λεπτά. Και αυτό υπερβαίνει τον χρόνο εργασίας αυτού του διαχειριστή έκδοσης. Απλώς κουράζεται να το κάνει. Υπάρχουν σταθερά κόστη για ορισμένες πρακτικές. Αυτό είναι όλο.
Και πρέπει είτε να ακυρώσετε αυτόν τον κανόνα για να μην κάνετε πλέον τέτοια σκουπίδια, δηλαδή να μην εκχωρείτε χειροκίνητα ένα πτυχίο για να αντιστοιχεί σε κάτι. Βασίζεστε εξ ολοκλήρου σε κάποιο αυτοματοποιημένο σύνολο δοκιμών ετοιμότητας.
Και αν χρειάζεστε αποδείξεις από κάποιον, ώστε το αφεντικό να το υπογράψει και να μην μπείτε στην παραγωγή χωρίς ο Βάσια να πει ότι το επιτρέπει κ.λπ. - όλη αυτή η ανοησία παρεμποδίζει τον ασκούμενο. Γιατί αν υπάρχουν κάποιες δραστηριότητες που σχετίζονται με τον φόρο, τότε όλα αυξάνονται 100 φορές. Ως εκ τούτου, η αλλαγή συχνά δεν θα χαιρετιστεί με χαρά από όλους. Γιατί οι συνήθειες των ανθρώπων δύσκολα αλλάζουν.
Όταν ένα άτομο κάνει τη συνηθισμένη του δουλειά, το κάνει σχεδόν χωρίς να το σκεφτεί. Το γνωστικό της φορτίο είναι μηδενικό. Απλώς παίζει με αυτό, έχει ήδη μια λίστα ελέγχου στο κεφάλι του, το έχει κάνει χίλιες φορές. Και μόλις έρθεις και του πεις: «Ας ακυρώσουμε αυτήν την πρακτική και ας εισάγουμε μια νέα από τη Δευτέρα», γι' αυτόν γίνεται ένα ισχυρό γνωστικό φορτίο. Και έρχεται σε όλους ταυτόχρονα.
Επομένως, το πιο απλό πράγμα, αν και δεν μπορούν όλοι να αντέξουν οικονομικά αυτήν την πολυτέλεια, αλλά αυτό κάνω πάντα, αυτό είναι το εξής. Εάν ξεκινήσει ένα νέο έργο, τότε συνήθως όλες οι μη δοκιμασμένες πρακτικές στριμώχνονται αμέσως σε αυτό το έργο. Ενώ το έργο είναι νέο, δεν διακινδυνεύουμε τίποτα. Δεν υπάρχει ακόμα Prod, δεν υπάρχει τίποτα να καταστραφεί. Ως εκ τούτου, μπορεί να χρησιμοποιηθεί ως εκπαίδευση. Αυτή η προσέγγιση λειτουργεί. Αλλά δεν έχουν όλες οι εταιρείες την ευκαιρία να ξεκινούν συχνά τέτοια έργα. Αν και αυτό είναι επίσης λίγο περίεργο, γιατί τώρα υπάρχει ένας πλήρης ψηφιακός μετασχηματισμός, όλοι πρέπει να ξεκινήσουν πειράματα για να συμβαδίσουν με τους ανταγωνιστές.
Εδώ καταλήγετε στο συμπέρασμα ότι πρέπει πρώτα να κατανοήσετε τι πρέπει να κάνετε. Ο κόσμος δεν είναι ιδανικός, ούτε και το prod είναι ιδανικό.
Ναι, αυτά τα πράγματα είναι αλληλένδετα.
Οι επιχειρήσεις επίσης δεν καταλαβαίνουν πάντα ότι πρέπει να ακολουθήσουν αυτόν τον τρόπο.
Υπάρχει μια κατάσταση στην οποία δεν είναι δυνατή καμία αλλαγή. Αυτή είναι μια κατάσταση όπου υπάρχει μεγαλύτερη πίεση στην ομάδα. Η ομάδα είναι ήδη αρκετά καμένη. Δεν έχει ελεύθερο χρόνο για πειράματα. Δουλεύουν σε χαρακτηριστικά από το πρωί έως το βράδυ. Και η διαχείριση έχει όλο και λιγότερα χαρακτηριστικά. Όλο και περισσότερα απαιτούνται. Σε μια τέτοια κατάσταση, καμία αλλαγή δεν είναι δυνατή. Η ομάδα μπορεί να πει μόνο ότι αύριο θα κάνουμε το ίδιο με χθες, απλά πρέπει να κάνουμε λίγο περισσότερα χαρακτηριστικά. Υπό αυτή την έννοια, δεν είναι δυνατή καμία μετάβαση σε οποιεσδήποτε πρακτικές. Αυτή είναι μια κλασική κατάσταση όταν δεν υπάρχει χρόνος για να ακονίσετε το τσεκούρι, τα δέντρα πρέπει να κοπούν, οπότε το κόβουν με ένα θαμπό τσεκούρι. Δεν υπάρχουν απλές συμβουλές εδώ.
(Ντιμίτρι) Θα διαβάσω μια διευκρίνιση από τη συνομιλία: «Αλλά χρειαζόμαστε πολλή κάλυψη δοκιμών σε διαφορετικά επίπεδα. Πόσος χρόνος διατίθεται για τις δοκιμές; Είναι λίγο ακριβό και παίρνει πολύ χρόνο».
(Oleg) Αυτή είναι μια κλασική παρανόηση. Θα πρέπει να υπάρχουν αρκετά τεστ για να είστε σίγουροι. Η συνεχής ολοκλήρωση δεν είναι ένα πράγμα όπου πρώτα γίνεται το 100% των δοκιμών και μόνο μετά αρχίζεις να εφαρμόζεις αυτήν την πρακτική. Η συνεχής ολοκλήρωση μειώνει το γνωστικό σας φορτίο λόγω του γεγονότος ότι κάθε μια από τις αλλαγές που βλέπετε με τα μάτια σας είναι τόσο εμφανής που καταλαβαίνετε αν θα σπάσει κάτι ή όχι, ακόμα και χωρίς τεστ. Μπορείτε να το δοκιμάσετε γρήγορα στο μυαλό σας γιατί οι αλλαγές είναι μικρές. Ακόμα κι αν έχετε μόνο μη αυτόματους ελεγκτές, είναι πιο εύκολο και για αυτούς. Πήγες έξω και είπες: "Κοίτα, χάλασε κάτι;" Έλεγξαν και είπαν: «Όχι, τίποτα δεν έχει χαλάσει». Γιατί ο ελεγκτής ξέρει πού να ψάξει. Έχετε ένα commit που σχετίζεται με ένα κομμάτι κώδικα. Και αυτό το εκμεταλλεύεται συγκεκριμένη συμπεριφορά.
Εδώ, φυσικά, στολίστηκες.
(Dmitry) Δεν συμφωνώ εδώ. Υπάρχει μια πρακτική - βασισμένη σε δοκιμές ανάπτυξη, η οποία θα σας σώσει από αυτό.
(Oleg) Λοιπόν, δεν έχω φτάσει ακόμα σε αυτό το σημείο. Η πρώτη ψευδαίσθηση είναι ότι πρέπει να γράψετε το 100% των δοκιμών ή δεν χρειάζεται να κάνετε καθόλου Συνεχή Ενσωμάτωση. Δεν είναι αλήθεια. Πρόκειται για δύο παράλληλες πρακτικές. Και δεν εξαρτώνται άμεσα. Η κάλυψη της δοκιμής σας θα πρέπει να είναι η βέλτιστη. Βέλτιστο - αυτό σημαίνει ότι εσείς οι ίδιοι είστε βέβαιοι ότι η ποιότητα του πλοιάρχου στην οποία παρέμεινε ο κύριος σας μετά τη δέσμευση σάς επιτρέπει να πατήσετε με σιγουριά το κουμπί "Ανάπτυξη" ένα μεθυσμένο βράδυ Παρασκευής. Πώς το πετυχαίνεις αυτό; Μέσω αναθεώρησης, μέσω κάλυψης, μέσω καλής παρακολούθησης.
Η καλή παρακολούθηση δεν διακρίνεται από τις δοκιμές. Εάν εκτελέσετε δοκιμές μία φορά στο pre-prod, τότε ελέγχουν όλα τα σενάρια χρήστη σας μία φορά και αυτό είναι. Και αν τα εκτελέσετε σε έναν ατελείωτο βρόχο, τότε αυτό είναι το αναπτυγμένο σύστημα παρακολούθησης σας, το οποίο ελέγχει ατελείωτα τα πάντα - είτε συνετρίβη είτε όχι. Σε αυτή την περίπτωση, η μόνη διαφορά είναι αν γίνεται μία ή δύο φορές. Ένα πολύ καλό σύνολο δοκιμών... τρέχει ατελείωτα, αυτό είναι η παρακολούθηση. Και η σωστή παρακολούθηση πρέπει να είναι έτσι.
Και επομένως, πώς ακριβώς θα πετύχετε αυτή την κατάσταση όταν ετοιμαστείτε την Παρασκευή το απόγευμα και πάτε σπίτι είναι ένα άλλο ερώτημα. Ίσως είσαι απλά ένα τολμηρό σκουπίδι.
Ας επιστρέψουμε λίγο στο Continuous Integration. Τρέξαμε σε μια ελαφρώς διαφορετική περίπλοκη πρακτική.
Και η δεύτερη ψευδαίσθηση είναι ότι ο MVP, λένε, πρέπει να γίνει γρήγορα, οπότε δεν χρειάζονται καθόλου τεστ εκεί. Όχι σίγουρα με αυτόν τον τρόπο. Το γεγονός είναι ότι όταν γράφετε μια ιστορία χρήστη σε ένα MVP, μπορείτε είτε να την αναπτύξετε στην μπάλα, δηλαδή ακούσατε ότι υπήρχε κάποιο είδος ιστορίας χρήστη και αμέσως τρέξατε να την κωδικοποιήσετε ή μπορείτε να εργαστείτε χρησιμοποιώντας το TDD. Και σύμφωνα με το TDD, όπως δείχνει η πρακτική, δεν χρειάζεται περισσότερος χρόνος, δηλαδή οι δοκιμές είναι μια παρενέργεια. Η πρακτική του TDD δεν αφορά τη δοκιμή. Παρά αυτό που ονομάζεται Test Driven Development, δεν πρόκειται καθόλου για δοκιμές. Αυτή είναι επίσης μάλλον μια αρχιτεκτονική προσέγγιση. Αυτή είναι μια προσέγγιση για να γράψετε ακριβώς αυτό που χρειάζεται και να μην γράψετε αυτό που δεν χρειάζεται. Αυτή είναι μια πρακτική εστίασης στην επόμενη επανάληψη της σκέψης σας όσον αφορά τη δημιουργία μιας αρχιτεκτονικής εφαρμογής.
Επομένως, δεν είναι τόσο εύκολο να απαλλαγούμε από αυτές τις ψευδαισθήσεις. MVP και τεστ δεν έρχονται σε αντίθεση μεταξύ τους. Ακόμη, μάλλον, αντίθετα, αν κάνεις MVP χρησιμοποιώντας εξάσκηση TDD, τότε θα το κάνεις καλύτερα και πιο γρήγορα από ό,τι αν το κάνεις χωρίς καθόλου εξάσκηση, αλλά με μπάλα.
Αυτή είναι μια πολύ μη προφανής και πολύπλοκη ιδέα. Όταν ακούς ότι τώρα θα γράψω περισσότερα τεστ και ταυτόχρονα θα κάνω κάτι πιο γρήγορα, ακούγεται απολύτως ανεπαρκές.
(Dmitry) Πολλοί άνθρωποι εδώ, όταν καλούν MVP, οι άνθρωποι είναι πολύ τεμπέληδες για να γράψουν κάτι κανονικό. Και αυτά είναι ακόμα διαφορετικά πράγματα. Δεν χρειάζεται να μετατρέψετε το MVP σε κάτι κακό που δεν λειτουργεί.
Ναι, ναι, έχεις δίκιο.
Και τότε ξαφνικά MVP στο prod.
Για πάντα.
Και το TDD ακούγεται πολύ ασυνήθιστο όταν ακούτε ότι γράφετε τεστ και φαίνεται να κάνετε περισσότερη δουλειά. Ακούγεται πολύ περίεργο, αλλά στην πραγματικότητα αποδεικνύεται πιο γρήγορο και πιο όμορφο με αυτόν τον τρόπο. Όταν γράφετε ένα τεστ, σκέφτεστε ήδη πολύ στο μυαλό σας για το ποιος κωδικός θα ονομάζεται και πώς, καθώς και τι συμπεριφορά περιμένουμε από αυτόν. Δεν λες απλώς ότι έγραψα κάποια λειτουργία και κάτι κάνει. Στην αρχή νόμιζες ότι είχε τέτοιες και τέτοιες συνθήκες, θα την καλούσαν έτσι και έτσι. Το καλύπτετε αυτό με δοκιμές και από αυτό καταλαβαίνετε πώς θα φαίνονται οι διεπαφές σας μέσα στον κώδικά σας. Αυτό έχει τεράστιο αντίκτυπο στην αρχιτεκτονική. Ο κώδικάς σας γίνεται αυτόματα πιο αρθρωτός, γιατί πρώτα προσπαθείτε να καταλάβετε πώς θα τον δοκιμάσετε και μόνο μετά τον γράφετε.
Αυτό που μου συνέβη με το TDD ήταν ότι κάποια στιγμή προσέλαβα έναν μέντορα της Ruby όταν ήμουν ακόμα προγραμματιστής της Ruby. Και λέει: «Ας το κάνουμε σύμφωνα με το TDD». Σκέφτηκα: «Διάολε, τώρα πρέπει να γράψω κάτι παραπάνω». Και συμφωνήσαμε ότι μέσα σε δύο εβδομάδες θα έγραφα όλο τον κώδικα εργασίας στην Python χρησιμοποιώντας το TDD. Μετά από δύο εβδομάδες, συνειδητοποίησα ότι δεν ήθελα να επιστρέψω. Μετά από δύο εβδομάδες προσπαθώντας να το εφαρμόσετε παντού, συνειδητοποιείτε πόσο πιο εύκολο είναι για εσάς να σκεφτείτε. Αλλά αυτό δεν είναι προφανές, γι' αυτό συνιστώ σε όλους ότι αν έχετε την αίσθηση ότι το TDD είναι δύσκολο, χρονοβόρο και περιττό, δοκιμάστε να το διατηρήσετε για μόλις δύο εβδομάδες. Δύο ήταν αρκετά για μένα.
(Dmitry) Μπορούμε να επεκτείνουμε αυτήν την ιδέα από την άποψη της λειτουργίας της υποδομής. Πριν ξεκινήσουμε οτιδήποτε καινούργιο, κάνουμε παρακολούθηση και μετά εκκινούμε. Σε αυτή την περίπτωση, η παρακολούθηση γίνεται κανονική δοκιμή για εμάς. Και υπάρχει ανάπτυξη μέσω της παρακολούθησης. Αλλά σχεδόν όλοι λένε ότι είναι μακρύ, είμαι τεμπέλης, έκανα ένα προσωρινό σχέδιο. Εάν έχουμε κάνει κανονική παρακολούθηση, κατανοούμε την κατάσταση του συστήματος CI. Και το σύστημα CI έχει πολλή παρακολούθηση. Καταλαβαίνουμε την κατάσταση του συστήματος, καταλαβαίνουμε τι υπάρχει μέσα του. Και κατά την ανάπτυξη, απλώς φτιάχνουμε το σύστημα έτσι ώστε να φτάσει στην επιθυμητή κατάσταση.
Αυτές οι πρακτικές είναι γνωστές εδώ και πολύ καιρό. Το συζητήσαμε πριν από περίπου 4 χρόνια. Αλλά σε 4 χρόνια δεν έχει αλλάξει σχεδόν τίποτα.
Αλλά σε αυτό το σημείωμα, προτείνω να τερματιστεί η επίσημη συζήτηση.
Βίντεο (εισάγεται ως στοιχείο πολυμέσων, αλλά για κάποιο λόγο δεν λειτουργεί):
Πηγή: www.habr.com