freeCodeCamp/docs/i18n/German/devops.md

Entwickleroperationen auf FreeCodeCamp.org

Dieser Leitfaden wird Ihnen helfen, unseren Infrastruktur-Stapel zu verstehen und wie wir unsere Plattformen pflegen. Obwohl diese Anleitung nicht über vollständige Details für alle Operationen verfügt, könnte sie als Referenz für Ihr Verständnis der Systeme verwendet werden.

Teilen Sie uns mit, wenn Sie Feedback oder Fragen haben, und wir werden gerne klären.

Wie können wir die Codebase bauen, testen und bereitstellen?

Dieses Projektarchiv wird kontinuierlich erstellt, getestet und in separate Infrastruktur-Sätze (Server, Datenbanken, CDNs, etc.) eingesetzt bereitgestellt.

Dies beinhaltet drei Schritte, die nacheinander verfolgt werden müssen:

1. Neue Änderungen (Fixes und Features) werden über Pull-Requests in unserem primären Entwicklungszweig (Master) zusammengeführt.
2. Diese Änderungen werden durch eine Reihe automatisierter Tests durchgeführt.
3. Sobald die Tests bestanden, werden die Änderungen freigegeben (oder bei Bedarf aktualisiert).

Bau der Codebase - Mapping Git Branches to Deployments.

Normalerweise Master (der Standard-Entwicklungszweig) wird einmal täglich in den Produktions-Staging Branch zusammengeführt und in eine isolierte Infrastruktur freigesetzt.

Dies ist eine Zwischenveröffentlichung für unsere Entwickler und Freiwillige. Es ist auch bekannt als unsere "Inszenierung" oder "Beta" Release.

Es ist identisch mit unserer Live-Produktionsumgebung unter freeCodeCamp.org, außer mit einem separaten Satz von Datenbanken, Servern, Webproxies usw. Diese Isolierung ermöglicht es uns, laufende Entwicklungen und Features in einem "Produktion" wie dem Szenario zu testen, ohne die normalen Benutzer der Hauptplattformen von FreeCodeCamp.org zu beeinträchtigen. Diese Isolierung ermöglicht es uns, laufende Entwicklungen und Features in einem "Produktion" wie dem Szenario zu testen, ohne die normalen Benutzer der Hauptplattformen von FreeCodeCamp.org zu beeinträchtigen.

Sobald das Entwicklerteam @freeCodeCamp/dev-team mit den Änderungen auf der Staging-Plattform zufrieden ist, diese Änderungen werden alle paar Tage in den Produktionszweig `` verschoben.

Dies ist die finale Veröffentlichung, die Änderungen an unseren Produktionsplattformen auf FreeCodeCamp.org verschiebt.

Testing changes - Integration und User Acceptance Testing.

Um die Qualität des Codes zu überprüfen, setzen wir verschiedene Integrations- und Akzeptanzstufen ein. Alle unsere Tests werden mit Software wie Travis CI und Azure Pipelines durchgeführt.

Wir haben Unit-Tests zum Testen unserer Challenge-Lösungen, Server-APIs und Client-Benutzeroberflächen. Diese helfen uns, die Integration zwischen verschiedenen Komponenten zu testen.

[!HINWEIS] Wir sind auch dabei, Endanwender-Tests zu schreiben, die dazu beitragen, reale Weltszenarien wie das Aktualisieren einer E-Mail oder einen Aufruf an die API oder die Dienste von Drittanbietern zu replizieren.

Zusammen helfen diese Tests zu verhindern, dass sich Probleme wiederholen und stellen sicher, dass wir keinen Fehler einführen, während wir an einem anderen Fehler oder einer Funktion arbeiten.

Weitergabe von Änderungen - Pushing Änderungen an Server.

Wir haben kontinuierliche Liefersoftware so konfiguriert, dass Änderungen an unseren Entwicklungs- und Produktionsservern beschleunigt werden.

