🥇Οδηγός CI/CD στο GitLab για τον (σχεδόν) απόλυτο αρχάριο

Ή πώς να αποκτήσετε όμορφα σήματα για το έργο σας σε ένα απόγευμα εύκολης κωδικοποίησης

Πιθανώς, κάθε προγραμματιστής που έχει τουλάχιστον ένα έργο για κατοικίδια κάποια στιγμή έχει μια φαγούρα σχετικά με όμορφα σήματα με καταστάσεις, κάλυψη κωδικών, εκδόσεις πακέτων στο nuget ... Και αυτή η φαγούρα με οδήγησε να γράψω αυτό το άρθρο. Προετοιμάζοντας να το γράψω, πήρα αυτή την ομορφιά σε ένα από τα έργα μου:

Αυτό το άρθρο θα σας καθοδηγήσει στη βασική ρύθμιση της συνεχούς ενσωμάτωσης και παράδοσης για ένα έργο βιβλιοθήκης κλάσης .Net Core στο GitLab, δημοσίευση τεκμηρίωσης σε σελίδες GitLab και προώθηση ενσωματωμένων πακέτων σε μια ιδιωτική ροή στο Azure DevOps.

Ο κώδικας VS χρησιμοποιήθηκε ως περιβάλλον ανάπτυξης με την επέκταση Ροή εργασίας GitLab (για επικύρωση του αρχείου ρυθμίσεων απευθείας από το περιβάλλον ανάπτυξης).

Σύντομη εισαγωγή

CD - είναι όταν μόλις πιέστηκες και όλα έχουν ήδη πέσει στον πελάτη;

Τι είναι το CI / CD και γιατί το χρειάζεστε - μπορείτε εύκολα να το αναζητήσετε στο google. Βρείτε πλήρη τεκμηρίωση για τη διαμόρφωση αγωγών στο GitLab επίσης εύκολο. Εδώ θα περιγράψω εν συντομία και, αν είναι δυνατόν, χωρίς ελαττώματα τη διαδικασία του συστήματος από την οπτική γωνία:

ο προγραμματιστής στέλνει μια δέσμευση στο αποθετήριο, δημιουργεί ένα αίτημα συγχώνευσης μέσω του ιστότοπου, ή με κάποιον άλλο τρόπο ξεκινά ρητά ή σιωπηρά τον αγωγό,
όλες οι εργασίες επιλέγονται από τη διαμόρφωση, οι συνθήκες της οποίας επιτρέπουν την εκκίνηση στο δεδομένο πλαίσιο,
οι εργασίες οργανώνονται ανάλογα με τα στάδια τους,
τα στάδια εκτελούνται με τη σειρά - δηλ. παράλληλο όλες οι εργασίες αυτού του σταδίου έχουν ολοκληρωθεί,
εάν η σκηνή αποτύχει (δηλαδή, τουλάχιστον μία από τις εργασίες της σκηνής αποτύχει), ο αγωγός σταματά (σχεδόν πάντα),
εάν όλα τα στάδια ολοκληρωθούν επιτυχώς, ο αγωγός θεωρείται επιτυχής.

Έτσι, έχουμε:

Pipeline - ένα σύνολο εργασιών οργανωμένων σε στάδια στα οποία μπορείτε να δημιουργήσετε, να δοκιμάσετε, να συσκευάσετε κώδικα, να αναπτύξετε μια ολοκληρωμένη έκδοση σε μια υπηρεσία cloud κ.λπ.
στάδιο (στάδιο) — μονάδα οργάνωσης αγωγού, περιέχει 1+ εργασία,
εργασία (εργασία) είναι μια μονάδα εργασίας σε εξέλιξη. Αποτελείται από ένα σενάριο (υποχρεωτικό), συνθήκες εκκίνησης, ρυθμίσεις για δημοσίευση/αποθήκευση αντικειμένων και πολλά άλλα.

Αντίστοιχα, η εργασία κατά τη ρύθμιση του CI / CD καταλήγει στη δημιουργία ενός συνόλου εργασιών που υλοποιούν όλες τις απαραίτητες ενέργειες για τη δημιουργία, τη δοκιμή και τη δημοσίευση κώδικα και τεχνουργημάτων.

Πριν ξεκινήσετε: γιατί;

Γιατί Gitlab;

Γιατί όταν χρειάστηκε να δημιουργηθούν ιδιωτικά αποθετήρια για έργα κατοικίδιων ζώων, πληρώνονταν στο GitHub και ήμουν άπληστος. Τα αποθετήρια έχουν γίνει δωρεάν, αλλά μέχρι στιγμής αυτός δεν είναι αρκετός λόγος για να μετακομίσω στο GitHub.

Γιατί όχι το Azure DevOps Pipelines;

