Γρήγοροι και εύκολοι αγωγοί CI/CD με σημασιολογική εκδοχή για οποιαδήποτε γλώσσα ή εργαλείο. Η κυκλοφορία μιας νέας έκδοσης ενός εργαλείου θα πρέπει να είναι βαρετή. Χωρίς τελετή, χωρίς προγραμματισμό συναντήσεων, ακόμη και χωρίς συζήτηση. Θα πρέπει να είναι διαφανής, εύκολη, αξιόπιστη και ακόμη και ενημερωτική - περισσότερα γι 'αυτό αργότερα. Ωστόσο, ως σύμβουλος λογισμικού που βοηθά τις ομάδες να εφαρμόζουν λύσεις DevOps, συχνά διαπιστώνω ότι αυτό δεν συμβαίνει.Αυτό που βρίσκω ποικίλλει άγρια στην ποιότητα, οπότε αντί να σας πω τι δεν μου αρέσει, ας επικεντρωθούμε στο πώς μου αρέσει να δομίζω τους αγωγούς μου για να ενσωματώσω νέα αποθέματα γρήγορα και εύκολα. Για να κατανοήσω την προοπτική μου, θα ήθελα να μοιραστώ πώς οι απόψεις μου σχετικά με το θέμα έχουν εξελιχθεί με την πάροδο των ετών. Επί του παρόντος, εφαρμόζω μια διαδικασία που περιλαμβάνει τη ρύθμιση «LEGO μπλοκ» των αρθρωτών ροών εργασίας με μικρές προσαρμογές, όπως αλλαγές παραμέτρων. Για παράδειγμα, η διαδικασία δημιουργίας για τη βιβλιοθήκη Rust X είναι πιθανότατα περίπου η ίδια με τη βιβλιοθήκη Rust Y, και το foo διακομιστή κόμβου είναι πιθανότατα περίπου το ίδιο με τη γραμμή διακομιστή κόμβου κλπ. Με τα χρόνια, προσπάθησα να συναρμολογήσω εξαρτήματα ανοιχτού κώδικα για να το πετύχω αυτό, αλλά ποτέ δεν βρήκα τον σωστό συνδυασμό. Πρώτα όμως... Συνειδητοποιώ ότι η έκδοση και η απελευθέρωση δεν είναι τα πιο συναρπαστικά θέματα, ωστόσο, είναι ένα πρόβλημα που αντιμετωπίζει κάθε έργο, ακόμη και όταν είναι κωδικοποιημένο (πιθανότατα ιδιαίτερα!). Το να το κάνετε σωστά θα κάνει το έργο σας να φαίνεται πολύ πιο επαγγελματικό και να επικοινωνεί τις αλλαγές στους χρήστες του. Αυτό δημιουργεί περισσότερη εμπιστοσύνη στα έργα σας βοηθώντας τους προγραμματιστές να κατανοήσουν και να υιοθετήσουν νέες αλλαγές με σαφή και συνεπή τρόπο. Στην αρχή... Ήταν το υποπροϊόν των ορόσημων, που επιτεύχθηκαν μέσω μιας σειράς σπριντ, που προγραμματίστηκαν, με την καλύτερη δυνατή ικανότητα του καθενός, σε μια σειρά συναντήσεων προγραμματισμού, όπου το αποκορύφωμα διαλύθηκε και επιλέχθηκαν εργασίες που ήταν άξια. Θα κάναμε το καλύτερο δυνατό για να γράψουμε μια προδιαγραφή ενός σχεδίου και να εκτιμήσουμε έναν αριθμό Fibonacci ή το μέγεθος του T-Shirt, ή στις χειρότερες περιπτώσεις, έναν αριθμό ημερών. Η απελευθέρωση ήταν το αποκορύφωμα αυτής της διαδικασίας. Η παράδοση των παραδοτέων, που αποστέλλονται στους πραγματικούς χρήστες. Ως το αποκορύφωμα αυτής της διαδικασίας, και υψηλό στοίχημα για να το πάρει σωστά, η απελευθέρωση ήταν μια συναισθηματική στιγμή. Το συναρπαστικό; Φοβισμένος ? Ίσως μερικοί που έχετε ενεργοποιήσει έχουν πάρει την καρδιά σας τρέξιμο καθώς θέτουν τις μηχανές σε κίνηση. Υπάρχει επίσης η λεπτομέρεια και το δράμα της απόφασης για έναν αριθμό έκδοσης. Είναι αυτό μια μεγάλη έκδοση; Μια εντελώς νέα έκδοση; Μικρότερη; Patch; Μερικές φορές το μάρκετινγκ υπαγορεύει την έκδοση... 2.0! Σε αυτό το σημείο της καριέρας μου, δεν ήταν σε μεγάλο βαθμό η γνώμη μου που μετράει σε αυτό το θέμα των αριθμών εκδόσεων, και κοιτάζοντας πίσω, πιθανότατα δεν θα έπρεπε να ήταν κανένας (θα δείτε τι εννοώ αργότερα). Δεν ήμουν υπεύθυνος για τις εκδόσεις στην αρχή... Ωστόσο... αυτό δεν θα διαρκέσει για πάντα. σε ανοιχτό κώδικα Σε κάποιο σημείο της καριέρας μου, άρχισα να ενδιαφέρομαι να συνεισφέρω στον ανοιχτό κώδικα. Γενικά, με τη μορφή ενοτήτων npm, καθώς ήμουν πολύ εξοικειωμένος με το Node εκείνη την εποχή. Ήταν η σειρά μου να είμαι υπεύθυνος για τις απελευθερώσεις. Δεν θυμάμαι πώς, ίσως μέσω κάποιου ενημερωτικού δελτίου ή ίσως μέρος της συνάντησης NYC NodeJS που ο Matt Walters και εγώ χρησιμοποιούσαμε για να τρέξουμε μαζί - βρήκα τη βιβλιοθήκη. Η Semantic Release υλοποίησε μια αρχή, την οποία χρησιμοποιούσα ως web developer, του διαχωρισμού των προβλημάτων με βάση τη σημασιολογία. semantic-release Πριν φύγετε και αρχίσετε να χρησιμοποιείτε τη σημασιολογική απελευθέρωση, υπάρχουν μερικοί περιορισμοί που συναντήθηκα με αυτό ... Και θα φτάσω σε αυτούς σε μια στιγμή. Πρώτον, σε υψηλό επίπεδο, η βασική ιδέα που κήρυξε η σημασιολογική απελευθέρωση ήταν ότι θα ακολουθούσατε μια συγκεκριμένη μορφή για τα μηνύματά σας και με βάση τα μηνύματα, η έκδοση θα μπορούσε να υπολογιστεί. Μιλούσε για την αφαίρεση των συναισθημάτων από τις εκδόσεις, καθιστώντας τα ρομποτικά, με βάση αυτό που έχει πράγματι αλλάξει. Αν υπήρχε μια νέα μεγάλη έκδοση έκδοσης - v2 σε v3, για παράδειγμα, αυτό σήμαινε ότι υπήρχε μια ριζική αλλαγή. Για να το δηλώσετε αυτό στο μήνυμά σας, θα πρέπει να συμπεριλάβετε στο σώμα της επιτροπής. BREAKING CHANGE: feat: revamp user auth flow BREAKING CHANGE: Per Chad's "game-changer" vision in the 3am Slack rant, we've ditched the old auth system for a blockchain-based solution because "passwords are so 2024." Update your clients or enjoy the 500 errors! Μικρές ανατροπές έκδοσης, όπως v2.0.0 έως v2.1.0, σήμαιναν ότι προστέθηκε ένα νέο χαρακτηριστικό. feat: add dark mode toggle Per the 47-comment thread in the "urgent" ticket, users can now save their retinas. Dark mode added, but brace for the inevitable "make it darker" feedback. Οι εκδόσεις patch σηματοδότησαν διορθώσεις, ή refactors, ή ουσιαστικά οτιδήποτε άλλο που θα έπρεπε να προκαλέσει μια νέα κυκλοφορία. fix: revert "fix" by AI that skipped the breaking tests to avoid the failure Και τέλος, μερικές δεσμεύσεις δεν θα πρέπει να προκαλέσουν καθόλου απελευθέρωση. «Εργασίες» όπως μου εισήχθησαν. chore: update release pipeline version from v3.1.0 to v3.1.1 Αυτή η συγκεκριμένη μορφή μηνυμάτων commit ήταν γνωστή ως Μπορείτε να ελέγξετε τη σελίδα τους για το πλήρες spec, αλλά ήθελα να μοιραστώ την ουσία του. Συμβατικές Επιτροπές Επιπλέον, αυτές οι πληροφορίες που περιέχονται στα συμβόλαια θα μπορούσαν επίσης να εμφανιστούν ως αρχείο καταγραφής αλλαγών - όπως η επισήμανση μιας αλλαγής κατάρρευσης. What's new in v2.0.0 * feat: remove deprecated API BREAKING CHANGE: the FooBar API that was deprecated. To upgrade, you can use the new BazBar API. Έτσι, για λίγο, η σημασιολογική απελευθέρωση ήταν μεγάλη για μένα. Για τα έργα Node, εξακολουθεί να είναι... Ωστόσο... Σχετικά με DevOps Πάντα με ενδιέφερε η ιδέα του πώς να χτίσω κλιμακούμενα κατανεμημένα συστήματα και έτσι ήταν κάτι που επιδίωξα για αρκετό καιρό στην καριέρα μου. μακρά ιστορία σύντομη, τελικά έμαθα πώς να το κάνω καλά, αλλά είχα ένα νέο πρόβλημα: πώς να αναπτύξω όλα τα κομμάτια. Αυτές δεν ήταν npm ενότητες, ήταν εφαρμογές, υπηρεσίες, βάσεις δεδομένων και ουρές! Μου άρεσε η απλότητα της σημασιολογικής απελευθέρωσης, αλλά λειτουργούσε μόνο καλά για τα έργα Node.js. αρχείο σε έργα που δεν είναι κόμβοι, αλλά αυτό ήταν ακατάλληλο και hacky στην καλύτερη περίπτωση. package.json Περίπου αυτή τη στιγμή, έγινα βαθιά εμπλεκόμενος στο DevOps, κατά τη διάρκεια της εποχής του Jenkins, καθώς το Docker άρχισε να κερδίζει έλξη. Έμαθα να γράφω αγωγούς με το Jenkins και να αναπτύσσω τα πάντα με το Docker Swarm! Το πρώτο μου ταξίδι DevOps και η ανακάλυψη του Docker για ανάπτυξη. Ο πιο πρόσφατος και ακόμα σχετικός και ακριβής οδηγός μου για το Git with Trunk Based Development άρθρο εξηγεί το γιατί και πώς αν σας ενδιαφέρει. Ο πιο πρόσφατος και ακόμα σχετικός και ακριβής οδηγός μου για το Git with Trunk Based Development άρθρο εξηγεί το γιατί και πώς αν σας ενδιαφέρει. Πάντα ήθελα αυτά τα έργα με τα οποία εργάστηκα να εκδοθούν και να κυκλοφορήσουν όπως τα έργα σημασιολογικής έκδοσης, αλλά ποτέ δεν βρήκα μια λύση που να λειτούργησε. Δεν ήταν το πιο σημαντικό πράγμα στη λίστα μου, οπότε γενικά το αποκαλούσα αρκετά καλό και έζησα με τα ελαττώματα. Με την πάροδο του χρόνου, ως σύμβουλος DevOps, έχω συναντήσει και κυκλοφορήσει διάφορα έργα σε πολλαπλές γλώσσες και πλαίσια, και κάθε ένα από αυτά έχει απαιτήσει εκδόσεις, εκδόσεις και αρχεία αλλαγής. Ένας άλλος πονοκέφαλος που συναντούσα συχνά ήταν μεγάλοι, μονολιθικοί αγωγοί. Έχοντας έρθει από την εποχή του Jenkins, το παίρνω, αυτό είναι πώς συνήθιζα να γράφω αγωγοί επίσης. Θα προσπαθούσα να έχω ολόκληρη τη ροή απελευθέρωσης σε μια μεγάλη σειρά βημάτων, ξεκινώντας με μια ώθηση στο κύριο. Αυτό δεν είναι τρομερό από μόνο του και επίσης πιθανότατα "αρκετά καλό" στις περισσότερες περιπτώσεις. ωστόσο, ως σύμβουλος DevOps, πρέπει να το κάνω επανειλημμένα. Το να σπάσω τα πράγματα σε μικρότερα, πιο αρθρωτά κομμάτια επιτρέπει σε αυτά τα κομμάτια να εξυπηρετήσουν περισσότερα έργα. , μια ιδέα που προέρχεται από την υιοθέτηση φιλοσοφιών του UNIX. Η κάλυψη των ιδεών Για παράδειγμα, ένας αγωγός ποιότητας του κόμβου μπορεί να είναι ο ίδιος σε κάθε έργο του κόμβου, υπό την προϋπόθεση ότι ακολουθείτε τις τυποποιημένες συμβάσεις σεναρίου npm, και έτσι ένας γενικός αγωγός για την εκτέλεση της σύνδεσης, της κατασκευής και των δοκιμών μονάδων μπορεί να μοιραστεί τα περισσότερα, αν όχι όλα, έργα του Node.js. κ.λπ., και το τμήμα των γραπτών του Το αρχείο καθορίζει τι συμβαίνει όταν Η διοίκηση τρέχει. npm run lint --if-present package.json lint Υψηλού επιπέδου αγωγοί για έκδοση και απελευθέρωση Σε υψηλό επίπεδο, κάθε έργο που χρειάζεται να κυκλοφορήσει θα επισημανθεί πρώτα με έναν νέο αριθμό έκδοσης. Στη συνέχεια, μπορεί να δημιουργηθεί μια έκδοση που συνδέεται με αυτόν τον αριθμό έκδοσης και τα αντικείμενα θα παράγονται ως μέρος των σχετικών αγωγών. Χρησιμοποιώ GitHub Actions πιο συχνά, καθώς νομίζω ότι οι αγωγοί είναι εμπορεύματα, και είναι ένα απλό για να ξεκινήσετε. έχω χρησιμοποιήσει πολλά, αλλά είναι όλα ουσιαστικά το ίδιο - εκτελέστε μια σειρά από βήματα με κοινό όγκο. Η ίδια η έκδοση, αν ακολουθούμε το πρότυπο των συμβατικών δεσμεύσεων που συνδέονται με την αύξηση της σημασιολογικής έκδοσης, δεν είναι γλωσσικά ειδικό πράγμα. Για μεγάλο χρονικό διάστημα, έχω συνδέσει τις εκδόσεις με τις εκδόσεις, νομίζοντας ότι ήταν μέρος του ίδιου πράγματος, όταν στην πραγματικότητα είναι δύο ξεχωριστές οντότητες που ενώνονται μαζί. Η διάσπαση τους χωριστά έκανε το τμήμα έκδοσης του αγωγού το δικό του αρθρωτό κομμάτι, το οποίο στη συνέχεια ενεργοποίησε μια κατασκευή αυτής της έκδοσης και την επακόλουθη κυκλοφορία. Για κάθε έργο, στο GitHub Actions, έχω δύο αγωγούς: On commit to the trunk branch, version, and tag When a commit occurs in the trunk branch (usually or ), trigger a pipeline that runs quality checks, and, if they pass, calculates a new version number. It then creates and pushes a tag with that new version number. We can also use this opportunity to update that version number in the code base if necessary, and generate a change log from the commit data that was used to calculate the new version number. main master When a tag is created, build new versions and release them. This step is simplified by the previous step of doing the version bump. Everything’s already been bumped to the new version. We can just run build and release using the tag as the base. Όπως ανέφερα νωρίτερα, αφού προσπάθησα πολλές φορές να συνθέσω στοιχεία ανοιχτού κώδικα από το GitHub Actions Marketplace, τελικά παραχώρησα και έγραψα το δικό μου εργαλείο που χειρίζεται το βήμα ένα. Εισαγωγή Επόμενο Επόμενο Το vnext είναι ένα γρήγορο εργαλείο Rust CLI που χρησιμοποιεί συμβατικά μηνύματα συμβιβασμού για να υπολογίσει την επόμενη σημασιολογική έκδοση, αυτοματοποιώντας μεγάλες, μικρές ή επιδιορθώσεις για απλοποιημένες εκδόσεις. Εδώ είναι πώς να το χρησιμοποιήσετε. NEXT_VERSION=v`vnext` vnext --changelog > CHANGELOG.md Είναι αρκετά απλό!Αφήστε με να ξέρω τι σκέφτεστε. Βασίζεται εξ ολοκλήρου στην ιστορία του έργου. Δεν έχει σημασία ποια γλώσσα ή εργαλείο απελευθερώνετε. η διαδικασία έκδοσης είναι ουσιαστικά η ίδια. αποκτήστε μια νέα έκδοση, ενημερώστε το σε μερικά αρχεία, δημιουργήστε ένα changelog, ετικέτα και πιέστε. Είναι γρήγορο και εύκολο να εγκατασταθεί μέσω - την Μόλις διαμορφωθεί, μπορείτε να εκτελέσετε: vnext ubi Το «Universal Binary Installer» ubi --project unbounded-tech/vnext Έχω επίσης δημιουργήσει μια κοινή ροή εργασίας GitHub Actions που μπορείτε να καλέσετε, η οποία χειρίζεται όλες αυτές τις λεπτομέρειες. Εδώ είναι πώς να χρησιμοποιήσετε την κοινή ροή εργασίας: name: On Push Main, Version and Tag on: push: branches: - main - master permissions: packages: write contents: write jobs: version-and-tag: uses: unbounded-tech/workflow-vnext-tag/.github/workflows/workflow.yaml@v1 with: useDeployKey: true changelog: true Τα περισσότερα έργα θα πρέπει επίσης να ρυθμίσετε πώς και ποια αρχεία να ενημερώσετε με τον νέο αριθμό έκδοσης. Επί του παρόντος, Υποστηρίζει δύο γενικές μεθόδους ( και ) και μερικές γλωσσικές επιλογές. vnext yqPatches regexPatches Οι επιλογές γλώσσας είναι οι ευκολότερες στη χρήση. για παράδειγμα, η ρύθμιση Δύο Χρησιμοποιήστε για να ενημερώσετε τα αρχεία πακέτου του έργου. with.node true npm Χρησιμοποιήστε το εργαλείο Για να διορθώσετε συγκεκριμένα πεδία σε ένα αρχείο YAML. Συχνά χρησιμοποιώ αυτό για την ενημέρωση αριθμών εκδόσεων σε διαγράμματα Helm: yqPatches yq version-and-tag: uses: unbounded-tech/workflow-vnext-tag/.github/workflows/workflow.yaml@v1.13.0 secrets: GH_PAT: ${{ secrets.YOUR_ORG_SECRET_PAT }} with: usePAT: true changelog: true yqPatches: | patches: - filePath: helm/values.yaml selector: .image.tag valuePrefix: "v" - filePath: helm/Chart.yaml selector: .version valuePrefix: "v" Χρησιμοποίησα επίσης αυτή την ευκαιρία για να μοιραστώ πώς να χρησιμοποιήσω ένα προσωπικό token πρόσβασης αντί για ένα κλειδί ανάπτυξης. Χρησιμοποίησα επίσης αυτή την ευκαιρία για να μοιραστώ πώς να χρησιμοποιήσω ένα προσωπικό token πρόσβασης αντί για ένα κλειδί ανάπτυξης. Χρησιμοποιήστε για να βρείτε και να αντικαταστήσετε μια γραμμή με τον αριθμό έκδοσης που έχει εισαχθεί. regexPatches sed regexPatches: | patches: - filePath: package/composition.yaml regex: /ghcr.io/org-name/package-name:(.*)/g valuePrefix: ghcr.io/org-name/package-name:v - filePath: README.md regex: /Current version: v[0-9]+\.[0-9]+\.[0-9]+/g valuePrefix: Current version: v Μπορείτε επίσης να χρησιμοποιήσετε ένα συνδυασμό επιλογών. Μια απόχρωση σχετικά με τις ενέργειες του GitHub Όταν εκτελείτε μια ενέργεια στο GitHub Actions, από προεπιλογή, ο εργαζόμενος δημιουργεί ένα προσωρινό token επαλήθευσης ταυτότητας GitHub. Αυτό το token έχει άδεια να εκτελέσει μερικές βασικές εργασίες. Αλλά το επόμενο βήμα μας μετά την ετικέτα μιας νέας έκδοσης ήταν να ενεργοποιήσουμε έναν άλλο αγωγό με αυτή την ετικέτα! Μην ανησυχείτε, αυτό είναι σχεδιασμένο - απλά ένα μέτρο από το GitHub για να αποτρέψετε την ακούσια περιστροφή ενός σωρού δρομέων. Υπάρχουν μερικοί τρόποι για να είναι σκόπιμο σχετικά με αυτό - έχω ήδη δείξει ένα παράδειγμα από δύο: Χρησιμοποιώντας ένα κλειδί ανάπτυξης και το αντίστοιχο GitHub Actions Secret Χρησιμοποιώντας ένα προσωπικό token πρόσβασης ως μυστικό δράσης του GitHub Δημιουργία μιας εφαρμογής GitHub (θεωρητικά - δεν έχω ανάγκη αυτή την επιλογή) Η χρήση ενός προσωπικού token πρόσβασης είναι βολική εάν είστε πελάτης που πληρώνει στο οικοσύστημα του GitHub, καθώς είναι διαθέσιμα μυστικά σε ολόκληρο τον οργανισμό. Στο δωρεάν επίπεδο, αυτό δεν είναι μια επιλογή, οπότε θα σας δείξω πώς να ρυθμίσετε ένα κλειδί ανάπτυξης. Στην πραγματικότητα, το έκανα πολύ απλό, οικοδομώντας το στο Είναι μια μεγάλη επιλογή, καθώς όταν ρυθμίζεται με αυτόν τον τρόπο, κανένας άνθρωπος δεν χρειάζεται να το γνωρίζει και μπορεί εύκολα να περιστραφεί επαναλαμβάνοντας την ίδια εντολή. vnext Για κάθε αποθετήριο που θέλετε να δημιουργήσετε για να απελευθερώσετε με ένα πλήκτρο ανάπτυξης, στον κατάλογο του έργου... vnext Πρώτον, αποκτήστε ένα auth token χρησιμοποιώντας Με άδεια διαχείρισης κλειδιών: gh gh auth refresh -h github.com -s admin:public_key -s admin:ssh_signing_key export GITHUB_TOKEN=$(gh auth token) Και μετά τρέχει: vnext generate-deploy-key Μπορεί να αναρωτιέστε, δεν μπορεί αυτό να πάει σε έναν αγωγό από μόνη της; Δυστυχώς, δεν μπορώ να βρω έναν τρόπο να αυτοματοποιήσω αυτό το βήμα στις ενέργειες του Github χωρίς να δημιουργήσω ένα προσωπικό token πρόσβασης, καθώς το προεπιλεγμένο token δεν μπορεί να τροποποιήσει τα μυστικά. Αυτό νικάει το pupose της χρήσης ενός κλειδιού ανάπτυξης αντί για το δωρεάν επίπεδο, καθώς θα πρέπει να το δημιουργήσετε σε κάθε repo. Αυτό απαιτεί κάποιο είδος μυστικής διαχείρισης για να το κάνετε εύκολο, και έτσι το κάνει πιο λειτουργικό από το να χρησιμοποιήσετε ένα κλειδί ανάπτυξης. Μπορεί να αναρωτιέστε, δεν μπορεί αυτό να πάει σε έναν αγωγό από μόνη της; Δυστυχώς, δεν μπορώ να βρω έναν τρόπο να αυτοματοποιήσω αυτό το βήμα στις ενέργειες του Github χωρίς να δημιουργήσω ένα προσωπικό token πρόσβασης, καθώς το προεπιλεγμένο token δεν μπορεί να τροποποιήσει τα μυστικά. Αυτό νικάει το pupose της χρήσης ενός κλειδιού ανάπτυξης αντί για το δωρεάν επίπεδο, καθώς θα πρέπει να το δημιουργήσετε σε κάθε repo. Αυτό απαιτεί κάποιο είδος μυστικής διαχείρισης για να το κάνετε εύκολο, και έτσι το κάνει πιο λειτουργικό από το να χρησιμοποιήσετε ένα κλειδί ανάπτυξης. Με το κλειδί ανάπτυξης ή το προσωπικό token πρόσβασης (PAT) στη θέση του, και η ροή εργασίας έκδοσης και ετικετών που εκτελείται σε σπρώχνει στον κλάδο του κορμού σας, το επόμενο βήμα είναι να απελευθερώσετε! Αυτό θα ποικίλει ανάλογα με το έργο, αλλά όλα ενεργοποιούνται από την έκδοση που έχει επισημανθεί από το προηγούμενο βήμα. name: On Version Tag, Trigger GitHub Release on: push: tags: - 'v*.*.*' permissions: contents: write jobs: release: uses: unbounded-tech/workflow-simple-release/.github/workflows/workflow.yaml@v1 with: tag: ${{ github.ref_name }} name: ${{ github.ref_name }} Ή, αν ήταν ένα έργο Rust, ίσως κάτι τέτοιο: name: On Version Tagged, Build and Publish Rust Binaries on: push: tags: - "v*.*.*" permissions: contents: write jobs: build-and-release: uses: unbounded-tech/workflows-rust/.github/workflows/release.yaml@v1 with: binary_name: ${{ github.event.repository.name }} build_args: "--release --features vendored" Ή αν ήταν μια εφαρμογή με ένα Dockerfile, και οι ορισμοί πόρων του k8s για τις αναπτύξεις του Gitops, ίσως κάτι τέτοιο: name: promote on: push: tags: - v*.*.* permissions: contents: write packages: write issues: write pull-requests: write jobs: publish: uses: unbounded-tech/workflows-containers/.github/workflows/publish.yaml@v1.1.1 release: needs: publish uses: unbounded-tech/workflow-simple-release/.github/workflows/workflow.yaml@v1 with: tag: ${{ github.ref_name }} name: ${{ github.ref_name }} promote: needs: release uses: unbounded-tech/workflows-gitops/.github/workflows/helm-promote.yaml@v1 secrets: GH_PAT: ${{ secrets.GH_PAT }} with: environment_repository: your-org/staging-env path: .gitops/deploy project: staging Σημείωση: Ένα πλήκτρο ανάπτυξης δεν μπορεί να μετακινηθεί σε άλλο repos, όπως στο βήμα προώθησης gitops, οπότε μπορείτε να εξετάσετε τη χρήση ενός PAT παντού για αυτό το repository.Αν έχετε πολλά φορτία εργασίας όπως αυτό, η αναβάθμιση σε ένα πληρωμένο org μπορεί να αξίζει τον κόπο για οργανωτικά μυστικά, αντί να ρυθμίσετε κάθε repo ξεχωριστά. Σημείωση: Ένα πλήκτρο ανάπτυξης δεν μπορεί να μετακινηθεί σε άλλο repos, όπως στο βήμα προώθησης gitops, οπότε μπορείτε να εξετάσετε τη χρήση ενός PAT παντού για αυτό το repository.Αν έχετε πολλά φορτία εργασίας όπως αυτό, η αναβάθμιση σε ένα πληρωμένο org μπορεί να αξίζει τον κόπο για οργανωτικά μυστικά, αντί να ρυθμίσετε κάθε repo ξεχωριστά. Σε γενικές γραμμές, κάθε έκδοση είναι ένας συνδυασμός μερικών τεμαχίων από αυτές τις παρόμοιες ενότητες, οι οποίες κάνουν σχεδόν τα ίδια πράγματα, αλλά για τα συγκεκριμένα τους εργαλεία ή γλώσσες. Συνήθως, οι οργανισμοί τουλάχιστον προσπαθούν να ακολουθήσουν πολλά από τα ίδια πρότυπα σε όλες τις εφαρμογές και τις υπηρεσίες που δημιουργούν, και έτσι η διάσπαση των ροών εργασίας σε κοινόχρηστα αρθρωτά κομμάτια επιτρέπει στους προγραμματιστές να αντιγράψουν και να επικολλήσουν τη γεύση αυτών των κοινών κλήσεων ροής εργασίας σε κάθε έργο αυτού του τύπου. Συνεπείς εκδόσεις με Changelogs Μπορεί να έχετε παρατηρήσει ένα είδος κοίταξε πάνω από το Ήθελα να επιστρέψω σε αυτό, καθώς είναι ένα σημαντικό μέρος μιας ώριμης διαδικασίας κυκλοφορίας.Το changelog είναι πώς μπορείτε να επικοινωνήσετε τους τρόπους με τους οποίους το έργο σας έχει αλλάξει σε άλλους προγραμματιστές. with.changelog Παράλληλα με τις εκδοχές, χρησιμοποιεί επίσης τα μηνύματα συμβιβασμού για να κατασκευάσει αυτό το changelog και το αποθηκεύει σε ένα αρχείο που ονομάζεται CHANGELOG.md, το οποίο είναι δεσμευμένο μαζί με την ετικέτα έκδοσης και τα σφάλματα έκδοσης. vnext Κρυμμένο σε αυτές τις ροές εργασίας έκδοσης που μοιράστηκα παραπάνω, αυτό το αρχείο χρησιμοποιείται ως σώμα της έκδοσης GitHub. Το ίδιο το πρόγραμμα: vnext Αυτή η έκδοση ήταν μια έκδοση patch, καθώς περιείχε μια επιδιόρθωση, με τη μορφή μιας έκδοσης εξάρτησης, και μια σειρά από άλλες εργασίες. Αυτές οι σημειώσεις απελευθέρωσης εμφανίζονται στη συνέχεια σε άλλα εργαλεία, όπως , ένα εργαλείο που κάνει τις δημόσιες σχέσεις να διατηρούν τις εξαρτήσεις σας ενημερωμένες. Ανανεώστε Κατά τη συγχώνευση Pull Requests, μου αρέσει να χρησιμοποιώ τη λειτουργία Squash and Merge του GitHub για να έχω την ευκαιρία να γράψω έναν καλό τίτλο και το σώμα του τελικού μηνύματος commit που θα χρησιμοποιηθεί στο changelog. Για παράδειγμα: Όπως φαίνεται στο παράδειγμα, μπορείτε να τοποθετήσετε το πλήρες Markdown ως σώμα ανάθεσης. Θα εμφανιστεί κατάλληλα στις σημειώσεις κυκλοφορίας! Συμπέρασμα Ξέρω ότι η έκδοση και η απελευθέρωση δεν είναι το πιο σέξι θέμα. είναι μάλλον βαρετό - ή μάλλον, θα πρέπει να είναι! Ωστόσο, αυτό δεν συμβαίνει πάντα. γι 'αυτό δημιουργήσαμε Και μια δέσμη από Τώρα, μπορώ εύκολα να επιβιβαστώ στα περισσότερα έργα πολύ γρήγορα! vnext Κοινές ροές εργασίας Ελπίζω να είναι χρήσιμο και για εσάς! Παρακαλώ να μου πείτε αν δίνετε Θα ήθελα να εκτιμήσω μερικά αστέρια στο GitHub και να μοιραστώ αν τα βρείτε χρήσιμα! vnext
