Σύγχρονες στρατηγικές απελευθέρωσης με δράσεις GitHub (ελληνικά (Greek))

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

Ο οδηγός αυτός καλύπτει τις στρατηγικές απελευθέρωσης που χρησιμοποιώ στην παραγωγή, από απλές εφαρμογές βασισμένες σε ετικέτες έως εκδόσεις πολλαπλών πακέτων Monorepo. Ενέργειες GitHub Ροές εργασίας σε αυτό το αποθετήριο.

Στρατηγικές απελευθέρωσης με μια ματιά

Πριν από την κατάδυση σε λεπτομέρειες, εδώ είναι πώς οι κοινές στρατηγικές συγκρίνουν:

Στρατηγική ~ Καλύτερη για την πολυπλοκότητα ~ Κοινή σε ~ |----------|----------|------------|-----------| | Με βάση την ετικέτα □ Εφαρμογές, σαφείς κυκλοφορίες □ Χαμηλές startups, σόλο devs, ώριμες ομάδες | Υποκατάστημα με βάση ~ Συνεχής ανάπτυξη ~ Χαμηλές startups, γρήγορες μετακινούμενες ομάδες ~ | GitFlow Ρυθμισμένες κυκλοφορίες, πολλαπλές εκδόσεις Υψηλό επίπεδο επιχειρήσεων, συμμόρφωση-βαρύς | Σημαίες με βάση το πορτ-μπαγκάζ + χαρακτηριστικά Οι ομάδες υψηλής ταχύτητας Μεσαία Μεγάλη τεχνολογία, ώριμες startups | Monorepo πολυσυσκευές Βιβλιοθήκες, κοινές codebases □ Μεσαίες ομάδες πλατφόρμας, OSS projects

Τι Λειτουργεί Πού

Startups & Μικρές Ομάδες: Ξεκινήστε με tag-based ή branch-based ανάπτυξη. Κρατήστε το απλό - μπορείτε πάντα να προσθέσετε πολυπλοκότητα αργότερα. Trunk-based ανάπτυξη με σημαίες χαρακτηριστικό είναι δημοφιλής σε κλίμακα, αλλά υπερβολή για μικρές ομάδες.

ΕντερπράιζCity name (optional, probably does not need a translation): Συχνά απαιτεί GitFlow ή παρόμοια για τη συμμόρφωση, μονοπάτια ελέγχου, και τη διαχείριση απελευθέρωσης. Πολλαπλά περιβάλλοντα (dev, QA, stageing, prod) με πύλες έγκρισης.

Solo DevelopersΣπρώξε μια ετικέτα, η ανάπτυξη θα γίνει χωρίς τελετή, χωρίς έξοδα.

Πλατφόρμα/Ομάδες Βιβλιοθήκης: Need monorepo στρατηγικές με ανεξάρτητη έκδοση ανά πακέτο. Σημασιολογική έκδοση είναι κρίσιμη για τους μεταγενέστερους καταναλωτές.

Tag-Based Development

Η απλούστερη και πιο αξιόπιστη στρατηγική. Διαφορετική ετικέτα προθέτει διαδρομή σε διαφορετικά περιβάλλοντα ή ενεργοποιούν διαφορετικές δράσεις.

Στόχος για το περιβάλλον

on:
  push:
    tags:
      - 'release-*'  # Production
      - 'local-*'    # Dev environment