Επειδή εκεί η ρύθμιση είναι στοιχειώδης - δεν απαιτείται καν γνώση της γραμμής εντολών. Ενσωμάτωση με εξωτερικούς παρόχους git - με μερικά κλικ, εισαγωγή κλειδιών SSH για αποστολή δεσμεύσεων στο αποθετήριο - επίσης, η διοχέτευση διαμορφώνεται εύκολα ακόμη και όχι από ένα πρότυπο.

Αρχική θέση: τι έχεις και τι θέλεις

Εχουμε:

αποθετήριο στο GitLab.

Θέλουμε:

αυτόματη συναρμολόγηση και δοκιμή για κάθε αίτημα συγχώνευσης,
δημιουργία πακέτων για κάθε αίτημα συγχώνευσης και ώθηση στο κύριο, με την προϋπόθεση ότι υπάρχει μια συγκεκριμένη γραμμή στο μήνυμα δέσμευσης,
αποστολή ενσωματωμένων πακέτων σε μια ιδιωτική ροή στο Azure DevOps,
συναρμολόγηση τεκμηρίωσης και δημοσίευση στις Σελίδες GitLab,
κονκάρδες!11

Οι περιγραφόμενες απαιτήσεις εμπίπτουν οργανικά στο ακόλουθο μοντέλο αγωγού:

Στάδιο 1 - Συναρμολόγηση
- Συλλέγουμε τον κώδικα, δημοσιεύουμε τα αρχεία εξόδου ως τεχνουργήματα
Στάδιο 2 - δοκιμή
- Λαμβάνουμε τεχνουργήματα από το στάδιο κατασκευής, εκτελούμε δοκιμές, συλλέγουμε δεδομένα κάλυψης κώδικα
Στάδιο 3 - Υποβολή
- Εργασία 1 - δημιουργήστε το πακέτο nuget και στείλτε το στο Azure DevOps
- Εργασία 2 - συλλέγουμε τον ιστότοπο από το xmldoc στον πηγαίο κώδικα και τον δημοσιεύουμε στις Σελίδες GitLab

Ας αρχίσουμε!

Συλλογή της διαμόρφωσης

Προετοιμασία λογαριασμών

Δημιουργία λογαριασμού σε Η Microsoft Azure
Παω σε Azure DevOps
Δημιουργούμε ένα νέο έργο
1. Όνομα - οποιοδήποτε
2. Ορατότητα - οποιαδήποτε
Όταν κάνετε κλικ στο κουμπί Δημιουργία, το έργο θα δημιουργηθεί και θα ανακατευθυνθείτε στη σελίδα του. Σε αυτήν τη σελίδα, μπορείτε να απενεργοποιήσετε τις περιττές λειτουργίες μεταβαίνοντας στις ρυθμίσεις του έργου (κάτω σύνδεσμος στη λίστα στα αριστερά -> Επισκόπηση -> Μπλοκ Υπηρεσιών Azure DevOps)
Μεταβείτε στο Atrifacts, κάντε κλικ στην επιλογή Δημιουργία ροής
1. Εισαγάγετε το όνομα της πηγής
2. Επιλέξτε ορατότητα
3. Καταργήστε την επιλογή Συμπεριλάβετε πακέτα από κοινές δημόσιες πηγές, έτσι ώστε η πηγή να μην μετατραπεί σε dump nuget clone
Κάντε κλικ στο Connect to feed, επιλέξτε Visual Studio, αντιγράψτε το Source από το μπλοκ Machine Setup
Μεταβείτε στις ρυθμίσεις λογαριασμού, επιλέξτε Personal Access Token
Δημιουργήστε ένα νέο διακριτικό πρόσβασης
1. Όνομα - αυθαίρετο
2. Οργάνωση - τρέχουσα
3. Ισχύει για μέγιστο 1 έτος
4. Πεδίο εφαρμογής - Συσκευασία/Ανάγνωση & Γράψτε
Αντιγράψτε το διακριτικό που δημιουργήθηκε - μετά το κλείσιμο του παραθύρου modal, η τιμή δεν θα είναι διαθέσιμη
Μεταβείτε στις ρυθμίσεις αποθετηρίου στο GitLab, επιλέξτε τις ρυθμίσεις CI / CD
Αναπτύξτε το μπλοκ Μεταβλητές, προσθέστε ένα νέο
1. Όνομα - οποιοδήποτε χωρίς κενά (θα είναι διαθέσιμο στο κέλυφος εντολών)
2. Τιμή - διακριτικό πρόσβασης από την παράγραφο 9
3. Επιλέξτε Μεταβλητή Μάσκα

Αυτό ολοκληρώνει την προ-διαμόρφωση.

Προετοιμασία του πλαισίου διαμόρφωσης