Sobald die Änderungen in die geschützten Versionszweige gedrückt werden, wird automatisch eine Build-Pipeline für den Zweig ausgelöst. Die Pipelines sind dafür verantwortlich, Artefakte zu bauen und sie für einen späteren Gebrauch in einem Kaltlager zu halten.

Die Build-Pipeline löst eine entsprechende Release-Pipeline aus, wenn sie einen erfolgreichen Lauf abschließt. Die Release-Pipelines sind dafür verantwortlich, die Build-Artefakte zu sammeln, sie auf die Server zu verschieben und live zu gehen.

Status of builds and releases are available here.

Ein Build, Test und Deployment auslösen.

Derzeit können nur Mitglieder des Entwicklerteams in die Produktionsbranchen schieben. Die Änderungen an den -Produktions-* Zweigen können nur über Schnellweiterleitung in den Upstream landen.

[!HINWEIS] In den kommenden Tagen würden wir diesen Fluss verbessern, der über Pull-Requests erfolgen soll, um das Zugangsmanagement und die Transparenz zu verbessern.

Änderungen an Staging Applikationen schieben.

1. Konfigurieren Sie Ihre Fernbedienungen richtig.

   git remote -v
   

   Ergebnisse:

   origin git@github.com:raisedadead/freeCodeCamp.git (fetch)
   origin git@github.com:raisedadead/freeCodeCamp.git (push)
   upstream git@github.com:freeCodeCamp/freeCodeCamp.git (fetch)
   upstream git@github.com:freeCodeCamp/freeCodeCamp.git (push)
   

2. Vergewissern Sie sich, dass Ihr Master Branch unverändert und mit dem Upstream synchronisiert ist.

   git Checkout Master
   git retriech --all --prune
   git reset --hard upstream/master
   

3. Überprüfen Sie, ob der Travis CI den Master Branch für den Upstream weitergibt.

   Die kontinuierlichen Integrations- Tests sollten grün und PASSING für den Master Zweig sein.

   Überprüfe den Status auf Travis CI (Screenshot)

   
   

   Wenn dies fehlschlägt, sollten Sie aufhören und die Fehler untersuchen.

4. Bestätigen Sie, dass Sie das Projektarchiv lokal erstellen können.

   npm laufen sauber und entwickeln
   

5. Änderungen von master auf Production-Staging über eine Schnell-Forware-Merge verschieben

   git checkout Production-Staging
   git merge master
   git push upstream
   

   [!HINWEIS] Du wirst nicht in der Lage sein, Push zu erzwingen und wenn du den Verlauf auf jeden Fall neu geschrieben hast, werden diese Befehle fehlerhaft sein.

   Wenn das der Fall ist, haben Sie möglicherweise etwas falsch gemacht, und Sie sollten einfach neu anfangen.

The above steps will automatically trigger a run on the build pipeline for the production-staging branch. Sobald die Erstellung abgeschlossen ist, werden die Artefakte als .zip Dateien in einem kalten Speicher gespeichert, der später abgerufen und verwendet wird.

Die Release-Pipeline wird automatisch ausgelöst, wenn ein neues Artefakt über die angeschlossene Build-Pipeline verfügbar ist. Für Staging-Plattformen erfordert dieser Prozess keine manuelle Freigabe und die Artefakte werden auf den Client CDN und API-Server geschoben.

[!TIP|label:Estimates] Der Build-Run dauert normalerweise ~20-25 Minuten, um den Release-Run abzuschließen, der ~15-20 Minuten dauert, für den Client und ~5-10 Minuten für die API verfügbar sein. Vom Code-Push bis zum Live Live auf den Staging-Plattformen dauert der gesamte Prozess ~35-45 Minuten insgesamt.

Pushing von Änderungen an Produktionsanwendungen.

