Για την έκδοση που βασίζεται σε υποκαταστήματα, πρέπει να μιλήσουμε για το ακόλουθο διάγραμμα, το οποίο απεικονίζει τέλεια το πανόραμα της διαδικασίας διαχείρισης διαμόρφωσης. Πρώτα απ 'όλα, αυτό το διάγραμμα είναι γραμμένο με βάση το μοντέλο Git, αλλά στην πραγματικότητα, το Git και το Subversion έχουν καταλάβει την έννοια της διαχείρισης ελέγχου έκδοσης, αλλά το Git κάνει ένα ποιοτικό άλμα προς τα εμπρός από το Subversion στη διαχείριση υποκαταστημάτων και την κατανεμημένη απόδοση (αλλά αυτό δεν είναι το επίκεντρο αυτού του άρθρου).
Πριν εισαγάγουμε την αρχή αυτού του γραφήματος, ας μιλήσουμε για δύο διαφορετικές στρατηγικές για τον γενικό έλεγχο εκδόσεων, η μία είναι "πρωτοποριακή ραχοκοκαλιά, σταθερός κλάδος" και η άλλη είναι "σταθερή ραχοκοκαλιά, πρωτοπόρος κλάδος". Όπως υποδηλώνει το όνομα, είναι η σταθερή έκδοση (έκδοση παραγωγής), στον κορμό ή στο κλαδί. Στην περίπτωση των παραδοσιακών ομάδων έργου που χρησιμοποιούν VSS, είναι δύσκολο να πούμε σε ποια λειτουργία ανήκει, κυρίως επειδή η ίδια η VSS δεν έχει στρατηγική διαχείρισης υποκαταστημάτων, έτσι πολλές ομάδες έργου δημιουργούν βιβλιοθήκες δύο εκδόσεων (ή τρεις) αντίστοιχα, που αντιστοιχούν στο περιβάλλον παραγωγής και στο περιβάλλον ανάπτυξης, φυσικά, αυτό είναι επίσης ένα είδος μεταμφιεσμένης διαχείρισης υποκαταστημάτων. Ωστόσο, εάν μεταβείτε στο Subversion ή στο Git ως εργαλείο ελέγχου έκδοσης, οι περισσότερες ομάδες χρησιμοποιούν τη λειτουργία σταθερού κορμού, δηλαδή, ο κορμός (φορτηγό ή κύριος) αντιστοιχεί σε ένα σταθερό περιβάλλον παραγωγής και επισημαίνει διαφορετικές εκδόσεις για να υποδείξει την έκδοση παραγωγής. Προσωπικά, πιστεύω ότι το σταθερό μοτίβο κώδικα κορμού θα πρέπει να είναι η απόλυτη κύρια λύση διαχείρισης ελέγχου έκδοσης κώδικα προς το παρόν. Η παραπάνω εικόνα είναι το τυπικό μοντέλο διαχείρισης «σταθερής ραχοκοκαλιάς».
master: Το αντίστοιχο Subversion είναι φορτηγό。 Αντίστοιχα με την έκδοση παραγωγής, επισημαίνεται μία φορά σε κάθε κυκλοφορία.
Release Branch (γνωστός και ως Integration Branch): Εφόσον η παραγωγή είναι ενημερωμένη, πρέπει πρώτα να συγχωνευθεί στον κλάδο έκδοσης (κλάδος ενοποίησης). Είναι κάπως παρόμοιο με αυτό που η ομάδα του έργου αποκαλεί επί του παρόντος την έννοια της «προπαραγωγής» και του «προσομοιωμένου περιβάλλοντος».
Κλάδος ανάπτυξης (κλάδος ανάπτυξης ή κλάδος ανάπτυξης): Το περιβάλλον που αντιμετωπίζει το αναπτυξιακό περιβάλλον.
κλάδος χαρακτηριστικών (κλάδος χαρακτηριστικών): Ορισμένες ανεξάρτητες λειτουργίες μπορούν να διαχωριστούν από έναν ξεχωριστό κλάδο ανάπτυξης. Αυτό γίνεται κυρίως για να αντιμετωπιστεί το γεγονός ότι ορισμένες λειτουργίες ενδέχεται να χρειαστούν σχετικά μεγάλο χρονικό διάστημα για να ενημερωθούν, ώστε να μην παρασυρθεί προς τα κάτω η έκδοση και οι ξεχωριστοί κλάδοι.
Κλάδος επειγουσών επιδιορθώσεων (κλάδος επιδιόρθωσης σφαλμάτων): Το σφάλμα εδώ είναι κυρίως ένα σφάλμα παραγωγής.
Μετά την εισαγωγή του κορμού και των κλαδιών, πρέπει να παρουσιάσω την κατεύθυνση της δημιουργίας και της συγχώνευσης αυτών των κλαδιών.
Το Master είναι η έκδοση παραγωγής και ο κορμός δέχεται μόνο δύο κλάδους για συγχώνευση, ο ένας είναι ο κλάδος έκδοσης (κλάδος ενοποίησης) και ο άλλος είναι ο κλάδος επειγουσών επιδιορθώσεων. Κανένας άλλος κλάδος δεν μπορεί να συγχωνευθεί σε κλάδο παραγωγής.
Ο κλάδος απελευθέρωσης δημιουργείται αρχικά ταυτόχρονα με την παραγωγή, που είναι ακριβώς το ίδιο με την παραγωγή. Δέχεται μόνο τον κλάδο dev για να συγχωνευθεί μαζί του. Με άλλα λόγια, δεν δέχεται τη συγχώνευση απευθείας από τον κλάδο χαρακτηριστικών ή τον κλάδο επιδιορθώσεων σφαλμάτων.
Ο κλάδος ανάπτυξης, ο κλάδος ανάπτυξης, όπως και ο κλάδος ολοκλήρωσης, είναι ο ίδιος με το περιβάλλον παραγωγής σε μια συγκεκριμένη χρονική στιγμή. Ωστόσο, καθώς προχωρά η ανάπτυξη, θα συνεχίσουν να δημιουργούνται νέες δυνατότητες στον κλάδο προγραμματιστών. Η θεωρία dev δέχεται μόνο τη συγχώνευση δύο κλάδων, ο ένας είναι επείγουσες επιδιορθώσεις και ο άλλος είναι ο κλάδος χαρακτηριστικών.
Feature Branch, ξεκινώντας από ένα συγκεκριμένο σημείο (έκδοση) με τον κλάδο Dev, ο κλάδος Feature θα συγχωνευθεί τελικά με τον κλάδο Dev.
Ας παρουσιάσουμε εν συντομία τη μέθοδο ελέγχου έκδοσης με τη μορφή σεναρίου
Ας υποθέσουμε ότι μια έκδοση παραγωγής χωρίζεται σε κλάδους (dev, επείγουσες επιδιορθώσεις, έκδοση) και αυτή τη στιγμή, ο προγραμματιστής αρχίζει να αναπτύσσει συνολικά δέκα συναρτήσεις. Όταν αναπτύχθηκαν 8 από τις 10 δυνατότητες, η ομάδα δοκιμών άρχισε να παρεμβαίνει για εσωτερικές δοκιμές και ο διαχειριστής διαμόρφωσης ανέπτυξε τον κλάδο dev στο περιβάλλον προγραμματιστή για δοκιμή μέσω εργαλείων συνεχούς ενοποίησης (ένα ξεχωριστό θέμα εδώ). Όταν η δοκιμαστική επαλήθευση διαπίστωσε ότι δύο από τις λειτουργίες ήταν εντελώς απαράδεκτες και έπρεπε να επαναληφθούν, όπως η απλή ασφάλιση ασφάλισης και η επιστροφή απαίτησης, δύο κλάδοι χαρακτηριστικών διαχωρίστηκαν από τον προγραμματιστή, που αντιστοιχούν στην απλή ασφάλιση ασφάλισης και την επιστροφή χρημάτων αξίωσης, και στον κλάδο προγραμματιστή, ο αντίστοιχος κωδικός έπρεπε επίσης να επαναφερθεί (χειροκίνητη λειτουργία εδώ). Όταν η ομάδα δοκιμής διαπιστώσει ότι δεν υπάρχει πρόβλημα με τη δοκιμή διακλάδωσης προγραμματιστή, πληροί τις προϋποθέσεις του UAT, επομένως ο διαχειριστής διαμόρφωσης συγχωνεύει τον κλάδο προγραμματιστή στον κλάδο έκδοσης και, στη συνέχεια, χρησιμοποιεί εργαλεία συνεχούς ενοποίησης για να δημοσιεύσει αυτόν τον κλάδο στο περιβάλλον προπαραγωγής και να τον παραδώσει στον χρήστη για δοκιμή. Όταν η επαλήθευση χρήστη εντοπίσει ένα πρόβλημα, ο προγραμματιστής τροποποιεί τον κλάδο dev και, στη συνέχεια, τον συγχωνεύει στον κλάδο έκδοσης (εδώ, στην αρχική εικόνα, τροποποιείται απευθείας στον κλάδο έκδοσης, νομίζω ότι αυτό δεν είναι καλό, συνιστώ στον προγραμματιστή να αντιμετωπίσει μόνο τον κλάδο dev), όταν η διαδικασία επαλήθευσης έκδοσης επαλήθευσης ανακαλύπτει ξαφνικά ότι υπάρχει ένα σοβαρό σφάλμα στο περιβάλλον κατασκευής που πρέπει να διορθωθεί αμέσως, τότε τροποποιείται επειγόντως στον κλάδο επειγουσών επιδιορθώσεων και ξεκινά επειγόντως αφού επαληθευτεί ότι είναι σωστό. Ταυτόχρονα, ο κλάδος επειγουσών επιδιορθώσεων συγχωνεύεται με τον dev (εδώ είναι ως επί το πλείστον χειροκίνητος, επειδή αυτή τη στιγμή η έκδοση παραγωγής είναι ήδη πολύ διαφορετική από την έκδοση dev και συχνά είναι αδύνατο να ολοκληρωθεί η αυτόματη συγχώνευση) και στη συνέχεια ο dev συγχωνεύεται στην έκδοση. Μετά από κάποιο χρονικό διάστημα, η λειτουργία επιστροφής αξίωσης ενδέχεται να μην χρειάζεται πλέον και πρέπει να ακυρωθεί, επομένως ο κλάδος της δυνατότητας επιστροφής αξίωσης θα διαγραφεί. Ένα άλλο χαρακτηριστικό είναι εύκολο να ασφαλιστεί και έχει αναπτυχθεί και συγχωνευθεί ξανά στον κλάδο προγραμματιστών για να κυκλοφορήσει με την επόμενη διαδικτυακή έκδοση.
Το παραπάνω σενάριο περιλαμβάνει βασικά ανάπτυξη ρουτίνας, αποσυσκευασία, ενημερώσεις έκτακτης ανάγκης και άλλα σενάρια στην καθημερινή διαδικασία ανάπτυξης.
|
Δημοσιεύτηκε στις 8/4/2018 10:25:39 π.μ.
|
|
|
|