Από προεπιλογή, η διαμόρφωση CI/CD στο GitLab χρησιμοποιεί το αρχείο .gitlab-ci.yml από τη ρίζα του αποθετηρίου. Μπορείτε να ορίσετε μια αυθαίρετη διαδρομή σε αυτό το αρχείο στις ρυθμίσεις του αποθετηρίου, αλλά σε αυτήν την περίπτωση δεν είναι απαραίτητο.

Όπως μπορείτε να δείτε από την επέκταση, το αρχείο περιέχει μια διαμόρφωση στη μορφή YAML. Η τεκμηρίωση αναφέρει ποια κλειδιά μπορούν να περιέχονται στο ανώτερο επίπεδο της διαμόρφωσης και σε κάθε ένα από τα ένθετα επίπεδα.

Αρχικά, ας προσθέσουμε έναν σύνδεσμο στην εικόνα του docker στο αρχείο διαμόρφωσης, στον οποίο θα εκτελούνται οι εργασίες. Για αυτό βρίσκουμε Σελίδα εικόνων .Net Core στο Docker Hub. Σε GitHub υπάρχει ένας λεπτομερής οδηγός για το ποια εικόνα να επιλέξετε για διαφορετικές εργασίες. Μια εικόνα με .Net Core 3.1 είναι κατάλληλη για να δημιουργήσουμε, γι' αυτό μη διστάσετε να προσθέσετε την πρώτη γραμμή στη διαμόρφωση

image: mcr.microsoft.com/dotnet/core/sdk:3.1

Τώρα, όταν εκκινηθεί η διοχέτευση από το αποθετήριο εικόνων της Microsoft, θα γίνει λήψη της καθορισμένης εικόνας, στην οποία θα εκτελεστούν όλες οι εργασίες από τη διαμόρφωση.

Το επόμενο βήμα είναι η προσθήκη στάδιο'μικρό. Από προεπιλογή, το GitLab ορίζει 5 στάδια:

.pre - εκτελούνται σε όλα τα στάδια,
.post - εκτελείται μετά από όλα τα στάδια,
build - πρώτα μετά .pre στάδιο,
test - δεύτερη φάση,
deploy - το τρίτο στάδιο.

Τίποτα δεν σας εμποδίζει να τα δηλώσετε ρητά, ωστόσο. Η σειρά με την οποία παρατίθενται τα βήματα επηρεάζει τη σειρά με την οποία εκτελούνται. Για πληρότητα, ας προσθέσουμε στη διαμόρφωση:

stages:
  - build
  - test
  - deploy

Για τον εντοπισμό σφαλμάτων, είναι λογικό να λαμβάνετε πληροφορίες σχετικά με το περιβάλλον στο οποίο εκτελούνται οι εργασίες. Ας προσθέσουμε ένα συνολικό σύνολο εντολών που θα εκτελούνται πριν από κάθε εργασία με before_script:

before_script:
  - $PSVersionTable.PSVersion
  - dotnet --version
  - nuget help | select-string Version

Απομένει να προστεθεί τουλάχιστον μία εργασία, ώστε όταν αποσταλούν οι δεσμεύσεις, να ξεκινήσει η διοχέτευση. Προς το παρόν, ας προσθέσουμε μια κενή εργασία για επίδειξη:

dummy job:
  script:
    - echo ok

Ξεκινάμε την επικύρωση, λαμβάνουμε ένα μήνυμα ότι όλα είναι καλά, δεσμευόμαστε, πιέζουμε, κοιτάμε τα αποτελέσματα στον ιστότοπο ... Και λαμβάνουμε ένα σφάλμα σεναρίου - bash: .PSVersion: command not found. wtf;

Όλα είναι λογικά - από προεπιλογή, οι runners (υπεύθυνοι για την εκτέλεση σεναρίων εργασιών και παρέχονται από το GitLab) χρησιμοποιούν bash για την εκτέλεση εντολών. Μπορείτε να το διορθώσετε προσδιορίζοντας ρητά στην περιγραφή της εργασίας ποιες ετικέτες πρέπει να έχει ο εκτελούμενος runner pipeline:

dummy job on windows:
  script:
    - echo ok
  tags:
    - windows

Εξαιρετική! Ο αγωγός τρέχει τώρα.

Ένας προσεκτικός αναγνώστης, έχοντας επαναλάβει τα υποδεικνυόμενα βήματα, θα παρατηρήσει ότι η εργασία ολοκληρώθηκε στο στάδιο test, αν και δεν προσδιορίσαμε το στάδιο. Όπως μπορείτε να μαντέψετε test είναι το προεπιλεγμένο βήμα.

Ας συνεχίσουμε να δημιουργούμε τον σκελετό διαμόρφωσης προσθέτοντας όλες τις εργασίες που περιγράφονται παραπάνω:

