Όταν πρόκειται για την παράδοση scrum, οι άνθρωποι συνήθως περιμένουν μια εκτέλεση έκδοσης μετά το τέλος ενός sprint. Αυτό σημαίνει αμέσως μετά από μια επιτυχημένη επίδειξη παρουσίασης στον πελάτη.
Αλλά πάντα αναρωτιόμουν πώς θα μπορούσε να είναι μια τόσο αυτόματη προσδοκία. Ειδικά αν σκεφτείτε τις παρακάτω πιθανές δραστηριότητες που πρέπει να συμβούν πριν ή παράλληλα.
- Αναπτύξτε και ολοκληρώστε όλες τις ιστορίες στο σπριντ. Κάποιες μπορεί να ολοκληρωθούν νωρίτερα, αλλά τις περισσότερες φορές, οι ιστορίες ολοκληρώνονται λίγο πριν το τέλος του σπριντ. Ίσως και μετά την παρουσίαση επίδειξης, να είναι ανοιχτό εδώ.
- Πραγματοποιήστε όλες τις προγραμματισμένες δοκιμές στο περιεχόμενο sprint για να βεβαιωθείτε ότι ο κώδικας που θα κυκλοφορήσει είναι έτοιμος για παραγωγή.
- Ενημερωθείτε για σφάλματα που εντοπίστηκαν και διορθώστε τα εγκαίρως πριν από την κυκλοφορία.
- Βεβαιωθείτε ότι ο αγωγός ανάπτυξης είναι ενημερωμένος με το πιο πρόσφατο περιεχόμενο και ότι ο ίδιος ο αγωγός είναι αξιόπιστος στην εκτέλεση.
- Εκτελέστε τη διοχέτευση σε όλα τα σχετικά περιβάλλοντα για να τα φέρετε στην πιο πρόσφατη κατάσταση από άποψη κώδικα και δεδομένων.
- Προετοιμάστε σημειώσεις έκδοσης και επικοινωνήστε με τον πελάτη για τον αντίκτυπο της κυκλοφορίας και τι ακριβώς θα αλλάξει στη συνέχεια.
- Εάν είναι απαραίτητο, συγχρονίστε με άλλες παράλληλες ομάδες scrum για να διασφαλίσετε ότι το εξαρτημένο περιεχόμενο θα κυκλοφορήσει ταυτόχρονα. Δεν πρέπει να λείπει τίποτα για να διασφαλίσετε ότι το περιεχόμενο κυκλοφορίας σας θα λειτουργεί όπως αναμένεται.
- Πάνω από όλα αυτά, περάστε από όλες τις τελετές scrum. Δεν σχετίζεται μόνο με το τρέχον σπριντ αλλά και με αυτά που στοχεύουν για το επόμενο σπριντ (π.χ. συνεδρίες βελτίωσης ιστοριών).
Τώρα φανταστείτε ότι το σπριντ έχει δύο εβδομάδες.
Οι δραστηριότητες απελευθέρωσης από μόνες τους χρειάζονται χρόνο και ανθρώπους για να ολοκληρωθούν. Αλλά δεν μπορεί να πάρει πάρα πολλά. Αμέσως μετά την τελευταία ημέρα του σπριντ έρχεται κατευθείαν η πρώτη ημέρα του επόμενου σπριντ και ο κύκλος θα ξεκινήσει ξανά.
Εξακολουθεί να φαίνεται τόσο αυτόματη η προσδοκία κυκλοφορίας μετά από κάθε σπριντ;
Πίνακας περιεχομένων
Επεξεργασία περιεχομένου έκδοσης
Εάν όλες οι διεργασίες εντός του σπριντ είναι αυτοματοποιημένες, υπάρχει η δυνατότητα απλώς να «τραβήξετε τη σκανδάλη» και να εγκαταστήσετε την τελευταία έκδοση κώδικα στην παραγωγή στο τέλος κάθε σπριντ. Το πρόβλημα είναι ότι δεν έχω βιώσει ποτέ μια τόσο τέλεια κατάσταση της ομάδας scrum.
Αν όντως συμβαίνει σε ορισμένες μικρές ιδιωτικές επιχειρήσεις, τις ζηλεύω πραγματικά. Αλλά η πραγματικότητα στον εταιρικό κόσμο είναι ότι μια ομάδα scrum δεν θα επιτύχει αυτό το επίπεδο ωριμότητας. Αντίθετα, οι διαδικασίες έκδοσης συνδέονται συνήθως με χρονοβόρες δραστηριότητες που φθάνουν στο μεγαλύτερο μέρος του επόμενου σπριντ, επηρεάζοντας αυτό το σπριντ από το περιεχόμενο και όλες τις προοπτικές μετρήσεων. Η απελευθέρωση είναι απλώς μια αγχωτική πράξη που κανείς στην ομάδα δεν είναι ευτυχής να περάσει.
Έτσι, ανακάλυψα το επόμενο καλύτερο σενάριο για την αντιμετώπιση των κυκλοφοριών.
Το συμπέρασμα ήταν να κάνουμε κάθε δεύτερο σπριντ το Release Sprint. Εδώ είναι τι σημαίνει.
Ξεχωριστή έκδοση κώδικα για την επόμενη κυκλοφορία
Πρόκειται για το χειρισμό ξεχωριστών υποκαταστημάτων στο αποθετήριο GIT. Υπάρχουν πολλοί τρόποι για να προσεγγίσετε το ίδιο πρόβλημα και όλοι μπορούν να είναι επιτυχημένοι. Αλλά για τους σκοπούς αυτού του άρθρου, θα κρατήσω τα πράγματα απλά για να δείξω την προσέγγιση και τον αντίκτυπό της.
Προκειμένου να επηρεαστούν όσο το δυνατόν χαμηλότερα οι συνεχιζόμενες δραστηριότητες ανάπτυξης, είναι σημαντικό να διαχωρίσετε το περιεχόμενο για την επόμενη έκδοση σε ξεχωριστό κλάδο. Ας το ονομάσουμε Release Branch. Με αυτό θα λυθούν τα εξής:
- Η ομάδα ανάπτυξης μπορεί να συνεχίσει τις δραστηριότητες και να συγχωνευθεί στις νέες ιστορίες του κύριου κλάδου χωρίς διακοπή.
- Δεν υπάρχει κίνδυνος να επηρεαστεί το περιεχόμενο της κυκλοφορίας από απροσδόκητες τροποποιήσεις κώδικα από την ομάδα scrum.
- Οι δοκιμαστικές δραστηριότητες μπορούν να εκτελεστούν σε απομονωμένο χώρο. Εδώ, θα εισαχθούν μόνο οι αλλαγές που είναι απαραίτητες για την επίλυση της δοκιμής.
- Δεδομένου ότι ο αγωγός κυκλοφορίας θα αναπτύξει στην παραγωγή μόνο το περιεχόμενο από τον κλάδο κυκλοφορίας, έχουμε σαφή διαδικασία και πλήρη έλεγχο του περιεχομένου που πρόκειται να κυκλοφορήσει. Δεν μπορεί να συμβεί κάποια απροσδόκητη δέσμευση στον κλάδο Git να σπάσει τον ήδη δοκιμασμένο κώδικα.
Επομένως, απλώς κρατήστε το περιεχόμενο της επόμενης έκδοσης στην άκρη και αφήστε το να καταλήξει σε μια σταθερή κατάσταση, έτοιμο για κυκλοφορία.
Time The Releases, ώστε να λειτουργούν επανειλημμένα
Παράτησα τη φιλοδοξία να κάνω την κυκλοφορία μετά την ολοκλήρωση κάθε σπριντ. Ήταν σαφές ότι αυτό δεν θα είχε καμία πιθανότητα να λειτουργήσει. Τουλάχιστον όχι με παρενέργειες όπως:
- επηρεάζοντας το επόμενο περιεχόμενο ανάπτυξης sprint,
- αδυναμία σταθεροποίησης του περιεχομένου κυκλοφορίας,
- κάλυψη όλων των απαιτούμενων δραστηριοτήτων δοκιμών, κ.λπ.
Ο στόχος λοιπόν ήταν να εκτελεστεί η κυκλοφορία μέχρι το τέλος κάθε δεύτερου σπριντ. Αυτό θα σήμαινε τα εξής:
- Μια κυκλοφορία θα περιέχει πάντα ιστορίες από τα δύο τελευταία σπριντ που έχουν ήδη τελειώσει. Εφόσον η κυκλοφορία πραγματοποιείται εντός του τρέχοντος (ενεργό σπριντ), αυτό το περιεχόμενο σπριντ δεν περιλαμβάνεται ακόμη στην έκδοση.
- Υπάρχει ένας ολόκληρος χρόνος ενός σπριντ για να ολοκληρωθούν οι απαραίτητες δοκιμαστικές δραστηριότητες και οι διορθώσεις σφαλμάτων.
- Ο κάτοχος κυκλοφορίας έχει αρκετό χρόνο για να συγκεντρώσει πληροφορίες σχετικές με την κυκλοφορία (δοκιμές, σημειώσεις έκδοσης κ.λπ.) με το σπριντ μη κυκλοφορίας. Με αυτόν τον τρόπο, μπορούν να λειτουργήσουν βασικά αυτόνομα και να κρατήσουν την υπόλοιπη ομάδα ανάπτυξης να εργάζεται σε νέες ιστορίες.
- Σε περίπτωση εντοπισμού σφαλμάτων, ο κάτοχος της έκδοσης μπορεί να συνδεθεί γρήγορα με τον προγραμματιστή για να διορθώσει το πρόβλημα και να επιστρέψει στο τρέχον περιεχόμενο sprint. Επομένως, θα πρέπει πάντα να διατίθεται κάποιο ποσοστό χρόνου από την ικανότητα της ομάδας για την υποστήριξη αυτής της διόρθωσης σφαλμάτων. Πόσο ακριβώς μπορεί να ανακαλυφθεί με την πάροδο του χρόνου.
Είναι σαφές ότι οι χρήστες δεν θα λάβουν το πιο πρόσφατο περιεχόμενο sprint στην τελευταία έκδοση. Αλλά με την πάροδο του χρόνου, αυτό θα γίνει άσχετο. Θα λάβουν δύο σπριντ περιεχομένου με κάθε επόμενη κυκλοφορία ούτως ή άλλως, μετά από κάθε δεύτερο σπριντ.
Αυτό φαίνεται σαν ένας καλός συμβιβασμός μεταξύ της ικανοποίησης ταχείας παράδοσης και της παρακολούθησης των δραστηριοτήτων scrum χωρίς σημαντική ενόχληση.
Εκτελέστε την ανάπτυξη απελευθέρωσης
Όταν οι δραστηριότητες δοκιμών, επιδιόρθωσης σφαλμάτων και ετοιμότητας αγωγών ολοκληρωθούν με επιτυχία, είναι μια αρκετά απλή διαδικασία να εκτελεστεί ο αγωγός παραγωγής και να ολοκληρωθεί η κυκλοφορία στην παραγωγή.
Δεδομένου ότι αναπτύσσεται από έναν αυτόνομο κλάδο, αυτό μπορεί βασικά να είναι μια απαρατήρητη και αόρατη δραστηριότητα. Κανείς δεν χρειάζεται να ξέρει. Εάν συμβαίνει αυτό, είναι η καλύτερη δυνατή υλοποίηση της ανάπτυξης απελευθέρωσης.
Απαραίτητη προϋπόθεση για αυτό είναι να έχετε δημιουργήσει μια σταθερή αυτοματοποιημένη διοχέτευση DevOps. Δεν χρησιμοποιείται μόνο για την ανάπτυξη στο περιβάλλον παραγωγής αλλά και σε όλα τα άλλα περιβάλλοντα χαμηλότερου επιπέδου. Αυτό μπορεί να περιλαμβάνει dev, sandbox, δοκιμή, διασφάλιση ποιότητας, περιβάλλον απόδοσης κ.λπ. Αυτό θα είναι ένα κλικ για την ανάπτυξη όλων των λύσεων για κάθε περιβάλλον.
Η απελευθέρωση δεν πρέπει να είναι σημείο πόνου ή άγχος. Ή ένας εφιάλτης που όλοι φοβούνται και συνεχίζουν να προετοιμάζονται για εκείνη την ημέρα για μια εβδομάδα. Όχι – αντ’ αυτού, αν κανείς δεν το προσέξει ποτέ, αυτό είναι το καλύτερο σημάδι μιας επιτυχημένης κυκλοφορίας.
Συγχωνεύστε ξανά τον κλάδο έκδοσης στον κλάδο ανάπτυξης
Το Release Branch περιέχει πλέον κάποιο ειδικό περιεχόμενο που δεν υπάρχει στον κανονικό κλάδο συνεχούς ανάπτυξης. Σχετίζεται με όλες τις επιδιορθώσεις που εφαρμόστηκαν κατά την περίοδο δοκιμών. Αυτό το περιεχόμενο πρέπει να συγχωνευθεί ξανά στον κλάδο ανάπτυξης για να διασφαλιστεί ότι οι διορθώσεις θα παραμείνουν εκεί ακόμα και μετά την επόμενη κυκλοφορία.
Σε εκείνο το σημείο, το πιο πρόσφατο Release Branch χρησιμεύει ως κωδικός παραγωγής έτοιμου για αναδιάταξη έκτακτης ανάγκης. Εάν ένα επείγον ζήτημα υψηλής προτεραιότητας πρέπει να επιλυθεί αμέσως μετά την ανάπτυξη της παραγωγής, μπορεί να χρησιμοποιήσει αυτόν τον κλάδο. Είναι απλό να πάρετε αυτόν τον κώδικα και να εφαρμόσετε την επιδιόρθωση μέσα. Αυτό εξακολουθεί να είναι το ακριβές αντίγραφο του τρέχοντος κώδικα παραγωγής χωρίς νέο περιεχόμενο που δεν έχει κυκλοφορήσει.
Τέλος, μόλις ξεκινήσει η νέα περίοδος δοκιμής, ο κλάδος της προηγούμενης έκδοσης μπορεί να διαγραφεί και να αντικατασταθεί από έναν νέο. Το νέο δημιουργείται ξανά ως αντίγραφο από τον τρέχοντα κλάδο ανάπτυξης.
Καθιερώστε τακτικές εκδόσεις
Και τώρα το έχουμε 😀—μια σταθερή διαδικασία για την προσέγγιση της κυκλοφορίας. Το μόνο που λείπει είναι να δεσμευτείτε να το διατηρήσετε τακτικά. Σε αυτή την περίπτωση, μετά από κάθε δεύτερο σπριντ.
Διατηρώντας το τακτικό, ουσιαστικά θέτουμε το έδαφος για να το κάνουμε ευκολότερο, κυρίως επειδή:
- Εάν η κυκλοφορία γίνει μετά από όχι πολύ μεγάλο χρονικό διάστημα, δεν υπάρχει τόσο πολύ νέο περιεχόμενο για εγκατάσταση στην παραγωγή. Η αύξηση είναι μικρή και θεωρείται σταθερή.
- Τώρα τόσο νέο περιεχόμενο δεν σημαίνει ότι δεν υπάρχουν πολλές δραστηριότητες δοκιμών και δημιουργία δοκιμαστικών περιπτώσεων. Λιγότερες επικοινωνίες, κλήσεις συμφωνίας και συνεργασία με τους ενδιαφερόμενους σχετικά με το τι χρειάζεται να επικυρωθεί εκ νέου. Θα συμφωνήσουν επίσης ότι δεν έχει περάσει πολύς καιρός από την τελευταία κυκλοφορία. Έτσι δίνεται λιγότερη σημασία σε αυτή τη δράση.
- Η ομάδα θα συνηθίσει σε αυτόν τον κύκλο. με τον καιρό, θα είναι φυσικό μέρος της ομάδας.
- Ως παρενέργεια, τα περιβάλλοντα ανάπτυξης και δοκιμών ανανεώνονται συχνά τα δεδομένα. Αυτό είναι ούτως ή άλλως απαραίτητο για κάθε νέο κύκλο δοκιμών. Επομένως, δεν θα είναι απλώς μια άλλη προγραμματισμένη δραστηριότητα. Μάλλον μια ενέργεια που είναι ήδη μέρος της καθιερωμένης διαδικασίας. Αυτή η αλλαγή προοπτικής έχει τόσο μεγάλη επιρροή στην ατμόσφαιρα της ομάδας. Δεν θα το πίστευε κανείς.
συμπέρασμα
Αυτό το κεφάλαιο ολοκληρώνει τις προηγούμενες αναρτήσεις μου σχετικά με το θέμα του κύκλου ζωής του scrum. Επίσης, πρόκειται για αυτό που αποδείχθηκε ότι λειτουργεί στην πραγματική ζωή.
Συχνά, οι ομάδες ξεκινούν με ευέλικτο τρόπο και κάνουν πολλά πράγματα λάθος. Μετά εξελίσσονται, τελικά, και αρχίζουν να κάνουν τα πράγματα διαφορετικά. Αυτή η σειρά θα μπορούσε να βοηθήσει ορισμένους από αυτούς να κάνουν αυτή την αλλαγή πιο γρήγορα.
Ούτε αυτή η προσέγγιση έκδοσης είναι η μόνη εφαρμόσιμη, ούτε είναι χωρίς προβλήματα. Αυτά θα υπάρχουν ακόμα και οι ομάδες πρέπει να τα αντιμετωπίσουν. Μετά βελτιώστε ό,τι είναι δυνατό και ξεχάστε αυτό που δεν έχει νόημα.
Αλλά από ό,τι ξέρω, αυτή η προσέγγιση, αν και απλή, απέδειξε ότι η αλλαγή είναι δυνατή. Από χαοτικά, απρόβλεπτα σπριντ μέχρι πιο σταθερή παράδοση με κανονικές κυκλοφορίες στις οποίες μπορεί κανείς να βασιστεί και να σχεδιάσει. Και δεν απαιτεί ειδική, πολύ περίπλοκη μεθοδολογία – απλώς απλούς κανόνες και προθυμία να ακολουθήσετε το σχέδιο.