Der Prozess ist meist identisch mit den Staging-Plattformen, wobei einige zusätzliche Kontrollen durchgeführt werden. Dies ist nur, um sicherzustellen, dass wir nichts auf freeCodeCamp.org kaputt machen, das jederzeit hunderte von Benutzern sehen kann, die es verwenden.

Führen Sie diese Befehle NICHT aus, es sei denn, Sie haben überprüft, dass alles auf der Staging-Plattform funktioniert. Du solltest keine Tests auf Staging umgehen oder überspringen, bevor du weiter fortfährst.

1. Vergewissern Sie sich, dass Ihr -Produktions-Staging- Zweig unberührt und mit dem Upstream synchronisiert ist.

   git checkout Production-Staging
   git fetch --all --prune
   git reset --hard upstream/production-staging
   

2. Änderungen von Produktionsphase auf Produktionsstrom verschieben durch Schnell-Forware-Zusammenführung

   git checkout produktion-current
   git merge production-staging
   git push upstream
   

   [!HINWEIS] Du wirst nicht in der Lage sein, Push zu erzwingen und wenn du den Verlauf auf jeden Fall neu geschrieben hast, werden diese Befehle fehlerhaft sein.

   Wenn das der Fall ist, haben Sie möglicherweise etwas falsch gemacht, und Sie sollten einfach neu anfangen.

Die obigen Schritte werden automatisch einen Run auf die Build-Pipeline für den Produktionsstrom-Branch auslösen. Sobald ein Build-Artefakt fertig ist, wird es einen Run auf die Release-Pipeline auslösen.

[!TIP|label:Estimates] Der Build-Run dauert normalerweise ~20-25 Minuten.

Zusätzliche Schritte für die Personalaktion

Ein Release-Run wird ausgelöst, Mitglieder des Entwicklerteams erhalten eine automatisierte manuelle Interventions-E-Mail. They can either approve or reject the release run.

Wenn die Änderungen gut funktionieren und auf der Staging-Plattform getestet wurden, kann sie genehmigt werden. Die Genehmigung muss innerhalb von 4 Stunden nach dem Auslösen der Veröffentlichung erteilt werden, bevor sie automatisch abgelehnt wird. Ein Stab kann die Freigabe manuell für abgelehnte Läufe auslösen oder auf den nächsten Release-Zyklus warten.

Für Personalnutzung:

Überprüfen Sie Ihre E-Mail für einen direkten Link oder gehen Sie zum Release-Dashboard nachdem der Build-Run abgeschlossen ist.

Sobald einer der Mitarbeiter eine Veröffentlichung genehmigt, wird die Pipeline die Änderungen live auf FreeCodeCamp.orgs Produktions-CDN- und API-Server übertragen. Sie benötigen normalerweise ~15-20 Minuten für den Client, und ~5 Minuten für die Verfügbarkeit der API-Server.

[!TIP|label:Estimates] Der Release-Run benötigt normalerweise ~15-20 Minuten für jede Clientinstanz, und ~5-10 Minuten für jede API-Instanz, um live verfügbar zu sein. Vom Code-Push bis zum Live-Betrieb auf den Produktionsplattformen dauert der gesamte Prozess ~90-120 Minuten (ohne die Wartezeit auf die Genehmigung des Personals zu zählen).

Bau-, Test- und Einsatzstatus

Hier ist der aktuelle Test-, Build-und Bereitstellungsstatus der Codebase.

Typ	Zweig	Status	Dashboard
CI Tests	master		Zum Status Dashboard wechseln
CI Tests	produktionsphase		Zum Status Dashboard wechseln
Pipeline bauen	produktionsphase		Zum Status Dashboard wechseln
Pipeline freigeben	produktionsphase		Zum Status Dashboard wechseln
CI Tests	produktionstrom-Strom		Zum Status Dashboard wechseln
Pipeline bauen	produktionstrom-Strom		Zum Status Dashboard wechseln
Pipeline freigeben	produktionstrom-Strom		Zum Status Dashboard wechseln

Früher Zugriff und Betatest

