Eine neue Umgebung für jede Pull-Anfrage

Fast jedes Team, mit dem ich gearbeitet habe, hatte eine "Inszenierungs"-Umgebung. Und fast jedes Team hat in Slack das gleiche Gespräch geführt: "Wer hat in die Inszenierung eingesetzt? Meine Änderungen sind weg". "Können Sie eine Stunde nicht einsetzen, ich teste etwas?" "Die Inszenierung ist wieder kaputt, weiß jemand warum?"

Eine gemeinsame Umgebung für viele Entwickler schafft einen Engpass. Vorschaumöglichkeiten beseitigen diesen Engpass.

Warum gemeinsame Inszenierung schadet

• Veränderungen kollidieren. Zwei Feature-Zweige, die an derselben Stelle bereitgestellt werden, überschreiben sich gegenseitig.
• Es ist immer leicht kaputt. Irgendjemandes halb fertiges Wechselgeld ist immer da.
• Die Rückmeldung ist langsam. Rezensenten, Tester und Produktmanager können keine Veränderung sehen, bis sie zusammengeführt wird.
• Niemand vertraut ihm. Und eine Umgebung, der niemand vertraut, ist eine Umgebing, in der niemand richtig testet.

Wie Vorsicht-Umgebungen funktionieren

Die Idee ist einfach. Wenn eine Pull-Anfrage geöffnet wird, erstellt die Pipeline eine temporäre Kopie der Anwendung nur für diesen Zweig, mit seiner eigenen URL wie pr-142.preview.example.com- Ich weiß . Wenn die Pull-Anfrage zusammengeführt oder geschlossen wird, wird die Umgebung gelöscht.

Auf Kubernetes gibt es einige übliche Möglichkeiten, dies zu bauen:

Ein Namensraum pro Zuganfrage. Der einfachste Ansatz. Die Pipeline erstellt einen Namespace, stellt das Helm-Chart mit dem Bildtag des Zweigs bereit und setzt einen Eingang oder HTTPRoute für den Vorschauhostnamen ein.

Argo CD ApplicationSets mit dem Pull-Request-Generator. Argo CD beobachtet Ihr Repository und erstellt automatisch eine Anwendung für jede offene Pull-Anfrage und entfernt sie, wenn die PR geschlossen wird. Keine benutzerdefinierten Skripte.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: shop-previews
spec:
  generators:
  - pullRequest:
      github:
        owner: my-org
        repo: shop
      requeueAfterSeconds: 120
  template:
    metadata:
      name: 'shop-pr-{{number}}'
    spec:
      project: previews
      source:
        repoURL: https://github.com/my-org/shop
        targetRevision: '{{head_sha}}'
        path: deploy/chart
        helm:
          parameters:
          - name: image.tag
            value: '{{head_sha}}'
          - name: ingress.host
            value: 'pr-{{number}}.preview.example.com'
      destination:
        server: https://kubernetes.default.svc
        namespace: 'shop-pr-{{number}}'
      syncPolicy:
        automated: { prune: true }
        syncOptions: [CreateNamespace=true]

Virtuelle Cluster (vCluster) werden verwendet. Wenn Teams Cluster-Ebene Ressourcen wie CRDs benötigen, bietet ein virtueller Cluster pro Pull-Anfrage vollständige Isolation, ohne jedes Mal für einen echten Cluster zu bezahlen.

Der beste Kommentar ist "Ich habe es durchklickt und es funktioniert", und Vorschaumöglichkeiten machen das möglich, bevor man es zusammenführt.

Daten und Geheimnisse: der schwierige Teil

Die App zu implementieren ist der einfache Teil. Die schwierigen Fragen:

• Datenbanken. Die Optionen reichen von einem kleinen Datenbankcontainer mit Testdaten über eine gemeinsame Datenbank mit einem separaten Schema pro PR bis hin zu Schnappschüssen eines anonymisierten Datensatzes. Vervielfältigen Sie niemals Produktionsdaten mit persönlichen Daten in Vorschauen.
• Außendienstleistungen. Zahlungsdienstleister, E-Mails, API's von Drittanbietern. Verwenden Sie Sandbox-Konten oder Spottkonten.
• Geheimnisse. Vorschauen sollte seine eigenen begrenzten Anmeldeinformationen bekommen, idealerweise durch Externe Geheimnisse oder Ihren geheimen Manager, nicht Kopien von Inszenierungsgeheimnissen.
• Wildcard DNS und TLS. Ein Wildcard-Rekord wie *.preview.example.com und ein Wildcard-Zertifikat (cert-Manager kümmert sich um das) machen neue Hostnamen sofort funktionieren.

Ich räume auf, damit die Rechnung klein bleibt.

Vorschaumöglichkeiten können ruhig teuer werden. 50 offene Zugwünsche bedeuten 50 Kopien deiner App.

Was hilft:

• Stell dich immer ganz nah. ApplicationSets tun dies automatisch. Mit Skript stellen Sie sicher, dass der Aufräumvorgang läuft, auch wenn die Pipeline ausfällt.
• Zeit zum Leben. Löschen Sie Vorschauen, die seit ein paar Tagen nicht aktualisiert wurden, auch wenn die PR noch offen ist.
• Wenige Ressourcen. Vorführungen brauchen keine Produktionsgröße. Eine Kopie, wenig Anfragen.
• Spot- oder vorbehaltlich der Vorgabe verfügbare Knoten für den Vorabbericht-Nodengrund.
• Skala auf Null Nachts mit einer einfachen geplanten Arbeit oder mit Werkzeugen, die Umgebungen auf der ersten Anfrage wecken.

Also, ist es das wert?

Für Teams mit mehr als ein paar Entwicklern, die parallel arbeiten, ja. Die Bewertungen werden besser, die Tests kommen früher und die "Wer brach die Inszenierung" -Nachrichten verschwinden. Beginnen Sie mit einem Namespace pro PR, fügen Sie Daten hinzu und bereinigen Sie richtig, und wachsen Sie von dort aus.

Ich sage: Jeder Veränderung seine eigene Welt. Es ist billiger als die Zeit, die dein Team verliert, um auf die Inszenierung zu warten.

Desly