build job:
  script:
    - echo "building..."
  tags:
    - windows
  stage: build

test and cover job:
  script:
    - echo "running tests and coverage analysis..."
  tags:
    - windows
  stage: test

pack and deploy job:
  script:
    - echo "packing and pushing to nuget..."
  tags:
    - windows
  stage: deploy

pages:
  script:
    - echo "creating docs..."
  tags:
    - windows
  stage: deploy

Πήραμε έναν όχι ιδιαίτερα λειτουργικό, αλλά παρόλα αυτά σωστό αγωγό.

Ρύθμιση σκανδάλων

Λόγω του γεγονότος ότι δεν έχουν καθοριστεί φίλτρα ενεργοποίησης για καμία από τις εργασίες, η διοχέτευση θα πλήρως να εκτελείται κάθε φορά που μια δέσμευση προωθείται στο αποθετήριο. Δεδομένου ότι αυτή δεν είναι η επιθυμητή συμπεριφορά γενικά, θα ρυθμίσουμε φίλτρα ενεργοποίησης για εργασίες.

Τα φίλτρα μπορούν να διαμορφωθούν σε δύο μορφές: μόνο/εκτός и κανόνες. Εν ολίγοις, only/except σας επιτρέπει να διαμορφώνετε τα φίλτρα κατά εναύσματα (merge_request, για παράδειγμα - ορίζει την εργασία που πρέπει να εκτελείται κάθε φορά που δημιουργείται ένα αίτημα έλξης και κάθε φορά που αποστέλλονται δεσμεύσεις στον κλάδο που είναι η πηγή στο αίτημα συγχώνευσης) και ονόματα κλάδου (συμπεριλαμβανομένης της χρήσης κανονικών εκφράσεων). rules σας επιτρέπει να προσαρμόσετε ένα σύνολο συνθηκών και, προαιρετικά, να αλλάξετε τη συνθήκη εκτέλεσης εργασιών ανάλογα με την επιτυχία των προηγούμενων εργασιών (when στο GitLab CI/CD).

Ας θυμηθούμε ένα σύνολο απαιτήσεων - συναρμολόγηση και δοκιμή μόνο για αίτημα συγχώνευσης, συσκευασία και αποστολή στο Azure DevOps - για αίτημα συγχώνευσης και ώθηση στο κύριο, δημιουργία τεκμηρίωσης - για ωθήσεις στο κύριο.

Αρχικά, ας ρυθμίσουμε την εργασία δημιουργίας κώδικα προσθέτοντας έναν κανόνα που ενεργοποιείται μόνο κατόπιν αιτήματος συγχώνευσης:

build job:
  # snip
  only:
    - merge_request

Τώρα ας ρυθμίσουμε την εργασία συσκευασίας για να ενεργοποιηθεί το αίτημα συγχώνευσης και να προσθέσουμε δεσμεύσεις στο master:

pack and deploy job:
  # snip
  only:
    - merge_request
    - master

Όπως μπορείτε να δείτε, όλα είναι απλά και ξεκάθαρα.

Μπορείτε επίσης να ρυθμίσετε την εργασία να ενεργοποιείται μόνο εάν δημιουργηθεί ένα αίτημα συγχώνευσης με έναν συγκεκριμένο κλάδο στόχο ή πηγή:

  rules:
    - if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"

Υπό προϋποθέσεις, μπορείτε να χρησιμοποιήσετε μεταβλητές που αναφέρονται εδώ; κανόνες rules ασυμβίβαστο με τους κανόνες only/except.

Διαμόρφωση Αποθήκευσης Artifact

Κατά τη διάρκεια μιας εργασίας build job θα έχουμε build artifacts που μπορούν να επαναχρησιμοποιηθούν σε επόμενες εργασίες. Για να το κάνετε αυτό, πρέπει να προσθέσετε τις διαδρομές στη διαμόρφωση εργασιών, τα αρχεία κατά μήκος των οποίων θα πρέπει να αποθηκεύσετε και να επαναχρησιμοποιήσετε στις ακόλουθες εργασίες, στο κλειδί artifacts:

