Εάν η εταιρεία σας απλώς εφαρμόζει εργαλεία DevOps ή CI/CD, ίσως σας φανεί χρήσιμο να εξοικειωθείτε με τα πιο συνηθισμένα λάθη, ώστε να μην τα επαναλάβετε και να πατήσετε στη γκανιότα κάποιου άλλου.
Ομάδα μετέφρασε το άρθρο .
Απροθυμία αλλαγής κουλτούρας και διαδικασιών
Κοιτάζοντας το διάγραμμα κύκλου , είναι σαφές ότι στις πρακτικές DevOps, η δοκιμή είναι μια συνεχής εργασία, ένα θεμελιώδες μέρος κάθε μεμονωμένης ανάπτυξης.
Διάγραμμα ατελείωτου κύκλου DevOps
Οι δοκιμές και η διασφάλιση ποιότητας κατά την ανάπτυξη και την παράδοση αποτελούν ουσιαστικό μέρος όλων όσων κάνουν οι προγραμματιστές. Αυτό απαιτεί μια αλλαγή νοοτροπίας για να περιλαμβάνει δοκιμές σε κάθε εργασία.
Οι δοκιμές γίνονται μέρος της καθημερινής εργασίας κάθε μέλους της ομάδας. Η μετάβαση σε συνεχείς δοκιμές δεν είναι εύκολη, πρέπει να είστε προετοιμασμένοι για αυτό.
Έλλειψη ανατροφοδότησης
Η αποτελεσματικότητα του DevOps εξαρτάται από τη συνεχή ανατροφοδότηση. Η συνεχής βελτίωση δεν είναι δυνατή αν δεν υπάρχει χώρος για συνεργασία και επικοινωνία.
Οι εταιρείες που δεν διοργανώνουν αναδρομικές συναντήσεις δυσκολεύονται να εφαρμόσουν μια κουλτούρα συνεχούς ανατροφοδότησης στο CI/CD. Στο τέλος κάθε επανάληψης πραγματοποιούνται αναδρομικές συναντήσεις, όπου τα μέλη της ομάδας συζητούν τι πήγε καλά και τι πήγε στραβά. Οι αναδρομικές συναντήσεις είναι το θεμέλιο του Scrum/Agile, αλλά είναι επίσης απαραίτητες για τα DevOps.
Αυτό συμβαίνει επειδή οι αναδρομικές συναντήσεις ενσταλάζουν τη συνήθεια της ανταλλαγής σχολίων και απόψεων. Μία από τις πιο σημαντικές στιγμές στην αρχή είναι η διοργάνωση επαναλαμβανόμενων ρετρό συναντήσεων ώστε να γίνουν κατανοητές και οικεία σε όλη την ομάδα.
Όσον αφορά την ποιότητα του λογισμικού, όλα τα μέλη της ομάδας είναι υπεύθυνα για τη διατήρησή του. Για παράδειγμα, οι προγραμματιστές μπορούν να γράφουν δοκιμές μονάδων καθώς και κώδικα έχοντας κατά νου τη δυνατότητα δοκιμής, συμβάλλοντας στον μετριασμό του κινδύνου από την αρχή.
Ένας εύκολος τρόπος για να αντικατοπτρίσετε τις μεταβαλλόμενες αντιλήψεις για τις δοκιμές είναι να καλέσετε τους ελεγκτές όχι QA αλλά ελεγκτή λογισμικού ή μηχανικό ποιότητας. Αυτή η αλλαγή μπορεί να φαίνεται πολύ απλή ή ακόμα και ανόητη. Αλλά το να αποκαλούμε κάποιον "ειδικό διασφάλισης ποιότητας λογισμικού" δίνει τη λανθασμένη ιδέα για το ποιος είναι υπεύθυνος για την ποιότητα του προϊόντος. Στις πρακτικές Agile, CI/CD και DevOps, όλοι είναι υπεύθυνοι για την ποιότητα του λογισμικού.
Ένα άλλο σημαντικό σημείο είναι η κατανόηση του τι σημαίνει ποιότητα για όλη την ομάδα και κάθε μέλος, οργανισμό, ενδιαφερόμενα μέρη της.
Παρανόηση ολοκλήρωσης σκηνής
Εάν η ποιότητα είναι μια συνεχής και κοινή διαδικασία, απαιτείται κοινή κατανόηση της ολοκλήρωσης ενός σταδίου. Πώς να καταλάβετε ότι το στάδιο τελείωσε; Τι συμβαίνει όταν ένα ορόσημο επισημαίνεται ως ολοκληρωμένο σε έναν πίνακα Trello ή σε άλλο πίνακα kanban;
Ο προσδιορισμός ενός ολοκληρωμένου ορόσημου (DoD) είναι ένα ισχυρό εργαλείο στο πλαίσιο του CD DevOps/CI. Βοηθά στην καλύτερη κατανόηση των προτύπων ποιότητας του τι και πώς χτίζει η ομάδα.
Η ομάδα ανάπτυξης πρέπει να αποφασίσει τι σημαίνει "Τέλος". Πρέπει να καθίσουν και να φτιάξουν μια λίστα με τα χαρακτηριστικά που πρέπει να πληρούνται σε κάθε στάδιο, ώστε να μπορεί να θεωρηθεί ολοκληρωμένη.
Το Υπουργείο Εξωτερικών καθιστά τη διαδικασία πιο διαφανή και διευκολύνει την εφαρμογή του CI / CD, εάν είναι σαφές σε όλα τα μέλη της ομάδας και συμφωνηθεί από κοινού.
Έλλειψη ρεαλιστικών, σαφώς καθορισμένων στόχων
Αυτή είναι μια από τις πιο συχνά αναφερόμενες συμβουλές, αλλά αξίζει να επαναληφθεί. Για να πετύχει οποιοδήποτε σοβαρό εγχείρημα, συμπεριλαμβανομένης της εφαρμογής CI/CD ή DevOps, πρέπει να θέσετε ρεαλιστικούς στόχους και να μετρήσετε την απόδοση σε σχέση με αυτούς. Τι προσπαθείτε να πετύχετε με το CI/CD; Επιτρέπει πιο γρήγορες εκδόσεις με καλύτερη ποιότητα;
Τυχόν στόχοι που τίθενται πρέπει να είναι όχι μόνο διαφανείς και ρεαλιστικοί, αλλά και συνεπείς με τις τρέχουσες δραστηριότητες της εταιρείας. Για παράδειγμα, πόσο συχνά χρειάζονται οι πελάτες σας νέες ενημερώσεις κώδικα ή εκδόσεις; Δεν χρειάζεται να υπερφορτώνετε τις διεργασίες και να απελευθερώνετε πιο γρήγορα εάν δεν υπάρχει πρόσθετο όφελος για τους χρήστες.
Επίσης, δεν χρειάζεται πάντα να εφαρμόζετε και CD και CI. Για παράδειγμα, εταιρείες με υψηλή ρύθμιση, όπως τράπεζες και ιατρικές κλινικές, μπορούν να συνεργάζονται μόνο με CI.
Το CI είναι ένα καλό σημείο εκκίνησης για κάθε εταιρεία που εφαρμόζει DevOps. Όταν εφαρμόζεται σε μια εταιρεία, οι προσεγγίσεις για την παράδοση λογισμικού αλλάζουν σημαντικά. Μόλις κατακτήσετε το CI, μπορείτε να σκεφτείτε τη βελτίωση της όλης διαδικασίας, την αύξηση της ταχύτητας διάθεσης και άλλες αλλαγές.
Για πολλούς οργανισμούς, ένα CI είναι αρκετό και το CD θα πρέπει να εφαρμόζεται μόνο εάν προσθέτει αξία.
Έλλειψη σχετικών πινάκων ελέγχου και μετρήσεων
Αφού ορίσετε στόχους, η ομάδα ανάπτυξης μπορεί να δημιουργήσει έναν πίνακα ελέγχου για τη μέτρηση των KPI. Πριν από την ανάπτυξή του, αξίζει τον κόπο να αξιολογηθούν οι παράμετροι που θα παρακολουθούνται.
Διαφορετικές αναφορές και εφαρμογές είναι χρήσιμες για διαφορετικά μέλη της ομάδας. Οι Scrum Master ασχολούνται περισσότερο με το status και την εμβέλεια. Ενώ η ανώτερη διοίκηση μπορεί να ενδιαφέρεται για το ποσοστό εξουθένωσης των ειδικών.
Ορισμένες ομάδες χρησιμοποιούν επίσης πίνακες εργαλείων με κόκκινες, κίτρινες και πράσινες ενδείξεις για να αξιολογήσουν την κατάσταση του CI / CD, για να καταλάβουν εάν τα κάνουν όλα σωστά ή αν έχει συμβεί κάποιο σφάλμα. Το κόκκινο σημαίνει ότι πρέπει να προσέξεις τι συμβαίνει.
Ωστόσο, εάν οι πίνακες εργαλείων δεν είναι τυποποιημένοι, μπορεί να είναι παραπλανητικοί. Αναλύστε ποια δεδομένα χρειάζεται ο καθένας και στη συνέχεια δημιουργήστε μια τυποποιημένη περιγραφή του τι σημαίνει. Μάθετε τι είναι πιο λογικό για τους ενδιαφερόμενους: γραφικά, κείμενο ή αριθμούς.
Έλλειψη χειροκίνητων δοκιμών
Ο αυτοματισμός δοκιμής θέτει τα θεμέλια για έναν καλό αγωγό CI/CD. Αλλά η αυτοματοποιημένη δοκιμή σε όλα τα στάδια δεν σημαίνει ότι δεν πρέπει να κάνετε χειροκίνητη δοκιμή.
Για την κατασκευή ενός αποτελεσματικού αγωγού CI/CD, απαιτούνται επίσης χειροκίνητες δοκιμές. Θα υπάρχουν πάντα ορισμένες πτυχές των δοκιμών που απαιτούν ανθρώπινη ανάλυση.
Αξίζει να εξεταστεί το ενδεχόμενο ενσωμάτωσης των προσπαθειών χειροκίνητων δοκιμών στον αγωγό. Μόλις ολοκληρωθεί η μη αυτόματη δοκιμή ορισμένων δοκιμών, μπορείτε να προχωρήσετε στη φάση ανάπτυξης.
Μην προσπαθείτε να βελτιώσετε τις δοκιμές
Ένας αποτελεσματικός αγωγός CI/CD απαιτεί πρόσβαση στα σωστά εργαλεία, είτε πρόκειται για διαχείριση δοκιμών είτε για ενοποίηση και συνεχή παρακολούθηση.
Η δημιουργία μιας ισχυρής, προσανατολισμένης στην ποιότητα κουλτούρας έχει ως στόχο να , παρακολουθήστε την εμπειρία των πελατών μετά την ανάπτυξη και παρακολουθήστε τις βελτιώσεις.
Ακολουθούν μερικές πρακτικές συμβουλές που μπορείτε εύκολα να εφαρμόσετε:
- Βεβαιωθείτε ότι οι δοκιμές είναι εύκολες στη γραφή και αρκετά ευέλικτες ώστε να μην σπάνε κατά την ανακατασκευή του κώδικα.
- Οι ομάδες ανάπτυξης θα πρέπει να περιλαμβάνονται στη διαδικασία δοκιμών - δείτε μια λίστα με ζητήματα και αιτήματα χρηστών που είναι σημαντικό να ελέγχονται κατά τη διάρκεια των αγωγών CI.
- Μπορεί να μην έχετε πλήρη κάλυψη δοκιμών, αλλά πάντα βεβαιωθείτε ότι ελέγχονται οι ροές που είναι σημαντικές για το UX και την εμπειρία των πελατών.
Τελευταίο αλλά εξίσου σημαντικό σημείο
Η μετάβαση στο CI/CD ξεκινά συνήθως από κάτω προς τα πάνω, αλλά τελικά, είναι ένας μετασχηματισμός που απαιτεί τη συμμετοχή της διοίκησης, χρόνου και πόρων από την εταιρεία. Εξάλλου, το CI / CD είναι ένα σύνολο δεξιοτήτων, διαδικασιών, εργαλείων και πολιτισμικής αναδιάρθρωσης, τέτοιες αλλαγές μπορούν να εφαρμοστούν μόνο συστηματικά.
Τι άλλο να διαβάσετε για το θέμα:
- .
- .
- .
Πηγή: www.habr.com