Wir freuen uns, dass Sie diese Versionen im "Public Beta testing" Modus testen und frühzeitigen Zugriff auf die kommenden Funktionen auf den Plattformen erhalten. Manchmal werden diese Funktionen/Änderungen als , Beta, Staging, usw. bezeichnet.

Deine Beiträge durch Feedback und Fehlerberichte werden uns helfen, die Produktionsplattformen unter freeCodeCamp zu erstellen. rg mehr widerstandsfähig, konsistent und stabil für alle.

Wir danken Ihnen für die Fehlermeldung, auf die Sie stoßen, und helfen Ihnen FreeCodeCamp.org zu verbessern. Du rockst!

Identifizierung der kommenden Version der Plattformen

Derzeit ist eine öffentliche Beta-Testversion verfügbar:

freecodecamp.dev

[!HINWEIS] Der Domainname unterscheidet sich von freeCodeCamp.org. Dies ist beabsichtigt, die Indexierung von Suchmaschinen zu verhindern und Verwirrung für normale Benutzer der Plattform zu vermeiden.

Identifizierung der aktuellen Version der Plattformen

Die aktuelle Version der Plattform ist immer verfügbar unter freeCodeCamp.org.

Das dev-team führt Änderungen vom -Produktions-Staging- Branch zu Produktions-Strom , wenn sie freigegeben werden. Der beste Commit sollte sein, was du live auf der Seite siehst.

Sie können die genaue Version ermitteln, indem Sie die Build- und Bereitstellungsprotokolle im Abschnitt Status aufrufen. Alternativ kannst du uns auch im Mitwirkenden Chatraum um eine Bestätigung zu erhalten.

Bekannte Einschränkungen

Es gibt einige bekannte Einschränkungen und Kompromisse bei der Beta-Version der Plattform.

• All data / personal progress on these beta platforms will NOT be saved or carried over to production.

  Benutzer der Beta-Version werden ein separates Konto von der Produktion haben. Die Beta-Version verwendet eine physikalisch getrennte Datenbank von der Produktion. Dies gibt uns die Möglichkeit, zufällige Datenverluste oder Änderungen zu verhindern. Das Entwicklerteam kann die Datenbank auf dieser Beta-Version gegebenenfalls löschen.

• Es gibt keine Garantien für die Laufzeit und die Zuverlässigkeit der Beta-Plattformen.

  Es wird erwartet, dass die Einsatzbereitschaft häufig und in raschen Iterationen erfolgt, manchmal mehrmals am Tag. Infolgedessen wird es zu unerwarteten Ausfallzeiten oder zu kaputten Funktionalitäten auf der Beta-Version kommen.

• Senden Sie keine regulären Benutzer auf diese Seite um eine Korrektur zu bestätigen

  Die Beta-Seite ist und war es immer gewesen, lokale Entwicklung und Testing, nichts anderes. Es ist kein Versprechen, was kommt, sondern ein Blick auf das, woran man arbeitet.

• Zeichenseite kann anders aussehen als die Produktion

  Wir verwenden einen Test-Mieter für freecodecamp.dev auf Auth0 und haben daher nicht die Möglichkeit, eine eigene Domain zu setzen. Dies macht es so dass alle Redirect Callbacks und die Login-Seite auf einer Standard-Domain erscheinen wie: https://freecodecamp-dev.auth0.com/. Dies hat keinen Einfluss auf die Funktionalität ist so nah an der Produktion, wie wir erhalten können.

Fehler melden und Feedback hinterlassen

Bitte öffnen Sie neue Ausgaben für Diskussionen und Fehlermeldungen. Sie können sie als Release benennen: next/beta für Triage.

Sie können eine E-Mail an dev[at]freecodecamp.org senden, wenn Sie Fragen haben. Wie immer sollten alle Sicherheitslücken an security[at]freecodecamp.org anstatt an den öffentlichen Tracker und Forum gemeldet werden.