build job:
  # snip
  artifacts:
    paths:
      - path/to/build/artifacts
      - another/path
      - MyCoolLib.*/bin/Release/*

Τα μονοπάτια υποστηρίζουν χαρακτήρες μπαλαντέρ, κάτι που σίγουρα διευκολύνει τον ορισμό τους.

Εάν μια εργασία δημιουργεί τεχνουργήματα, τότε κάθε επόμενη εργασία θα μπορεί να έχει πρόσβαση σε αυτά - θα βρίσκονται στις ίδιες διαδρομές σε σχέση με τη ρίζα του αποθετηρίου που συλλέχθηκαν από την αρχική εργασία. Τα τεχνουργήματα είναι επίσης διαθέσιμα για λήψη στον ιστότοπο.

Τώρα που έχουμε έτοιμο (και δοκιμασμένο) ένα πλαίσιο διαμόρφωσης, μπορούμε να προχωρήσουμε στη συγγραφή σεναρίων για εργασίες.

Γράφουμε σενάρια

Ίσως, μια φορά κι έναν καιρό, σε έναν γαλαξία πολύ, πολύ μακρινό, η κατασκευή έργων (συμπεριλαμβανομένων αυτών στο .net) από τη γραμμή εντολών ήταν ένας πόνος. Τώρα μπορείτε να δημιουργήσετε, να δοκιμάσετε και να δημοσιεύσετε το έργο σε 3 ομάδες:

dotnet build
dotnet test
dotnet pack

Φυσικά, υπάρχουν ορισμένες αποχρώσεις λόγω των οποίων θα περιπλέξουμε κάπως τις εντολές.

Θέλουμε μια έκδοση έκδοσης, όχι μια έκδοση εντοπισμού σφαλμάτων, οπότε προσθέτουμε σε κάθε εντολή -c Release
Κατά τη δοκιμή, θέλουμε να συλλέξουμε δεδομένα κάλυψης κώδικα, επομένως πρέπει να συμπεριλάβουμε έναν αναλυτή κάλυψης στις βιβλιοθήκες δοκιμής:
1. Προσθέστε το πακέτο σε όλες τις δοκιμαστικές βιβλιοθήκες coverlet.msbuild: dotnet add package coverlet.msbuild από το φάκελο του έργου
2. Προσθήκη στην εντολή δοκιμαστικής εκτέλεσης /p:CollectCoverage=true
3. Προσθέστε ένα κλειδί στη διαμόρφωση της δοκιμαστικής εργασίας για να λάβετε αποτελέσματα κάλυψης (δείτε παρακάτω)
Κατά τη συσκευασία του κώδικα σε πακέτα nuget, ορίστε τον κατάλογο εξόδου για τα πακέτα: -o .

Συλλογή δεδομένων κάλυψης κωδικού

Μετά την εκτέλεση των δοκιμών, το Coverlet εκτυπώνει στατιστικά στοιχεία εκτέλεσης στην κονσόλα:

Calculating coverage result...
  Generating report 'C:Usersxxxsourcereposmy-projectmyProject.testscoverage.json'

+-------------+--------+--------+--------+
| Module      | Line   | Branch | Method |
+-------------+--------+--------+--------+
| project 1   | 83,24% | 66,66% | 92,1%  |
+-------------+--------+--------+--------+
| project 2   | 87,5%  | 50%    | 100%   |
+-------------+--------+--------+--------+
| project 3   | 100%   | 83,33% | 100%   |
+-------------+--------+--------+--------+

+---------+--------+--------+--------+
|         | Line   | Branch | Method |
+---------+--------+--------+--------+
| Total   | 84,27% | 65,76% | 92,94% |
+---------+--------+--------+--------+
| Average | 90,24% | 66,66% | 97,36% |
+---------+--------+--------+--------+

Το GitLab σάς επιτρέπει να καθορίσετε μια τυπική έκφραση για να λάβετε στατιστικά στοιχεία, τα οποία στη συνέχεια μπορούν να ληφθούν με τη μορφή σήματος. Η τυπική έκφραση καθορίζεται στις ρυθμίσεις εργασιών με το πλήκτρο coverage; η έκφραση πρέπει να περιέχει μια ομάδα λήψης, η τιμή της οποίας θα μεταβιβαστεί στο σήμα:

test and cover job:
  # snip
  coverage: /|s*Totals*|s*(d+[,.]d+%)/

Εδώ λαμβάνουμε στατιστικά στοιχεία από μια γραμμή με συνολική κάλυψη γραμμής.

Δημοσίευση πακέτων και τεκμηρίωσης

Και οι δύο ενέργειες έχουν προγραμματιστεί για το τελευταίο στάδιο του αγωγού - αφού η συναρμολόγηση και οι δοκιμές έχουν περάσει, μπορούμε να μοιραστούμε τις εξελίξεις μας με τον κόσμο.

Αρχικά, εξετάστε το ενδεχόμενο να δημοσιεύσετε στην πηγή του πακέτου:

Εάν το έργο δεν έχει αρχείο ρύθμισης παραμέτρων nuget (nuget.config), δημιουργήστε ένα νέο: dotnet new nugetconfig

Για τι: η εικόνα ενδέχεται να μην έχει πρόσβαση εγγραφής σε καθολικές διαμορφώσεις (χρήστης και μηχανής). Για να μην εντοπιστούν σφάλματα, απλώς δημιουργούμε μια νέα τοπική διαμόρφωση και εργαζόμαστε με αυτήν.
Ας προσθέσουμε μια νέα πηγή πακέτου στην τοπική διαμόρφωση: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
1. name - όνομα τοπικής πηγής, όχι κρίσιμο
2. url - URL της πηγής από το στάδιο "Προετοιμασία λογαριασμών", σελ. 6
3. organization - όνομα οργανισμού στο Azure DevOps
4. gitlab variable - το όνομα της μεταβλητής με το διακριτικό πρόσβασης που προστέθηκε στο GitLab ("Προετοιμασία λογαριασμών", σελ. 11). Φυσικά, στη μορφή $variableName
5. -StorePasswordInClearText - μια παραβίαση για παράκαμψη του σφάλματος απαγόρευσης πρόσβασης (Δεν είμαι ο πρώτος που πατάω σε αυτή τη γκανιότα)
6. Σε περίπτωση σφαλμάτων, ίσως είναι χρήσιμο να προσθέσετε -verbosity detailed
Αποστολή του πακέτου στην πηγή: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
1. Στέλνουμε όλα τα πακέτα από τον τρέχοντα κατάλογο, έτσι *.nupkg.
2. name - από το παραπάνω βήμα.
3. key - οποιαδήποτε γραμμή. Στο Azure DevOps, στο παράθυρο Connect to feed, το παράδειγμα είναι πάντα η γραμμή az.
4. -skipduplicate - όταν προσπαθείτε να στείλετε ένα ήδη υπάρχον πακέτο χωρίς αυτό το κλειδί, η πηγή θα εμφανίσει ένα σφάλμα 409 Conflict; με το κλειδί, η αποστολή θα παραλειφθεί.

Τώρα ας ρυθμίσουμε τη δημιουργία τεκμηρίωσης:

Αρχικά, στο αποθετήριο, στον κύριο κλάδο, αρχικοποιούμε το έργο docfx. Για να το κάνετε αυτό, εκτελέστε την εντολή από τη ρίζα docfx init και να ορίσετε διαδραστικά τις βασικές παραμέτρους για την τεκμηρίωση κτιρίου. Λεπτομερής περιγραφή της ελάχιστης ρύθμισης του έργου εδώ.
1. Κατά τη διαμόρφωση, είναι σημαντικό να καθορίσετε τον κατάλογο εξόδου ..public - Το GitLab από προεπιλογή παίρνει τα περιεχόμενα του δημόσιου φακέλου στη ρίζα του αποθετηρίου ως πηγή για τις Σελίδες. Επειδή το έργο θα βρίσκεται σε ένα φάκελο ένθετο στο αποθετήριο - προσθέστε μια έξοδο στο επίπεδο επάνω στη διαδρομή.
Ας προωθήσουμε τις αλλαγές στο GitLab.
Προσθέστε μια εργασία στη διαμόρφωση του αγωγού pages (δεσμευμένη λέξη για εργασίες δημοσίευσης ιστότοπου στις Σελίδες GitLab):
1. Γραφή:
  1. nuget install docfx.console -version 2.51.0 - εγκατάσταση docfx. η έκδοση καθορίζεται για να διασφαλιστεί ότι οι διαδρομές εγκατάστασης του πακέτου είναι σωστές.
  2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json - συλλογή εγγράφων
2. Αντικείμενα κόμβων:

pages:
  # snip
  artifacts:
    paths:
      - public

Λυρική παρέκβαση για το docfx

Προηγουμένως, κατά τη ρύθμιση ενός έργου, καθόριζα την πηγή κώδικα για την τεκμηρίωση ως αρχείο λύσης. Το κύριο μειονέκτημα είναι ότι δημιουργείται τεκμηρίωση και για δοκιμαστικά έργα. Σε περίπτωση που αυτό δεν είναι απαραίτητο, μπορείτε να ορίσετε αυτήν την τιμή στον κόμβο metadata.src:

{
  "metadata": [
    {
      "src": [
        {
          "src": "../",
          "files": [
            "**/*.csproj"
          ],
          "exclude":[
            "*.tests*/**"
          ]
        }
      ],
      // --- snip ---
    },
    // --- snip ---
  ],
  // --- snip ---
}

