Η αναφορά θα μιλήσει για ορισμένες πρακτικές DevOps, αλλά από τη σκοπιά ενός προγραμματιστή. Συνήθως, όλοι οι μηχανικοί που συμμετέχουν στο DevOps έχουν ήδη αρκετά χρόνια διοικητικής εμπειρίας. Αλλά αυτό δεν σημαίνει ότι δεν υπάρχει θέση για τον προγραμματιστή εδώ. Τις περισσότερες φορές, οι προγραμματιστές είναι απασχολημένοι με την επιδιόρθωση "του επόμενου επειγόντως κρίσιμου σφάλματος της ημέρας" και δεν έχουν χρόνο να ρίξουν καν μια γρήγορη ματιά στο πεδίο DevOps. Κατά την κατανόηση του συγγραφέα, το DevOps είναι, πρώτον, η κοινή λογική. Δεύτερον, είναι μια ευκαιρία να είμαστε πιο αποτελεσματικοί. Εάν είστε προγραμματιστής, έχετε κοινή λογική και θέλετε να είστε πιο αποτελεσματικοί ως ομαδικός παίκτης, αυτή η αναφορά είναι για εσάς.
Επιτρέψτε μου να συστηθώ, παραδέχομαι πλήρως ότι υπάρχουν άνθρωποι στο δωμάτιο που δεν με γνωρίζουν. Ονομάζομαι Anton Boyko, είμαι MVP της Microsoft Azure. Τι είναι ο MVP; Αυτό είναι το Model-View-Presenter. Model-View-Presenter είμαι ακριβώς εγώ.
Επιπλέον, αυτή τη στιγμή κατέχω τη θέση του αρχιτέκτονα λύσεων στο Ciklum. Και μόλις πρόσφατα αγόρασα για τον εαυτό μου έναν τόσο όμορφο τομέα και ενημέρωσα το email μου, το οποίο συνήθως δείχνω σε παρουσιάσεις. Μπορείτε να μου γράψετε στο: me [dog] byokoant.pro. Μπορείτε να μου στείλετε email με ερωτήσεις. Συνήθως τους απαντώ. Το μόνο πράγμα είναι ότι δεν θα ήθελα να λαμβάνω ερωτήσεις μέσω email που σχετίζονται με δύο θέματα: την πολιτική και τη θρησκεία. Μπορείτε να μου γράψετε για οτιδήποτε άλλο μέσω email. Θα περάσει καιρός, θα απαντήσω.
Λίγα λόγια για τον εαυτό μου:
- Είμαι σε αυτόν τον τομέα 10 χρόνια τώρα.
- Δούλεψα στη Microsoft.
- Είμαι ο ιδρυτής της ουκρανικής κοινότητας Azure, την οποία ιδρύσαμε κάπου το 2014. Και το έχουμε ακόμα και το αναπτύσσουμε.
- Είμαι επίσης ο πατέρας του ιδρυτή του συνεδρίου Azure, το οποίο φιλοξενούμε στην Ουκρανία.
- Βοηθώ επίσης στη διοργάνωση του Global Azure Bootcamp στο Κίεβο.
- Όπως είπα, είμαι MVP του Microsoft Azure.
- Μιλάω σε συνέδρια αρκετά συχνά. Μου αρέσει πολύ να μιλάω σε συνέδρια. Τον περασμένο χρόνο μπόρεσα να παίξω περίπου 40 φορές. Εάν περάσετε από την Ουκρανία, τη Λευκορωσία, την Πολωνία, τη Βουλγαρία, τη Σουηδία, τη Δανία, την Ολλανδία, την Ισπανία ή δώσετε ή πάρετε μια άλλη χώρα στην Ευρώπη, τότε είναι πολύ πιθανό όταν πηγαίνετε σε ένα συνέδριο που έχει ένα θέμα cloud στη ροή του, μπορεί να με δείτε στη λίστα των ομιλητών.
- Είμαι επίσης φαν του Star Trek.
Ας μιλήσουμε λίγο για την Ατζέντα. Η ατζέντα μας είναι πολύ απλή:
- Θα μιλήσουμε για το τι είναι το DevOps. Ας μιλήσουμε γιατί αυτό είναι σημαντικό. Προηγουμένως, το DevOps ήταν μια λέξη-κλειδί που γράφατε στο βιογραφικό σας και λάβατε αμέσως +500$ σε μισθό. Τώρα πρέπει να γράψετε, για παράδειγμα, blockchain στο βιογραφικό σας για να πάρετε +500 δολάρια στον μισθό σας.
- Και μετά, όταν καταλάβουμε λίγο τι είναι αυτό, θα μιλήσουμε για το ποιες είναι οι πρακτικές DevOps. Αλλά όχι τόσο στο πλαίσιο του DevOps γενικά, αλλά σε εκείνες τις πρακτικές DevOps που μπορεί να ενδιαφέρουν τους προγραμματιστές. Θα σας πω γιατί μπορεί να σας ενδιαφέρουν. Θα σας πω γιατί πρέπει να το κάνετε αυτό και πώς μπορεί να σας βοηθήσει να αισθανθείτε λιγότερο πόνο.
Μια παραδοσιακή εικόνα που δείχνουν πολλοί. Αυτό συμβαίνει σε πολλά έργα. Αυτό συμβαίνει όταν έχουμε τμήματα ανάπτυξης και λειτουργιών που υποστηρίζουν το λογισμικό μας. Και αυτά τα τμήματα δεν επικοινωνούν μεταξύ τους.
Ίσως, αν δεν μπορούσατε να το νιώσετε τόσο καθαρά στα τμήματα DevOps και λειτουργιών, μπορείτε να κάνετε μια αναλογία με τα τμήματα Dev και QA. Υπάρχουν άνθρωποι που αναπτύσσουν λογισμικό και υπάρχουν άνθρωποι QA που είναι κακοί από την πλευρά των προγραμματιστών. Για παράδειγμα, δεσμεύω τον υπέροχο κώδικα μου στο αποθετήριο και κάθεται κάποιος απατεώνας που μου επιστρέφει αυτόν τον κωδικό και μου λέει ότι ο κώδικας σου είναι κακός.
Όλα αυτά συμβαίνουν επειδή οι άνθρωποι δεν επικοινωνούν μεταξύ τους. Και ρίχνουν κάποια πακέτα, κάποια εφαρμογή ο ένας στον άλλον μέσα από κάποιο τοίχο παρεξήγησης και προσπαθούν να κάνουν κάτι μαζί τους.
Είναι ακριβώς αυτό το τείχος που η κουλτούρα DevOps έχει σχεδιαστεί να καταστρέψει, δηλ. αναγκάστε τους ανθρώπους να επικοινωνήσουν μεταξύ τους και τουλάχιστον να καταλάβουν τι κάνουν τα διαφορετικά άτομα στο έργο και γιατί η δουλειά τους είναι σημαντική.
Και όταν μιλάμε για DevOps, κάποιος θα σας πει ότι το DevOps είναι όταν το έργο έχει συνεχή ενοποίηση. κάποιος θα πει ότι το DevOps είναι εάν το έργο εφαρμόζει την πρακτική της «υποδομής ως κώδικα». κάποιος θα πει ότι το πρώτο βήμα για το DevOps είναι η διακλάδωση χαρακτηριστικών, οι σημαίες χαρακτηριστικών.
Ουσιαστικά, όλα αυτά είναι αλήθεια με τον δικό τους τρόπο. Αλλά αυτές είναι μόνο οι απόλυτες πρακτικές που έχουμε. Πριν προχωρήσετε σε αυτές τις πρακτικές, προτείνω να δείτε αυτήν τη διαφάνεια, η οποία δείχνει τα 3 στάδια εφαρμογής της μεθοδολογίας Dev-Ops στο έργο σας, στην εταιρεία σας.
Αυτή η διαφάνεια έχει επίσης ένα δεύτερο ανεπίσημο όνομα. Μπορείτε να κάνετε αναζήτηση στο διαδίκτυο για να μάθετε ποιοι είναι οι 3 Σωματοφύλακες του DevOps. Είναι πιθανό να βρείτε αυτό το άρθρο. Γιατί 3 Σωματοφύλακες; Παρακάτω λέει: άνθρωποι, διαδικασίες και προϊόντα, δηλ. ΣΔΙΤ – Πόρθος, Πόρθος και Πόρθος. Εδώ είναι οι 3 σωματοφύλακες του DevOps. Αυτό το άρθρο περιγράφει με περισσότερες λεπτομέρειες γιατί αυτό είναι σημαντικό και τι συνεπάγεται.
Όταν ξεκινάτε να εφαρμόζετε μια κουλτούρα DevOps, είναι πολύ σημαντικό να υλοποιείται με την ακόλουθη σειρά.
Αρχικά πρέπει να μιλήσετε με ανθρώπους. Και πρέπει να εξηγήσετε στους ανθρώπους τι είναι και πώς μπορούν να αποκομίσουν κάποια οφέλη από αυτό.
Το συνέδριό μας ονομάζεται DotNet Fest. Και όπως μου είπαν οι διοργανωτές, προσκαλέσαμε κυρίως ένα κοινό προγραμματιστών εδώ, οπότε ελπίζω ότι οι περισσότεροι άνθρωποι στην αίθουσα ασχολούνται με την ανάπτυξη.
Θα μιλήσουμε για τους ανθρώπους, θα μιλήσουμε για το τι θέλουν να κάνουν οι προγραμματιστές κάθε μέρα. Τι θέλουν περισσότερο; Θέλουν να γράψουν κάποιο νέο κώδικα, να χρησιμοποιήσουν νέα πλαίσια, να δημιουργήσουν νέες δυνατότητες. Τι θέλουν λιγότερο οι προγραμματιστές; Διορθώστε παλιά σφάλματα. Ελπίζω να συμφωνείτε μαζί μου. Αυτό θέλουν οι προγραμματιστές. Θέλουν να γράψουν νέα χαρακτηριστικά, δεν θέλουν να διορθώσουν σφάλματα.
Ο αριθμός των σφαλμάτων που παράγει ένας συγκεκριμένος προγραμματιστής εξαρτάται από το πόσο ίσια είναι τα χέρια του και πόσο μεγαλώνουν από τους ώμους του και όχι από τις τσέπες του. Ωστόσο, όταν έχουμε ένα μεγάλο έργο, μερικές φορές συμβαίνει ότι είναι αδύνατο να παρακολουθούμε τα πάντα, επομένως θα ήταν ωραίο να χρησιμοποιήσουμε κάποιες προσεγγίσεις που θα μας βοηθήσουν να γράψουμε πιο σταθερό και ποιοτικότερο κώδικα.
Τι θέλουν περισσότερο τα QAs; Δεν ξέρω αν είναι στην αίθουσα. Μου είναι δύσκολο να πω ότι θέλω QA, γιατί δεν έχω υπάρξει ποτέ. Και καμία προσβολή στα παιδιά, θα ειπωθεί ότι ελπίζω να μην το κάνω ποτέ. Όχι όμως για τον λόγο ότι θεωρώ τη δουλειά τους ανούσια και άχρηστη, αλλά επειδή δεν θεωρώ τον εαυτό μου άτομο που θα μπορούσε να κάνει αυτή τη δουλειά αποτελεσματικά, οπότε δεν θα προσπαθήσω καν να το κάνω. Αλλά από ό,τι καταλαβαίνω, αυτό που δεν αρέσει περισσότερο στο QA είναι να λειτουργεί το πρωί, να τρέχει συνεχώς κάποιο είδος δοκιμών παλινδρόμησης, να πατά τα ίδια σφάλματα που ανέφεραν στους προγραμματιστές πριν από 3 σπριντ και να λέει: «Πότε θα , Monsieur D 'Artagnan, διορθώστε αυτό το σφάλμα.' Και ο κύριος Ντ’ Αρτανιάν του απαντά: «Ναι, ναι, ναι, το έχω ήδη φτιάξει». Και πώς συμβαίνει που διόρθωσα ένα σφάλμα και έκανα 5 στην πορεία.
Τα άτομα που υποστηρίζουν αυτήν τη λύση στην παραγωγή θέλουν αυτή η λύση να λειτουργεί χωρίς σφάλματα, έτσι ώστε να μην χρειάζεται να κάνουν επανεκκίνηση του διακομιστή κάθε Παρασκευή, όταν όλοι οι κανονικοί άνθρωποι πηγαίνουν στο μπαρ. Οι προγραμματιστές αναπτύχθηκαν την Παρασκευή, οι διαχειριστές κάθονται μέχρι το Σάββατο, προσπαθώντας να κάνουν αυτήν την ανάπτυξη και να διορθώσουν.
Και όταν εξηγείτε στους ανθρώπους ότι στοχεύουν στην επίλυση των ίδιων προβλημάτων, μπορείτε να προχωρήσετε στην επισημοποίηση των διαδικασιών. Είναι πολύ σημαντικό. Γιατί; Γιατί όταν λέμε "επισημοποίηση", είναι σημαντικό να περιγράψετε πώς συμβαίνουν οι διαδικασίες σας τουλάχιστον κάπου σε μια χαρτοπετσέτα. Πρέπει να καταλάβετε ότι εάν, για παράδειγμα, αναπτύξετε ένα περιβάλλον QA ή ένα περιβάλλον παραγωγής, τότε συμβαίνει πάντα με αυτήν τη σειρά· σε αυτά τα στάδια εκτελούμε, για παράδειγμα, αυτόματες δοκιμές μονάδων και δοκιμές διεπαφής χρήστη. Μετά την ανάπτυξη, ελέγχουμε αν η ανάπτυξη πήγε καλά ή άσχημα. Αλλά έχετε ήδη μια σαφή λίστα ενεργειών που πρέπει να επαναλαμβάνονται ξανά και ξανά όταν αναπτύσσετε στην παραγωγή.
Και μόνο όταν επισημοποιηθούν οι διαδικασίες σας, αρχίζετε να επιλέγετε προϊόντα που θα σας βοηθήσουν να αυτοματοποιήσετε αυτές τις διαδικασίες.
Δυστυχώς, πολύ συχνά το βλέπω να συμβαίνει αντίστροφα. Μόλις κάποιος ακούσει τη λέξη «DevOps», προτείνει αμέσως την εγκατάσταση του Jenkins, γιατί πιστεύει ότι μόλις εγκαταστήσει το Jenkins, θα έχει DevOps. Εγκατέστησαν το Jenkins, διάβασαν τα άρθρα "How to" στον ιστότοπο του Jenkins, προσπάθησαν να βάλουν διεργασίες σε αυτά τα άρθρα "How to" και μετά ήρθαν σε ανθρώπους και έσκυψαν τους ανθρώπους, λέγοντας ότι το βιβλίο λέει ότι πρέπει να το κάνεις με αυτόν τον τρόπο, οπότε το κάνουμε με αυτόν τον τρόπο.
Δεν είναι ότι ο Τζένκινς είναι κακό εργαλείο. Δεν θέλω να το πω με κανέναν τρόπο. Αλλά αυτό είναι μόνο ένα από τα προϊόντα. Και ποιο προϊόν θα χρησιμοποιήσετε θα πρέπει να είναι η τελευταία σας απόφαση, και σε καμία περίπτωση η πρώτη σας. Το προϊόν σας δεν πρέπει να καθοδηγείται από την εφαρμογή κουλτούρας και προσεγγίσεων. Αυτό είναι πολύ σημαντικό να το καταλάβουμε, γι' αυτό ξοδεύω τόσο πολύ χρόνο σε αυτήν τη διαφάνεια και τα εξηγώ όλα αυτά για τόσο καιρό.
Ας μιλήσουμε για τις πρακτικές DevOps γενικά. Τι είναι? Ποιά είναι η διαφορά? Πώς να τα δοκιμάσετε; Γιατί είναι σημαντικά;
Η πρώτη πρακτική που ίσως έχετε ακούσει ονομάζεται Συνεχής Ενσωμάτωση. Ίσως κάποιος στο έργο έχει Συνεχή Ενοποίηση (CI).
Το μεγαλύτερο πρόβλημα είναι ότι πιο συχνά όταν ρωτάω ένα άτομο: "Έχετε CI στο έργο;" και λέει: «Ναι», τότε όταν ρωτάω τι κάνει, μου περιγράφει απολύτως όλη τη διαδικασία αυτοματισμού. Αυτό δεν είναι απολύτως αληθές.
Στην πραγματικότητα, η πρακτική του CI στοχεύει απλώς στην ενσωμάτωση του κώδικα που γράφουν διαφορετικοί άνθρωποι σε κάποιο είδος ενιαίας βάσης κώδικα. Αυτό είναι όλο.
Μαζί με το CI, υπάρχουν συνήθως και άλλες πρακτικές στην πορεία - όπως η συνεχής ανάπτυξη, η διαχείριση εκδόσεων, αλλά θα μιλήσουμε για αυτό αργότερα.
Το ίδιο το CI μας λέει ότι διαφορετικοί άνθρωποι γράφουν κώδικα και αυτός ο κώδικας πρέπει να ενσωματώνεται συνεχώς σε μια ενιαία βάση κώδικα.
Τι μας δίνει αυτό και γιατί είναι σημαντικό; Αν έχουμε DotNet, τότε αυτό είναι καλό, είναι μια μεταγλωττισμένη γλώσσα, μπορούμε να μεταγλωττίσουμε την εφαρμογή μας. Εάν μεταγλωττιστεί, τότε αυτό είναι ήδη ένα καλό σημάδι. Αυτό δεν σημαίνει τίποτα ακόμα, αλλά είναι το πρώτο καλό σημάδι ότι μπορούμε τουλάχιστον να συντάξουμε.
Στη συνέχεια, μπορούμε να εκτελέσουμε κάποιες δοκιμές, που είναι επίσης μια ξεχωριστή πρακτική. Τα τεστ είναι όλα πράσινα – αυτό είναι το δεύτερο καλό σημάδι. Αλλά και πάλι, αυτό δεν σημαίνει τίποτα.
Αλλά γιατί να το κάνεις αυτό; Όλες οι πρακτικές για τις οποίες θα μιλήσω σήμερα έχουν περίπου την ίδια αξία, δηλαδή περίπου τα ίδια οφέλη και επίσης μετρώνται περίπου με τον ίδιο τρόπο.
Πρώτον, σας επιτρέπει να επιταχύνετε την παράδοση. Πώς σας επιτρέπει αυτό να επιταχύνετε την παράδοση; Όταν κάνουμε κάποιες νέες αλλαγές στη βάση του κώδικα μας, μπορούμε αμέσως να προσπαθήσουμε να κάνουμε κάτι με αυτόν τον κώδικα. Δεν περιμένουμε να έρθει η Πέμπτη γιατί την Πέμπτη το κυκλοφορούμε στο QA Environment, το κάνουμε εδώ και εδώ.
Θα σας πω μια θλιβερή ιστορία από τη ζωή μου. Ήταν πολύ καιρό πριν, όταν ήμουν ακόμα νέος και όμορφος. Τώρα είμαι ήδη νέος, όμορφος και έξυπνος και σεμνός. Πριν λίγο καιρό ήμουν σε ένα έργο. Είχαμε μια μεγάλη ομάδα περίπου 30 προγραμματιστών. Και είχαμε ένα μεγάλο, μεγάλο έργο Enterprise που αναπτύχθηκε για περίπου 10 χρόνια. Και είχαμε διαφορετικά υποκαταστήματα. Στο αποθετήριο είχαμε ένα υποκατάστημα στο οποίο περπατούσαν προγραμματιστές. Και υπήρχε ένα υποκατάστημα που εμφάνιζε την έκδοση του κώδικα που είναι σε παραγωγή.
Ο κλάδος παραγωγής ήταν 3 μήνες πίσω από τον κλάδο που ήταν διαθέσιμος στους προγραμματιστές. Τι σημαίνει αυτό? Αυτό σημαίνει ότι από τη στιγμή που έχω ένα σφάλμα κάπου που πηγαίνει στην παραγωγή λόγω υπαιτιότητας των προγραμματιστών, επειδή το επέτρεψαν, και λόγω σφάλματος του QA, επειδή το εξέτασαν, τότε αυτό σημαίνει ότι εάν λάβω ένα εργασία για επείγουσα επιδιόρθωση για παραγωγή, τότε πρέπει να επαναφέρω τις αλλαγές στον κώδικα πριν από 3 μήνες. Πρέπει να θυμηθώ τι είχα πριν από 3 μήνες και να προσπαθήσω να το φτιάξω εκεί.
Εάν δεν είχατε αυτήν την εμπειρία ακόμα, μπορείτε να τη δοκιμάσετε στο έργο του σπιτιού σας. Το κύριο πράγμα είναι, μην το δοκιμάσετε σε εμπορικό. Γράψτε μερικές γραμμές κώδικα, ξεχάστε τις για έξι μήνες και μετά επιστρέψτε και προσπαθήστε να εξηγήσετε γρήγορα τι αφορούν αυτές οι γραμμές κώδικα και πώς μπορείτε να τις διορθώσετε ή να τις βελτιστοποιήσετε. Είναι μια πολύ, πολύ συναρπαστική εμπειρία.
Εάν έχουμε μια πρακτική Συνεχούς Ενσωμάτωσης, τότε αυτό μας επιτρέπει να την ελέγξουμε με μια σειρά αυτοματοποιημένων εργαλείων εδώ και τώρα, μόλις γράψω τον κώδικά μου. Αυτό μπορεί να μην μου δίνει την πλήρη εικόνα, αλλά παρ' όλα αυτά, θα αφαιρέσει τουλάχιστον μερικούς από τους κινδύνους. Και αν υπάρχει κάποιο πιθανό σφάλμα, θα το μάθω αμέσως, δηλαδή κυριολεκτικά σε λίγα λεπτά. Δεν θα χρειαστεί να γυρίσω πίσω 3 μήνες. Θα χρειαστεί να επιστρέψω μόνο 2 λεπτά. Μια καλή καφετιέρα δεν θα έχει καν χρόνο να φτιάξει καφέ σε 2 λεπτά, οπότε είναι πολύ ωραίο.
Αυτό έχει την αξία ότι μπορεί να επαναλαμβάνεται κάθε φορά σε κάθε έργο, π.χ. όχι μόνο σε αυτόν που το ρυθμίσατε. Μπορείτε να επαναλάβετε τόσο την ίδια την πρακτική όσο και το ίδιο το CI θα επαναλαμβάνεται για κάθε νέα αλλαγή που κάνετε στο έργο. Αυτό σας επιτρέπει να βελτιστοποιήσετε τους πόρους επειδή η ομάδα σας λειτουργεί πιο αποτελεσματικά. Δεν θα έχετε πλέον μια κατάσταση όπου εμφανίζεται ένα σφάλμα από τον κωδικό με τον οποίο εργαστήκατε πριν από 3 μήνες. Δεν θα έχετε πλέον εναλλαγή περιβάλλοντος όταν κάθεστε και ξοδεύετε τις δύο πρώτες ώρες προσπαθώντας να καταλάβετε τι συνέβη τότε και να μπείτε στην ουσία του πλαισίου προτού αρχίσετε να διορθώνετε κάτι.
Πώς μπορούμε να μετρήσουμε την επιτυχία ή την αποτυχία αυτής της πρακτικής; Αν αναφέρετε στο μεγάλο αφεντικό τι εφαρμόσαμε στο έργο CI, ακούει μπλα μπλα μπλα. Το εφαρμόσαμε, εντάξει, αλλά γιατί, τι μας έφερε, πώς το μετράμε, πόσο σωστά ή λάθος το εφαρμόζουμε;
Το πρώτο είναι ότι, χάρη στο CI, μπορούμε να αναπτύσσουμε όλο και πιο συχνά, και πιο συχνά ακριβώς επειδή ο κώδικάς μας είναι δυνητικά πιο σταθερός. Με τον ίδιο τρόπο, μειώνεται ο χρόνος μας για να βρούμε ένα σφάλμα και μειώνεται ο χρόνος για τη διόρθωση αυτού του σφάλματος ακριβώς για το λόγο ότι λαμβάνουμε μια απάντηση από το σύστημα εδώ και τώρα, τι φταίει ο κώδικάς μας.
Μια άλλη πρακτική που έχουμε είναι η πρακτική της αυτοματοποίησης δοκιμής, η οποία συνήθως συνοδεύεται από την πρακτική CI. Πάνε χέρι-χέρι.
Τι είναι σημαντικό να καταλάβουμε εδώ; Είναι σημαντικό να καταλάβουμε ότι οι δοκιμές μας είναι διαφορετικές. Και κάθε αυτοματοποιημένο τεστ στοχεύει στην επίλυση των δικών του προβλημάτων. Έχουμε, για παράδειγμα, δοκιμές μονάδας που μας επιτρέπουν να δοκιμάσουμε μια ενότητα ξεχωριστά, π.χ. Πώς λειτουργεί στο κενό; Αυτό είναι καλό.
Έχουμε επίσης δοκιμές ολοκλήρωσης που μας επιτρέπουν να κατανοήσουμε πώς οι διαφορετικές ενότητες ενσωματώνονται μεταξύ τους. Είναι επίσης καλό.
Ενδέχεται να έχουμε δοκιμές αυτοματισμού διεπαφής χρήστη που μας επιτρέπουν να ελέγχουμε πόσο καλά η εργασία με τη διεπαφή χρήστη πληροί ορισμένες απαιτήσεις που ορίζονται από τον πελάτη κ.λπ.
Οι συγκεκριμένες δοκιμές που εκτελείτε μπορούν να επηρεάσουν τη συχνότητα που τις εκτελείτε. Τα τεστ μονάδων είναι συνήθως γραμμένα σύντομα και μικρά. Και μπορούν να κυκλοφορούν τακτικά.
Αν μιλάμε για δοκιμές αυτοματισμού διεπαφής χρήστη, τότε είναι καλό αν το έργο σας είναι μικρό. Οι δοκιμές αυτοματισμού διεπαφής χρήστη μπορεί να διαρκέσουν αρκετό χρόνο. Αλλά συνήθως μια δοκιμή αυτοματισμού διεπαφής χρήστη είναι κάτι που διαρκεί αρκετές ώρες σε ένα μεγάλο έργο. Και είναι καλό αν είναι λίγες ώρες. Το μόνο πράγμα είναι ότι δεν έχει νόημα να τα τρέχουμε για κάθε κατασκευή. Είναι λογικό να τα τρέχετε τη νύχτα. Και όταν όλοι ήρθαν στη δουλειά το πρωί: τόσο οι υπεύθυνοι δοκιμών όσο και οι προγραμματιστές, έλαβαν κάποιο είδος αναφοράς ότι εκτελέσαμε τον αυτόματο έλεγχο διεπαφής χρήστη τη νύχτα και λάβαμε αυτά τα αποτελέσματα. Και εδώ, μια ώρα εργασίας ενός διακομιστή που θα ελέγξει ότι το προϊόν σας πληροί κάποιες απαιτήσεις θα είναι πολύ φθηνότερη από μια ώρα εργασίας του ίδιου μηχανικού QA, ακόμα κι αν είναι ένας Junior QA μηχανικός που εργάζεται για φαγητό και ευχαριστεί. Παρόλα αυτά, μια ώρα λειτουργίας του μηχανήματος θα είναι φθηνότερη. Γι' αυτό είναι λογικό να επενδύσουμε σε αυτό.
Έχω ένα άλλο έργο στο οποίο δουλεύω. Είχαμε σπριντ δύο εβδομάδων σε αυτό το έργο. Το έργο ήταν μεγάλο, σημαντικό για τον χρηματοοικονομικό τομέα και δεν μπορούσε να γίνει λάθος. Και μετά από ένα σπριντ δύο εβδομάδων, ο κύκλος ανάπτυξης ακολουθήθηκε από μια διαδικασία δοκιμών, η οποία διήρκεσε άλλες 4 εβδομάδες. Προσπαθήστε να φανταστείτε το μέγεθος της τραγωδίας. Γράφουμε κώδικα για δύο εβδομάδες, μετά τον κάνουμε ala CodeFreeze, τον συσκευάζουμε σε μια νέα έκδοση της εφαρμογής και τον παρουσιάζουμε στους δοκιμαστές. Οι δοκιμαστές το δοκιμάζουν για άλλες 4 εβδομάδες, δηλ. Όσο το δοκιμάζουν, έχουμε χρόνο να τους ετοιμάσουμε άλλες δύο εκδόσεις. Αυτή είναι μια πραγματικά θλιβερή περίπτωση.
Και τους είπαμε ότι αν θέλετε να είστε πιο παραγωγικοί, είναι λογικό να εφαρμόσετε πρακτικές Αυτοματοποιημένων Δοκιμών, γιατί αυτό είναι που σας πληγώνει εδώ, αυτή τη στιγμή.
Εξασκηθείτε στη Συνεχή Ανάπτυξη. Τέλεια, τελείωσες την κατασκευή. Αυτό είναι ήδη καλό. Ο κώδικάς σας έχει μεταγλωττιστεί. Τώρα θα ήταν ωραίο να αναπτυχθεί αυτό το build σε κάποιο περιβάλλον. Ας πούμε σε ένα περιβάλλον για προγραμματιστές.
Γιατί είναι σημαντικό? Αρχικά, μπορείτε να δείτε πόσο επιτυχημένος είστε με την ίδια τη διαδικασία ανάπτυξης. Έχω συναντήσει έργα σαν αυτό, όταν ρωτάω: «Πώς αναπτύσσεις μια νέα έκδοση της εφαρμογής;», τα παιδιά μου λένε: «Τη συναρμολογούμε και τη συσκευάζουμε σε ένα αρχείο zip. Το στέλνουμε στον διαχειριστή μέσω ταχυδρομείου. Ο διαχειριστής κατεβάζει και επεκτείνει αυτό το αρχείο. Και όλο το γραφείο αρχίζει να προσεύχεται ώστε ο διακομιστής να παραλάβει τη νέα έκδοση.»
Ας ξεκινήσουμε με κάτι απλό. Για παράδειγμα, ξέχασαν να βάλουν το CSS στο αρχείο ή ξέχασαν να αλλάξουν το hashtag στο όνομα του αρχείου java-script. Και όταν κάνουμε ένα αίτημα στον διακομιστή, το πρόγραμμα περιήγησης πιστεύει ότι έχει ήδη αυτό το αρχείο java-script και αποφασίζει να μην το κατεβάσει. Και υπήρχε μια παλιά έκδοση, κάτι έλειπε. Γενικά, μπορεί να υπάρχουν πολλά προβλήματα. Επομένως, η πρακτική της Συνεχούς Ανάπτυξης σάς επιτρέπει να δοκιμάσετε τουλάχιστον τι θα συνέβαινε εάν τραβούσατε μια καθαρή εικόνα αναφοράς και τη ανεβάζατε σε ένα εντελώς καθαρό νέο περιβάλλον. Μπορείτε να δείτε πού οδηγεί αυτό.
Επίσης, όταν ενσωματώνετε κώδικα μεταξύ τους, π.χ. μεταξύ της εντολής, αυτό σας επιτρέπει επίσης να δείτε πώς φαίνεται στο UI.
Ένα από τα προβλήματα που παρουσιάζονται όταν χρησιμοποιούνται πολλά σενάρια java βανίλια είναι ότι δύο προγραμματιστές δήλωσαν βιαστικά μια μεταβλητή με το ίδιο όνομα στο αντικείμενο του παραθύρου. Και μετά, ανάλογα με την τύχη σου. Όποιος το αρχείο java-script βγαίνει δεύτερο θα αντικαταστήσει τις αλλαγές του άλλου. Είναι επίσης πολύ συναρπαστικό. Μπαίνεις: ένα πράγμα λειτουργεί για ένα άτομο, ένα άλλο δεν λειτουργεί για άλλον. Και είναι «υπέροχο» όταν όλα βγαίνουν στην παραγωγή.
Η επόμενη πρακτική που έχουμε είναι η πρακτική της Αυτόματης Επαναφοράς, δηλαδή η επαναφορά στην προηγούμενη έκδοση της εφαρμογής.
Γιατί είναι αυτό σημαντικό για τους προγραμματιστές; Υπάρχουν ακόμα εκείνοι που θυμούνται τη μακρινή, μακρινή δεκαετία του '90, όταν οι υπολογιστές ήταν μεγάλοι και τα προγράμματα μικρά. Και ο μόνος τρόπος για την ανάπτυξη Ιστού ήταν μέσω PHP. Δεν είναι ότι η PHP είναι κακή γλώσσα, αν και είναι.
Όμως το πρόβλημα ήταν διαφορετικό. Όταν αναπτύξαμε μια νέα έκδοση του ιστότοπού μας php, πώς την αναπτύξαμε; Τις περισσότερες φορές ανοίγαμε το Far Manager ή κάτι άλλο. Και ανέβασε αυτά τα αρχεία στο FTP. Και ξαφνικά συνειδητοποιήσαμε ότι είχαμε κάποιο μικρό, μικρό σφάλμα, για παράδειγμα, ξεχάσαμε να βάλουμε ένα ερωτηματικό ή ξεχάσαμε να αλλάξουμε τον κωδικό πρόσβασης για τη βάση δεδομένων και υπάρχει ένας κωδικός πρόσβασης για τη βάση δεδομένων, ο οποίος βρίσκεται στον τοπικό κεντρικό υπολογιστή. Και αποφασίζουμε να συνδεθούμε γρήγορα στο FTP και να επεξεργαστούμε τα αρχεία ακριβώς εκεί. Αυτό είναι απλά φωτιά! Αυτό ήταν δημοφιλές στη δεκαετία του '90.
Αλλά, αν δεν έχετε κοιτάξει το ημερολόγιο, τα 90s ήταν σχεδόν 30 χρόνια πριν. Τώρα όλα γίνονται λίγο διαφορετικά. Και προσπαθήστε να φανταστείτε το μέγεθος της τραγωδίας όταν σας λένε: «Επεξεργαστήκαμε στην παραγωγή, αλλά κάτι πήγε στραβά εκεί. Εδώ είναι τα στοιχεία σύνδεσης και ο κωδικός πρόσβασής σας στο FTP, συνδεθείτε στην παραγωγή και διορθώστε τα γρήγορα εκεί." Αν είσαι ο Τσακ Νόρις, αυτό θα λειτουργήσει. Αν όχι, τότε κινδυνεύετε να διορθώσετε ένα σφάλμα, να δημιουργήσετε άλλα 10. Αυτός ακριβώς είναι ο λόγος που αυτή η πρακτική της επαναφοράς στην προηγούμενη έκδοση σας επιτρέπει να επιτύχετε πολλά.
Ακόμα κι αν κάτι κακό με κάποιο τρόπο μπήκε στο prod κάπου, τότε είναι κακό, αλλά όχι μοιραίο. Μπορείτε να επιστρέψετε στην προηγούμενη έκδοση που έχετε. Ονομάστε το εφεδρικό, αν είναι πιο εύκολο να το αντιληφθείτε με αυτήν την ορολογία. Μπορείτε να επιστρέψετε σε αυτήν την προηγούμενη έκδοση και οι χρήστες θα εξακολουθούν να μπορούν να εργαστούν με το προϊόν σας και θα έχετε επαρκή χρόνο προσωρινής αποθήκευσης. Μπορείτε ήρεμα, χωρίς βιασύνη, να τα πάρετε όλα αυτά και να τα δοκιμάσετε τοπικά, να τα διορθώσετε και μετά να ανεβάσετε μια νέα έκδοση. Είναι πραγματικά λογικό να το κάνουμε αυτό.
Τώρα ας προσπαθήσουμε να συνδυάσουμε με κάποιο τρόπο τις δύο προηγούμενες πρακτικές μαζί. Θα πάρουμε ένα τρίτο που ονομάζεται Διαχείριση εκδόσεων.
Όταν μιλάμε για τη Συνεχή Ανάπτυξη στην κλασική της μορφή, λέμε ότι πρέπει να τραβήξουμε κώδικα από κάποιο κλάδο από το αποθετήριο, να τον μεταγλωττίσουμε και να τον αναπτύξουμε. Είναι καλό να έχουμε το ίδιο περιβάλλον. Αν έχουμε πολλά περιβάλλοντα, αυτό σημαίνει ότι πρέπει να τραβάμε τον κώδικα κάθε φορά, ακόμα και από την ίδια δέσμευση. Θα το βγάζουμε κάθε φορά, θα το χτίζουμε κάθε φορά και θα το αναπτύσσουμε σε ένα νέο περιβάλλον. Πρώτον, αυτή είναι η ώρα, γιατί για να φτιάξεις ένα έργο, αν έχεις ένα μεγάλο και ήρθες από τη δεκαετία του '90, τότε μπορεί να χρειαστούν αρκετές ώρες.
Άλλωστε υπάρχει και μια άλλη θλίψη. Όταν κατασκευάζετε, ακόμα και στο ίδιο μηχάνημα, θα δημιουργήσετε τις ίδιες πηγές, δεν έχετε ακόμα καμία εγγύηση ότι αυτό το μηχάνημα είναι στην ίδια κατάσταση όπως ήταν κατά την τελευταία κατασκευή.
Ας υποθέσουμε ότι κάποιος μπήκε και ενημέρωσε το DotNet για εσάς ή, αντίθετα, κάποιος αποφάσισε να διαγράψει κάτι. Και τότε έχετε γνωστική ασυμφωνία ότι από αυτή τη δέσμευση πριν από δύο εβδομάδες χτίζαμε μια κατασκευή και όλα ήταν καλά, αλλά τώρα φαίνεται σαν το ίδιο μηχάνημα, η ίδια δέσμευση, ο ίδιος κώδικας που προσπαθούμε να δημιουργήσουμε, αλλά δεν λειτουργεί . Θα ασχολείσαι με αυτό για πολύ καιρό και δεν είναι γεγονός ότι θα το καταλάβεις. Τουλάχιστον θα χαλάσεις πολύ τα νεύρα σου.
Επομένως, η πρακτική της διαχείρισης εκδόσεων προτείνει την εισαγωγή μιας πρόσθετης αφαίρεσης που ονομάζεται αποθήκη τεχνουργημάτων ή γκαλερί ή βιβλιοθήκη. Μπορείτε να το ονομάσετε όπως θέλετε.
Η κύρια ιδέα είναι ότι μόλις έχουμε κάποιο είδος δέσμευσης εκεί, ας πούμε, σε έναν κλάδο που είμαστε έτοιμοι να αναπτύξουμε στα διαφορετικά περιβάλλοντά μας, συλλέγουμε εφαρμογές από αυτό το commit και ό,τι χρειαζόμαστε για αυτήν την εφαρμογή, το πακετάρουμε σε ένα αρχείο zip και αποθηκεύστε το σε κάποια αξιόπιστη αποθήκευση. Και από αυτόν τον χώρο αποθήκευσης μπορούμε να λάβουμε αυτό το αρχείο zip ανά πάσα στιγμή.
Στη συνέχεια το παίρνουμε και το αναπτύσσουμε αυτόματα στο περιβάλλον dev. Αγωνιζόμαστε εκεί, και αν όλα είναι καλά, τότε ανεβαίνουμε στη σκηνή. Αν όλα πάνε καλά, τότε αναπτύσσουμε το ίδιο αρχείο στην παραγωγή, τα ίδια δυαδικά αρχεία, που έχουν μεταγλωττιστεί ακριβώς μία φορά.
Επιπλέον, όταν έχουμε μια συλλογή όπως αυτή, μας βοηθά επίσης να αντιμετωπίσουμε τους κινδύνους που αντιμετωπίσαμε στην τελευταία διαφάνεια όταν μιλήσαμε για επαναφορά στην προηγούμενη έκδοση. Εάν κατά λάθος αναπτύξατε κάτι λάθος, μπορείτε πάντα να πάρετε οποιαδήποτε άλλη προηγούμενη έκδοση από αυτήν τη συλλογή και να την αναιρέσετε σε αυτά τα περιβάλλοντα με τον ίδιο τρόπο. Αυτό σας επιτρέπει να επιστρέψετε εύκολα στην προηγούμενη έκδοση εάν κάτι πάει στραβά.
Υπάρχει μια άλλη μεγάλη πρακτική. Εσείς και εγώ όλοι καταλαβαίνουμε ότι όταν επαναφέρουμε τις εφαρμογές μας σε μια προηγούμενη έκδοση, αυτό μπορεί να σημαίνει ότι χρειαζόμαστε επίσης την υποδομή της προηγούμενης έκδοσης.
Όταν μιλάμε για εικονική υποδομή, πολλοί άνθρωποι πιστεύουν ότι αυτό είναι κάτι που ρυθμίζουν οι διαχειριστές. Και αν χρειάζεστε, ας πούμε, να αποκτήσετε έναν νέο διακομιστή στον οποίο θέλετε να δοκιμάσετε μια νέα έκδοση της εφαρμογής σας, τότε πρέπει να γράψετε ένα εισιτήριο στους διαχειριστές ή τους προγραμματιστές. Οι Devops θα χρειαστούν 3 εβδομάδες για αυτό. Και μετά από 3 εβδομάδες θα σας πουν ότι έχουμε εγκαταστήσει μια εικονική μηχανή για εσάς, με έναν πυρήνα, δύο gigabyte μνήμης RAM και έναν διακομιστή Windows χωρίς DotNet. Λέτε: «Αλλά ήθελα το DotNet». Αυτοί: «Εντάξει, έλα πίσω σε 3 εβδομάδες».
Η ιδέα είναι ότι χρησιμοποιώντας την Υποδομή ως πρακτικές κώδικα, μπορείτε να αντιμετωπίζετε την εικονική υποδομή σας ως απλώς έναν άλλο πόρο.
Ίσως, εάν κάποιος από εσάς αναπτύσσει εφαρμογές στο DotNet, μπορεί να έχετε ακούσει για μια βιβλιοθήκη που ονομάζεται Entity Framework. Και ίσως έχετε ακούσει ακόμη ότι το Entity Framework είναι μία από τις προσεγγίσεις που η Microsoft προωθεί ενεργά. Για την εργασία με μια βάση δεδομένων, αυτή είναι μια προσέγγιση που ονομάζεται Code First. Αυτό συμβαίνει όταν περιγράφετε σε κώδικα πώς θέλετε να φαίνεται η βάση δεδομένων σας. Και μετά αναπτύσσετε την εφαρμογή. Συνδέεται με τη βάση δεδομένων, καθορίζει μόνος του ποιοι πίνακες υπάρχουν και ποιοι πίνακες όχι και δημιουργεί όλα όσα χρειάζεστε.
Μπορείτε να κάνετε το ίδιο με την υποδομή σας. Δεν υπάρχει διαφορά μεταξύ του αν χρειάζεστε μια βάση δεδομένων για ένα έργο ή εάν χρειάζεστε έναν διακομιστή Windows για ένα έργο. Είναι απλώς ένας πόρος. Και μπορείτε να αυτοματοποιήσετε τη δημιουργία αυτού του πόρου, μπορείτε να αυτοματοποιήσετε τη διαμόρφωση αυτού του πόρου. Αντίστοιχα, κάθε φορά που θέλετε να δοκιμάσετε κάποια νέα ιδέα, κάποια νέα προσέγγιση, δεν θα χρειάζεται να γράψετε ένα εισιτήριο στο devops, μπορείτε απλά να αναπτύξετε μια απομονωμένη υποδομή για τον εαυτό σας από έτοιμα πρότυπα, από έτοιμα σενάρια και να την εφαρμόσετε εκεί όλα τα πειράματά σας. Μπορείτε να το διαγράψετε, να λάβετε κάποια αποτελέσματα και να αναφέρετε περαιτέρω.
Η επόμενη πρακτική, η οποία επίσης υπάρχει και είναι επίσης σημαντική, αλλά που λίγοι τη χρησιμοποιούν, είναι η Παρακολούθηση Απόδοσης Εφαρμογών.
Ήθελα να πω μόνο ένα πράγμα για την Παρακολούθηση Απόδοσης Εφαρμογών. Τι είναι πιο σημαντικό για αυτή την πρακτική; Αυτή είναι η Παρακολούθηση Απόδοσης Εφαρμογής περίπου το ίδιο με την επισκευή ενός διαμερίσματος. Αυτό δεν είναι μια τελική κατάσταση, είναι μια διαδικασία. Πρέπει να το κάνετε τακτικά.
Με την καλή έννοια, θα ήταν καλό να πραγματοποιείτε Παρακολούθηση Απόδοσης Εφαρμογών σχεδόν σε κάθε έκδοση, αν και, όπως καταλαβαίνετε, αυτό δεν είναι πάντα δυνατό. Αλλά, τουλάχιστον, πρέπει να εκτελείται για κάθε έκδοση.
Γιατί είναι σημαντικό? Γιατί αν ξαφνικά αντιμετωπίσετε πτώση στην απόδοση, τότε πρέπει να καταλάβετε ξεκάθαρα το γιατί. Εάν η ομάδα σας έχει, ας πούμε, σπριντ δύο εβδομάδων, τότε τουλάχιστον μία φορά κάθε δύο εβδομάδες θα πρέπει να αναπτύξετε την εφαρμογή σας σε κάποιον ξεχωριστό διακομιστή, όπου έχετε σαφώς σταθερό επεξεργαστή, μνήμη RAM, δίσκους κ.λπ. Και να εκτελέσετε τα ίδια τεστ απόδοσης . Παίρνετε το αποτέλεσμα. Δείτε πώς έχει αλλάξει από το προηγούμενο σπριντ.
Και αν ανακαλύψετε ότι η ανάληψη κάπου μειώθηκε απότομα, θα σημαίνει ότι ήταν μόνο λόγω των αλλαγών που έλαβαν χώρα τις τελευταίες δύο εβδομάδες. Αυτό θα σας επιτρέψει να εντοπίσετε και να διορθώσετε το πρόβλημα πολύ πιο γρήγορα. Και πάλι, αυτές είναι περίπου οι ίδιες μετρήσεις με τις οποίες μπορείτε να μετρήσετε πόσο επιτυχώς το κάνατε.
Η επόμενη πρακτική που έχουμε είναι η πρακτική Configuration Management. Είναι πολύ λίγοι αυτοί που το παίρνουν στα σοβαρά. Αλλά πιστέψτε με, αυτό είναι πραγματικά ένα πολύ σοβαρό πράγμα.
Πρόσφατα υπήρξε μια αστεία ιστορία. Τα παιδιά ήρθαν σε μένα και μου είπαν: «Βοηθήστε μας να κάνουμε έναν έλεγχο ασφαλείας της εφαρμογής μας». Κοιτάξαμε τον κώδικα μαζί για πολλή ώρα, μου είπαν για την εφαρμογή, σχεδίασαν διαγράμματα. Και συν ή πλην όλα ήταν λογικά, κατανοητά, ασφαλή, αλλά υπήρχε ένα ΑΛΛΑ! Είχαν αρχεία διαμόρφωσης στον έλεγχο πηγής, συμπεριλαμβανομένων εκείνων από την παραγωγή με τη βάση δεδομένων IP, με στοιχεία σύνδεσης και κωδικούς πρόσβασης για σύνδεση σε αυτές τις βάσεις δεδομένων κ.λπ.
Και λέω: «Παιδιά, εντάξει, έχετε κλείσει το περιβάλλον παραγωγής σας με ένα τείχος προστασίας, αλλά το γεγονός ότι έχετε το login και τον κωδικό πρόσβασης για τη βάση δεδομένων παραγωγής ακριβώς στο source control και οποιοσδήποτε προγραμματιστής μπορεί να το διαβάσει είναι ήδη τεράστιος κίνδυνος ασφάλειας . Και ανεξάρτητα από το πόσο εξαιρετικά ασφαλής είναι η εφαρμογή σας από την άποψη του κώδικα, εάν την αφήσετε στον έλεγχο πηγής, τότε δεν θα περάσετε ποτέ κανέναν έλεγχο πουθενά." Αυτο λεω.
Διαχείριση διαμόρφωσης. Μπορεί να έχουμε διαφορετικές διαμορφώσεις σε διαφορετικά περιβάλλοντα. Για παράδειγμα, μπορεί να έχουμε διαφορετικά στοιχεία σύνδεσης και κωδικούς πρόσβασης για βάσεις δεδομένων για QA, επίδειξη, περιβάλλον παραγωγής κ.λπ.
Αυτή η διαμόρφωση μπορεί επίσης να αυτοματοποιηθεί. Θα πρέπει πάντα να είναι ξεχωριστό από την ίδια την εφαρμογή. Γιατί; Επειδή δημιουργήσατε την εφαρμογή μία φορά και, στη συνέχεια, η εφαρμογή δεν ενδιαφέρεται εάν συνδέεστε στον διακομιστή SQL μέσω αυτής και της τάδε IP ή μιας τέτοιας και μιας τέτοιας IP, θα πρέπει να λειτουργεί το ίδιο. Επομένως, εάν ξαφνικά κάποιος από εσάς εξακολουθεί να κωδικοποιεί τη συμβολοσειρά σύνδεσης στον κώδικα, τότε να θυμάστε ότι θα σας βρω και θα σας τιμωρήσω εάν βρεθείτε στο ίδιο έργο με εμένα. Αυτό τοποθετείται πάντα σε ξεχωριστή διαμόρφωση, για παράδειγμα, στο web.config.
Και η διαχείριση αυτής της διαμόρφωσης γίνεται ήδη ξεχωριστά, δηλαδή αυτή είναι ακριβώς η στιγμή που ένας προγραμματιστής και ένας διαχειριστής μπορούν να έρθουν και να καθίσουν στο ίδιο δωμάτιο. Και ο προγραμματιστής μπορεί να πει: «Κοίτα, εδώ είναι τα δυαδικά αρχεία της εφαρμογής μου. Δουλεύουν. Η εφαρμογή χρειάζεται μια βάση δεδομένων για να λειτουργήσει. Εδώ δίπλα στα δυαδικά υπάρχει ένα αρχείο. Σε αυτό το αρχείο, αυτό το πεδίο είναι υπεύθυνο για τη σύνδεση, αυτό είναι για τον κωδικό πρόσβασης, αυτό είναι για την IP. Αναπτύξτε το οπουδήποτε." Και είναι απλό και ξεκάθαρο για τον διαχειριστή. Μπορεί να το αναπτύξει πραγματικά οπουδήποτε διαχειριζόμενος αυτήν τη διαμόρφωση.
Και η τελευταία πρακτική για την οποία θα ήθελα να μιλήσω είναι μια πρακτική που σχετίζεται πολύ, πολύ με τα σύννεφα. Και φέρνει το μέγιστο αποτέλεσμα εάν εργάζεστε στο cloud. Αυτή είναι η αυτόματη αφαίρεση του περιβάλλοντος σας.
Ξέρω ότι υπάρχουν πολλά άτομα σε αυτό το συνέδριο από τις ομάδες με τις οποίες συνεργάζομαι. Και με όλες τις ομάδες με τις οποίες συνεργάζομαι, χρησιμοποιούμε αυτήν την πρακτική.
Γιατί; Φυσικά, θα ήταν υπέροχο αν κάθε προγραμματιστής είχε μια εικονική μηχανή που θα λειτουργούσε 24/7. Αλλά ίσως αυτό είναι νέα για εσάς, ίσως δεν δώσατε προσοχή, αλλά ο ίδιος ο προγραμματιστής δεν λειτουργεί 24/7. Ένας προγραμματιστής εργάζεται συνήθως 8 ώρες την ημέρα. Ακόμα κι αν έρθει νωρίς στη δουλειά, έχει ένα μεγάλο γεύμα κατά το οποίο πηγαίνει στο γυμναστήριο. Ας είναι 12 ώρες την ημέρα όταν ο προγραμματιστής χρησιμοποιεί πραγματικά αυτούς τους πόρους. Σύμφωνα με τη νομοθεσία μας, έχουμε 5 στις 7 ημέρες την εβδομάδα που θεωρούνται εργάσιμες.
Κατά συνέπεια, τις καθημερινές αυτό το μηχάνημα δεν πρέπει να λειτουργεί 24 ώρες, αλλά μόνο 12, και τα Σαββατοκύριακα αυτό το μηχάνημα δεν πρέπει να λειτουργεί καθόλου. Φαίνεται ότι όλα είναι πολύ απλά, αλλά τι είναι σημαντικό να πούμε εδώ; Εφαρμόζοντας αυτήν την απλή πρακτική σε αυτό το βασικό πρόγραμμα, σας επιτρέπει να μειώσετε το κόστος συντήρησης αυτών των περιβαλλόντων κατά 70%, δηλαδή πήρατε την τιμή του προγραμματιστή, του QA, του demo, του περιβάλλοντος και το διαιρέσατε με το 3.
Το ερώτημα είναι τι να κάνουμε με τα υπόλοιπα χρήματα; Για παράδειγμα, οι προγραμματιστές θα πρέπει να αγοράσουν το ReSharper αν δεν το έχουν ήδη κάνει. Ή κάντε ένα κοκτέιλ πάρτι. Εάν είχατε προηγουμένως ένα περιβάλλον στο οποίο βοσκούσαν τόσο ο dev όσο και το QA, και αυτό ήταν όλο, τώρα μπορείτε να φτιάξετε 3 διαφορετικά που θα είναι απομονωμένα και οι άνθρωποι δεν θα παρεμβαίνουν μεταξύ τους.
Σχετικά με τη διαφάνεια με συνεχή μέτρηση απόδοσης, πώς μπορούμε να συγκρίνουμε την απόδοση αν είχαμε 1 εγγραφές στη βάση δεδομένων στο έργο, δύο μήνες μετά υπάρχουν ένα εκατομμύριο; Πώς να καταλάβετε γιατί και ποιο είναι το νόημα της μέτρησης της απόδοσης;
Αυτή είναι μια καλή ερώτηση, γιατί θα πρέπει πάντα να μετράτε την απόδοση στους ίδιους πόρους. Δηλαδή, ανοίγετε νέο κώδικα, μετράτε την απόδοση στον νέο κώδικα. Για παράδειγμα, πρέπει να δοκιμάσετε διαφορετικά σενάρια απόδοσης, ας υποθέσουμε ότι θέλετε να δοκιμάσετε την απόδοση της εφαρμογής σε ελαφρύ φορτίο, όπου υπάρχουν 1 χρήστες και το μέγεθος της βάσης δεδομένων είναι 000 gigabyte. Το μέτρησες και πήρες τους αριθμούς. Στη συνέχεια παίρνουμε ένα άλλο σενάριο. Για παράδειγμα, 5 χρήστες, μέγεθος βάσης δεδομένων 5 terabyte. Λάβαμε τα αποτελέσματα και τα θυμηθήκαμε.
Τι είναι σημαντικό εδώ; Το σημαντικό εδώ είναι ότι ανάλογα με το σενάριο, τον όγκο των δεδομένων, τον αριθμό των ταυτόχρονων χρηστών κ.λπ., μπορεί να συναντήσετε ορισμένα όρια. Για παράδειγμα, στο όριο μιας κάρτας δικτύου ή στο όριο ενός σκληρού δίσκου ή στο όριο των δυνατοτήτων του επεξεργαστή. Αυτό είναι που είναι σημαντικό να καταλάβετε. Σε διαφορετικά σενάρια αντιμετωπίζετε ορισμένα όρια. Και πρέπει να καταλαβαίνεις τους αριθμούς όταν τους χτυπάς.
Μιλάμε για μέτρηση απόδοσης σε ειδικό περιβάλλον δοκιμής; Δηλαδή αυτό δεν είναι παραγωγή;
Ναι, αυτό δεν είναι παραγωγή, αυτό είναι ένα περιβάλλον δοκιμής, το οποίο είναι πάντα το ίδιο για να μπορείτε να το συγκρίνετε με προηγούμενες μετρήσεις.
Κατανοητό ευχαριστώ!
Αν δεν υπάρχουν ερωτήσεις, νομίζω ότι μπορούμε να τελειώσουμε. Ευχαριστώ!
Πηγή: www.habr.com