- name: Build Docker image
  run: |
    TAG_NAME=${GITHUB_REF#refs/tags/}
    if [[ "$TAG_NAME" == local-* ]]; then
      docker build -t myapp:local .
    else
      docker build -t myapp:latest -t myapp:$(date +%s) .
    fi

Γιατί δουλεύει;: Απλό νοητικό μοντέλο, ρητή ανάπτυξη, εύκολο rollback μέσω χρονοσφραγισμένων ετικετών.

# Deploy to production
git tag release-v2024.12.01 && git push origin release-v2024.12.01

# Deploy to dev
git tag local-feature-test && git push origin local-feature-test

Multi-Package Versioning

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

# Different workflows, different tag patterns
# umami-net.yml
on:
  push:
    tags: ['umamiv*.*.*']  # e.g., umamiv1.0.5

# fetchextension.yml
on:
  push:
    tags: ['fetchextension-v*.*.*']  # e.g., fetchextension-v1.2.0

Απόσπασμα της έκδοσης και χρήση της σε:

- name: Extract version
  run: echo "VERSION=${GITHUB_REF#refs/tags/umamiv}" >> $GITHUB_OUTPUT

- name: Build & Pack
  run: |
    dotnet build -c Release -p:Version=${{ steps.version.outputs.VERSION }}
    dotnet pack -c Release -p:PackageVersion=${{ steps.version.outputs.VERSION }}

Για αυτόματη έκδοση, MinVerCity name (optional, probably does not need a translation) υπολογίζει τις εκδόσεις από τις ετικέτες Git:

<PackageReference Include="MinVer" Version="6.0.0" PrivateAssets="all" />
<PropertyGroup>
  <MinVerTagPrefix>umamiv</MinVerTagPrefix>
</PropertyGroup>

Αναπτύξεως Υποκατάστηματος

Αναπτύξτε αυτόματα όταν ο κώδικας προσγειώνεται σε συγκεκριμένους κλάδους.

on:
  push:
    branches: [main]      # → Production
    # branches: [develop] # → Staging

Pros: Δεν υπάρχει χειροκίνητο βήμα, αναπτύσσεται σε συγχώνευση ΚονςCity name (optional, probably does not need a translation): Τυχαία ανάπτυξη πιθανή, λιγότερο ρητή ιστορία

Χρησιμοποιώ μια υβριδική προσέγγιση - χτίζεται σε κλαδί ώθηση (επιβεβαίωση CI), αλλά δημοσιεύει μόνο σε ετικέτες:

on:
  push:
    tags: ['scheduler-*']
    branches: [main, local]

jobs:
  build:
    # Always build
  publish:
    if: startsWith(github.ref, 'refs/tags/')  # Only publish on tags

Αυτόματες ενημερώσεις με το Παρατηρητήριο

Για αυτοξεχωριζόμενες αποστολές, Σκοπιά αυτόματα τραβάει νέες εικόνες:

services:
  app:
    image: myapp:latest
    labels:
      - "com.centurylinklabs.watchtower.enable=true"

  watchtower:
    image: containrrr/watchtower
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    command: --interval 300  # Check every 5 minutes

Ροή ανάπτυξης→ Πιέστε την ετικέτα → GitHub Δράσεις → Πιέστε στο μητρώο → Τραβάει η Σκοπιά → επανεκκινεί Container. Συνολικός χρόνος: ~5 λεπτά.

Πύλες ποιότητας

Κάθε ροή εργασίας θα πρέπει να περιλαμβάνει πύλες:

- name: Run tests
  run: dotnet test --configuration Release

- name: Build
  run: dotnet build --configuration Release

# Tests or build fail → workflow stops → no publish

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

- run: dotnet build -c Release --framework net8.0
- run: dotnet build -c Release --framework net9.0

Έκδοση χωρίς κωδικό πρόσβασης με OIDC

Σύγχρονη προσέγγιση - χωρίς μυστικά για περιστροφή, χωρίς κλειδιά για διαρροή:

permissions:
  id-token: write
  contents: read

- uses: NuGet/login@v1
  with:
    user: 'myusername'

- run: dotnet nuget push *.nupkg --api-key ${{ steps.login.outputs.NUGET_API_KEY }}

Το GitHub ανταλλάσσει το OIDC του με ένα σύντομο κλειδί NuGet API. Ρυθμίστε την εμπιστοσύνη στο NuGet.org για να το ενεργοποιήσετε αυτό.

Ασφάλεια εφοδιαστικής αλυσίδας

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

permissions:
  id-token: write
  attestations: write

- uses: docker/build-push-action@v6
  id: push
  with:
    push: true
    tags: myapp:latest

- uses: actions/attest-build-provenance@v2
  with:
    subject-name: index.docker.io/myuser/myapp
    subject-digest: ${{ steps.push.outputs.digest }}
    push-to-registry: true

Οι καταναλωτές ελέγχουν με: gh attestation verify oci://index.docker.io/myuser/myapp:latest --owner myuser

Αυτό εpiιτυγχάνει SLSA Επίπεδο 2. Για το επίπεδο 3, χρήση Επαναχρησιμοποιούμενες ροές εργασίας.

Προεπισκόπηση Περιβάλλοντα

Οι ομάδες χρειάζονται τα ενδιαφερόμενα μέρη να προεπιθεωρήσουν τις αλλαγές πριν από τη συγχώνευση.

Προσέγγιση των επιχειρήσεων - Περιβάλλοντα προεπισκόπησης με βάση τα υποκαταστήματα:

on:
  pull_request:
    types: [opened, synchronize]

- run: |
    BRANCH=$(echo ${{ github.head_ref }} | sed 's/[^a-zA-Z0-9]/-/g')
    docker build -t myapp:preview-$BRANCH .
    # Deploy to k8s namespace, cloud platform, etc.

Εκκίνηση/προσέγγιση σόλο - Τούνελ τοπική μηχανή σας:

# Cloudflare Tunnel (free)
cloudflared tunnel run --url http://localhost:5000 my-preview
# → https://my-preview.cfargotunnel.com

Ή χρήση Συρματόσχοινα VPN για την εσωτερική ομάδα πρόσβαση στη μηχανή dev σας.

Πρακτικές Συμβουλές

Καθαρισμός ετικετών: Git tags stay around forever.

git tag -d old-test-tag                      # Delete local
git push origin :refs/tags/old-test-tag      # Delete remote

Συνέδρια ονοματοδοσίας: Να είστε συνεπείς.

release-YYYY.MM.DD για παραγωγή
local-feature-name για τον Dev
packagev1.2.3 για βιβλιοθήκες

Μυστικά: Να φυλάσσεται σε GitHub SecretsΑπαιτούμενα μυστικά συνήθως:

DOCKER_HUB_ACCESS_TOKEN
NUGET_API_KEY (ή χρήση OIDC)
NPM_TOKEN

Ανάπτυξη Monorepo: Χρησιμοποιήστε αναφορές έργου κατά τη διάρκεια της ανάπτυξης, μεταβείτε σε αναφορές πακέτου για επαλήθευση ανάπτυξης:

<ProjectReference Include="..\MyLib\MyLib.csproj" />
<!-- <PackageReference Include="MyLib" Version="1.0.0" /> -->

Μετακίνηση στο Kubernetes

Ίδιες αρχές, διαφορετικά εργαλεία:

Docker Compose Kubernetes |----------------|------------| Σκοπιά (στην Αγγλική) (στην Αγγλική) (στην Αγγλική) (στην Αγγλική) (στην Αγγλική) (στην Αγγλική) (στην Αγγλική) (στην Αγγλική) (στην Αγγλική) (στην Αγγλική) (στην Αγγλική) (στην Αγγλική) (στην Αγγλική) (στην Αγγλική) (στην Αγγλική) (στην Αγγλική) (στην Αγγλική (στην Αγγλική) (στην Αγγλική) (στην Αγγλική) (στην Αγγλική (στην Αγγλική) (στην Αγγλική) (στην Αγγλική (στην Αγγλική) (στην Αγγλική) (στην Αγγλική) (στην Αγγλική (στην Αγγλική) (στην Αγγλική) (στην Αγγλική) (στην Αγγλική) (στην Αγγλική) (στην Αγγλική) (στην Αγγλική) (στην Αγγλική) (στην Αγγλική (στην Αγγλική) (στην Αγγλική) (στην Αγγλική) (στην Αγγλική) (στην Αγγλική) ArgoCD / ΦλουξCity name (optional, probably does not need a translation) | ~ Docker-compose.yml περιβάλλοντα ~ Namespaces ~ Ο Container επανεκκινεί το Rolling development ~ Εγχειρίδιο rollback ~ GitOps rollback ~

Περίληψη

Ξεκινήστε απλά: Tag-based ανάπτυξη καλύπτει τις περισσότερες ανάγκες
Προσθήκη πολυπλοκότητας όταν απαιτείται: Καταστηματικές, πολυπεριβαλλοντικές, πιστοποιήσεις
Αυτόματες πύλες ποιότητας: Οι δοκιμές πρέπει να περάσουν πριν από τη δημοσίευση
Ενεργοποίηση αναστροφής: Timestamped tags or GitOps history
Ασφαλίστε τον αγωγό σας.: OIDC για μυστικά, πιστοποιήσεις για προέλευση
Ταιριάξτε τα συμφραζόμενα σας: Solo dev

Οι ροές εργασίας που εμφανίζονται εδώ εκτελούνται σε αυτό το αποθετήριο - έλεγχος .github/workflows/ για πλήρεις εφαρμογές.

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