metadata.src.src: "../" - ανεβαίνουμε ένα επίπεδο σε σχέση με την τοποθεσία docfx.json, επειδή στα μοτίβα, η αναζήτηση στο δέντρο καταλόγου δεν λειτουργεί.
metadata.src.files: ["**/*.csproj"] - ένα παγκόσμιο μοτίβο, συλλέγουμε όλα τα έργα C # από όλους τους καταλόγους.
metadata.src.exclude: ["*.tests*/**"] - καθολικό μοτίβο, εξαιρέστε τα πάντα από φακέλους με .tests Στον τίτλο

ΜΕΡΙΚΟ ΣΥΝΟΛΟ

Μια τόσο απλή διαμόρφωση μπορεί να δημιουργηθεί σε μόλις μισή ώρα και μερικά φλιτζάνια καφέ, που θα σας επιτρέψει να ελέγξετε ότι ο κώδικας είναι κατασκευασμένος και οι δοκιμές περνούν, να δημιουργήσετε ένα νέο πακέτο, να ενημερώσετε την τεκμηρίωση και να ευχαριστήσετε το μάτι με όμορφα σήματα στο README του έργου με κάθε αίτημα συγχώνευσης και αποστολή στον κύριο.

Τελικό .gitlab-ci.yml

image: mcr.microsoft.com/dotnet/core/sdk:3.1

before_script:
  - $PSVersionTable.PSVersion
  - dotnet --version
  - nuget help | select-string Version

stages:
  - build
  - test
  - deploy

build job:
  stage: build
  script:
    - dotnet build -c Release
  tags:
    - windows
  only:
    - merge_requests
    - master
  artifacts:
    paths:
      - your/path/to/binaries

test and cover job:
  stage: test
  tags:
    - windows
  script:
    - dotnet test -c Release /p:CollectCoverage=true
  coverage: /|s*Totals*|s*(d+[,.]d+%)/
  only:
    - merge_requests
    - master

pack and deploy job:
  stage: deploy
  tags:
    - windows
  script:
    - dotnet pack -c Release -o .
    - dotnet new nugetconfig
    - nuget sources add -name feedName -source https://pkgs.dev.azure.com/your-organization/_packaging/your-feed/nuget/v3/index.json -username your-organization -password $nugetFeedToken -configfile nuget.config -StorePasswordInClearText
    - nuget push -source feedName -skipduplicate -apikey az *.nupkg
  only:
    - master

pages:
  tags:
    - windows
  stage: deploy
  script:
    - nuget install docfx.console -version 2.51.0
    - $env:path = "$env:path;$($(get-location).Path)"
    - .docfx.console.2.51.0toolsdocfx.exe .docfxdocfx.json
  artifacts:
    paths:
      - public
  only:
    - master

Μιλώντας για κονκάρδες

Εξαιτίας τους άλλωστε ξεκίνησαν όλα!

Σήματα με καταστάσεις αγωγών και κάλυψη κωδικών είναι διαθέσιμα στο GitLab στις ρυθμίσεις CI/CD στο μπλοκ αγωγών Gtntral:

Δημιούργησα ένα σήμα με έναν σύνδεσμο προς την τεκμηρίωση στην πλατφόρμα ασπίδες.io - όλα είναι αρκετά απλά εκεί, μπορείτε να δημιουργήσετε το δικό σας σήμα και να το λάβετε χρησιμοποιώντας ένα αίτημα.

![Пример с Shields.io](https://img.shields.io/badge/custom-badge-blue)

Το Azure DevOps Artifacts σάς επιτρέπει επίσης να δημιουργείτε σήματα για πακέτα με την πιο πρόσφατη έκδοση. Για να το κάνετε αυτό, στην πηγή στον ιστότοπο Azure DevOps, πρέπει να κάνετε κλικ στο Δημιουργία σήματος για το επιλεγμένο πακέτο και να αντιγράψετε τη σήμανση σήμανσης:

Προσθέτοντας ομορφιά

Επισήμανση κοινών τμημάτων διαμόρφωσης

Ενώ έγραφα τη διαμόρφωση και έψαχνα στην τεκμηρίωση, βρήκα ένα ενδιαφέρον χαρακτηριστικό του YAML - την επαναχρησιμοποίηση θραυσμάτων.

Όπως μπορείτε να δείτε από τις ρυθμίσεις εργασιών, όλες απαιτούν την ετικέτα windows στο runner και ενεργοποιούνται όταν αποστέλλεται ένα αίτημα συγχώνευσης στον κύριο/δημιουργημένο (εκτός από την τεκμηρίωση). Ας προσθέσουμε αυτό στο κομμάτι που θα επαναχρησιμοποιήσουμε:

.common_tags: &common_tags
  tags:
    - windows
.common_only: &common_only
  only:
    - merge_requests
    - master

Και τώρα μπορούμε να εισαγάγουμε το κομμάτι που δηλώθηκε νωρίτερα στην περιγραφή της εργασίας:

build job:
  <<: *common_tags
  <<: *common_only

Τα ονόματα των τμημάτων πρέπει να ξεκινούν με μια τελεία, ώστε να μην ερμηνεύονται ως εργασία.

Εκδόσεις πακέτων

Κατά τη δημιουργία ενός πακέτου, ο μεταγλωττιστής ελέγχει τους διακόπτες της γραμμής εντολών και, ελλείψει αυτών, τα αρχεία έργου. όταν βρίσκει έναν κόμβο Έκδοσης, παίρνει την αξία του ως έκδοση του πακέτου που δημιουργείται. Αποδεικνύεται ότι για να δημιουργήσετε ένα πακέτο με μια νέα έκδοση, πρέπει είτε να το ενημερώσετε στο αρχείο του έργου είτε να το περάσετε ως όρισμα γραμμής εντολών.

Ας προσθέσουμε μία ακόμη Λίστα επιθυμιών - αφήστε τους δύο δευτερεύοντες αριθμούς στην έκδοση να είναι το έτος και η ημερομηνία κατασκευής του πακέτου και προσθέστε εκδόσεις προέκδοσης. Φυσικά, μπορείτε να προσθέσετε αυτά τα δεδομένα στο αρχείο του έργου και να τα ελέγχετε πριν από κάθε υποβολή - αλλά μπορείτε επίσης να το κάνετε στη διαδικασία, συλλέγοντας την έκδοση του πακέτου από το περιβάλλον και περνώντας το μέσω του ορίσματος της γραμμής εντολών.

Ας συμφωνήσουμε ότι αν το μήνυμα δέσμευσης περιέχει μια γραμμή όπως release (v./ver./version) <version number> (rev./revision <revision>)?, τότε θα πάρουμε την έκδοση του πακέτου από αυτή τη γραμμή, θα τη συμπληρώσουμε με την τρέχουσα ημερομηνία και θα την περάσουμε ως όρισμα στην εντολή dotnet pack. Ελλείψει γραμμής, απλά δεν θα παραλάβουμε το πακέτο.

Το ακόλουθο σενάριο λύνει αυτό το πρόβλημα:

# регулярное выражение для поиска строки с версией
$rx = "releases+(v.?|ver.?|version)s*(?<maj>d+)(?<min>.d+)?(?<rel>.d+)?s*((rev.?|revision)?s+(?<rev>[a-zA-Z0-9-_]+))?"
# ищем строку в сообщении коммита, передаваемом в одной из предопределяемых GitLab'ом переменных
$found = $env:CI_COMMIT_MESSAGE -match $rx
# совпадений нет - выходим
if (!$found) { Write-Output "no release info found, aborting"; exit }
# извлекаем мажорную и минорную версии
$maj = $matches['maj']
$min = $matches['min']
# если строка содержит номер релиза - используем его, иначе - текущий год
if ($matches.ContainsKey('rel')) { $rel = $matches['rel'] } else { $rel = ".$(get-date -format "yyyy")" }
# в качестве номера сборки - текущие месяц и день
$bld = $(get-date -format "MMdd")
# если есть данные по пререлизной версии - включаем их в версию
if ($matches.ContainsKey('rev')) { $rev = "-$($matches['rev'])" } else { $rev = '' }
# собираем единую строку версии
$version = "$maj$min$rel.$bld$rev"
# собираем пакеты
dotnet pack -c Release -o . /p:Version=$version

Προσθήκη σεναρίου σε μια εργασία pack and deploy job και παρατηρήστε τη συναρμολόγηση των πακέτων αυστηρά παρουσία μιας δεδομένης συμβολοσειράς στο μήνυμα δέσμευσης.

Σε συνολικά

Αφού ξοδέψαμε περίπου μισή ώρα ή μία ώρα για να γράψουμε τη διαμόρφωση, τον εντοπισμό σφαλμάτων στο τοπικό powershell και, πιθανώς, μερικές ανεπιτυχείς εκκινήσεις, πήραμε μια απλή διαμόρφωση για την αυτοματοποίηση εργασιών ρουτίνας.

Φυσικά, το GitLab CI / CD είναι πολύ πιο εκτεταμένο και πολύπλευρο από ό,τι φαίνεται μετά την ανάγνωση αυτού του οδηγού - αυτό δεν είναι καθόλου αλήθεια. Εκεί ακόμη Το Auto DevOps είναιεπιτρέποντας

εντοπίζει αυτόματα, δημιουργεί, δοκιμάζει, αναπτύσσει και παρακολουθεί τις εφαρμογές σας

Τώρα τα σχέδια είναι να διαμορφωθεί ένας αγωγός για την ανάπτυξη εφαρμογών στο Azure, χρησιμοποιώντας το Pulumi και τον αυτόματο προσδιορισμό του περιβάλλοντος στόχου, το οποίο θα καλυφθεί στο επόμενο άρθρο.

Πηγή: www.habr.com

Ένας οδηγός για το CI/CD στο GitLab για τον (σχεδόν) απόλυτο αρχάριο