Haben Sie die Git-Befehle gelernt, möchten aber verstehen, wie kontinuierliche Integration (Continuous Integration, CI) in der Praxis funktioniert? Oder möchten Sie Ihre täglichen Abläufe optimieren? Dieser Kurs vermittelt Ihnen praktische Fähigkeiten in kontinuierlicher Integration mithilfe eines Repositories auf GitHub. Der Kurs ist nicht als reiner Wizard gedacht, den man einfach durchklicken kann; stattdessen werden Sie die gleichen Schritte durchführen, die Menschen tatsächlich in ihrem Job machen, auf die gleiche Weise, wie sie es tun. Ich werde die Theorie erklären, während Sie die relevanten Schritte durchlaufen.

Was werden wir tun?

Während des Kurses werden wir schrittweise eine Liste typischer CI-Schritte erstellen, was eine hervorragende Möglichkeit ist, sich diese einzuprägen. Mit anderen Worten, wir werden eine Liste von Aktionen erstellen, die Entwickler durchführen, um kontinuierliche Integration zu realisieren. Außerdem werden wir einen einfachen Satz von Tests einsetzen, um unseren CI-Prozess der Realität näher zu bringen.

Dieses GIF zeigt schematisch die Commits in Ihrem Repository während des Fortschreitens des Kurses. Wie Sie sehen, ist hier nichts kompliziert und nur das Notwendigste.

Sie werden mit den typischen CI-Szenarien arbeiten:

• Arbeit an Funktionen;
• Anwendung von automatisierten Tests zur Qualitätssicherung;
• Umsetzung einer priorisierten Aufgabe;
• Behebung von Merge-Konflikten;
• Fehler im Produktionsumfeld.

Was werden Sie lernen?

Sie werden Fragen beantworten können wie:

• Was ist Continuous Integration (CI)?
• Welche Arten von automatisierten Tests werden bei CI verwendet, und auf welche Aktionen werden sie ausgelöst?
• Was ist ein Pull Request und wann wird er benötigt?
• Was ist testgetriebene Entwicklung (Test Driven Development, TDD) und wie steht sie im Zusammenhang mit CI?
• Soll man mergen oder Änderungen rebasen?
• Soll man zurückrollen oder im nächsten Release beheben?

Anfangs habe ich überall Begriffe wie "Pull Request" ins Deutsche übersetzt, habe aber schließlich entschieden, einige englische Phrasen zu verwenden, um den Wahnsinn im Text zu mindern. Manchmal werde ich 'programmiersprachlichen Mischmasch' verwenden, wie das seltsame Verb 'committen', dort wo es tatsächlich in der Praxis genutzt wird.

Was ist kontinuierliche Integration?

Kontinuierliche Integration, oder CI, ist eine technische Praxis, bei der jedes Teammitglied mindestens einmal täglich seinen Code in ein gemeinsames Repository integriert, wobei der resultierende Code fehlerfrei kompiliert werden muss.

Es gibt unterschiedliche Auffassungen zu diesem Begriff.

Streitpunkt ist die Häufigkeit der Integration. Einige behaupten, dass es nicht ausreicht, den Code nur einmal täglich zusammenzuführen, um tatsächlich kontinuierlich zu integrieren. Als Beispiel wird ein Team angeführt, in dem alle morgens den aktuellen Code abrufen und abends einmal integrieren. Auch wenn dies ein berechtigter Einwand ist, wird allgemein angenommen, dass der Ansatz "einmal täglich" ausreichend praktikabel, konkret und für Teams unterschiedlicher Größen geeignet ist.

Ein weiteres Argument besteht darin, dass C++ längst nicht mehr die einzige Sprache ist, die bei der Entwicklung verwendet wird, und dass die einfache Anforderung an eine fehlerfreie Erstellung als Validierung eher schwach ist. Ein gewisser Satz von Tests (zum Beispiel lokale Unit-Tests) sollte ebenfalls erfolgreich abgeschlossen werden. Derzeit neigt die Community dazu, eine solche Anforderung als obligatorisch zu betrachten, und in Zukunft wird "Erstellung + Modultests" offensichtlich zur Norm werden, wenn das nicht bereits der Fall ist.

Kontinuierliche Integration unterscheidet sich von kontinuierlicher Lieferung (Continuous Delivery, CD) dadurch, dass sie keinen Release-Kandidaten nach jedem Integrationszyklus erfordert.

Die Liste der Schritte, die wir im Verlauf des Kurses verwenden werden

1. Den neuesten Code herunterladen. Einen Branch erstellen von master. Mit der Arbeit beginnen.
2. Erstellen Sie Commits in Ihrem neuen Branch. Lokal bauen und testen. Erfolgreich? Gehen Sie zum nächsten Schritt. Fehlgeschlagen? Beheben Sie Fehler oder Tests und versuchen Sie es erneut.
3. In Ihr entferntes Repository oder den entfernten Branch pushen.
4. Ein Pull-Request erstellen. Diskutieren Sie die Änderungen, fügen Sie weitere Commits hinzu, während die Diskussion fortschreitet. Lassen Sie die Tests im Feature-Branch bestehen.
5. Commits vom Master zusammenführen/rebasen. Lassen Sie die Tests auf dem Merge-Ergebnis bestehen.
6. Vom Feature-Branch in die Produktion deployen.
7. Wenn alles einige Zeit gut in der Produktion läuft, Änderungen in den Master zusammenführen.

️ Vorbereitung

Stellen Sie sicher, dass die benötigte Software vorhanden ist

Um diesen Kurs zu absolvieren, benötigen Sie Node.js und einen Git-Client.

Sie können jeden Git-Client verwenden, aber ich werde nur die Befehle für die Befehlszeile angeben.

Stellen Sie sicher, dass Sie einen Git-Client installiert haben, der die Befehlszeile unterstützt.

Wenn Sie noch keinen Git-Client installiert haben, der die Befehlszeile unterstützt, finden Sie Anweisungen zur Installation. hier.

Bereiten Sie das Repository vor.

Sie müssen eine persönliche Kopie (Fork) des Vorlage-Repositories mit dem Code für den Kurs erstellen auf GitHub. Lassen Sie uns vereinbaren, diese persönliche Kopie Kursrepository zu nennen. Fertig? Wenn Sie die Standardeinstellungen nicht geändert haben, heißt Ihr Kursrepository wahrscheinlich.

continuous-integration-team-scenarios-students. Es befindet sich in Ihrem Konto auf GitHub, und die URL sieht so aus:https://github.com//continuous-integration-team-scenarios-students

Ich werde diese Adresse einfach

Ich werde diese Adresse einfach nennen nennen. Die spitzen Klammern wie.

Spitze Klammern wie bedeuten, dass Sie dieses Ausdruck durch den entsprechenden Wert ersetzen müssen. Stellen Sie sicher, dass

für dieses Kursrepository aktiviert sind. Wenn sie nicht aktiviert sind, aktivieren Sie sie bitte, indem Sie auf die große Schaltfläche in der Mitte der Seite klicken, die Sie erreichen können, indem Sie auf Actions im GitHub-Interface klicken. GitHub Actions sind für dieses Kursrepository enthalten. Wenn sie nicht enthalten sind, bitte aktiviere sie, indem du auf die große Schaltfläche in der Mitte der Seite klickst, die du erreichen kannst, indem du auf Aktionen im GitHub-Interface klickst.

Es wird Ihnen nicht gelingen, den Kurs zu absolvieren, wenn GitHub Actions nicht aktiviert sind.

Sie können immer die Funktion von GitHub nutzen, um Markdown anzuzeigen, um den aktuellen Status der Liste zu sehen, die wir hier erstellen.

https://github.com//continuous-integration-team-scenarios-students/blob/master/ci.md

Zu den Antworten

Obwohl der beste Weg, diesen Kurs abzuschließen, darin besteht, alles selbst zu machen, können Schwierigkeiten auftreten.

Wenn Sie das Gefühl haben, nicht zu verstehen, was zu tun ist und nicht weiterkommen, können Sie in den Branch solution, der in Ihrem Start-Repository vorhanden ist, nachsehen.
Bitte führen Sie während des Kurses keine Zusammenführungen durch. solution in master Sie können diesen Branch verwenden, um herauszufinden, was zu tun ist, oder um Ihren Code mit dem Originalcode zu vergleichen, indem Sie alle Möglichkeiten nutzen, die Git uns bietet. Wenn Sie völlig verloren sind, können Sie Ihren Branch master durch den Branch solution ersetzen und dann Ihr Arbeitsverzeichnis auf den Schritt im Kurs zurücksetzen, den Sie benötigen.

Verwenden Sie dies nur, wenn es wirklich nötig ist.

Committen Sie Ihren Code

git add .
git commit -m "Backing up my work"

Diese Befehle

• benennen master in master-backup;
• benennen solution in master;
• wechseln (checkout) zu einem neuen Branch. master und schreiben den Inhalt des Arbeitsverzeichnisses um;
• erstellen einen Branch "solution" aus "master" (der früher "solution" war) für den Fall, dass Sie in Zukunft den Branch "solution" benötigen.

git branch -m master master-backup
git branch -m solution master
git checkout master -f
git branch solution

Nach diesen Aktionen können Sie verwenden git log master um herauszufinden, welchen Commit Sie benötigen.
Sie können Ihr Arbeitsverzeichnis auf diesen Commit zurücksetzen mit:

git reset --hard

Wenn Sie mit dem Ergebnis zufrieden sind, müssen Sie irgendwann Ihre Versionen des Repositories in ein entferntes Repository veröffentlichen. Vergessen Sie nicht, beim Hochladen den entfernten Branch ausdrücklich anzugeben.

git push --force origin master

Bitte beachten Sie, dass wir verwenden git push --force. Wahrscheinlich möchten Sie das nicht oft tun, aber wir haben hier ein sehr spezifisches Szenario mit einem einzelnen Benutzer des Repositories, der außerdem versteht, was er tut.

Arbeiten beginnen

Lassen Sie uns mit dem Erstellen unserer CI-Schritte beginnen. Normalerweise beginnt man diesen Schritt, indem man die neueste Version des Codes aus dem entfernten Repository abruft, aber wir haben noch kein lokales Repository, also klonen wir stattdessen das entfernte.

️ Aufgabe: Aktualisieren Sie das lokale Repository, erstellen Sie einen Branch aus master, beginnen Sie zu arbeiten

1. Klone das Kursrepository von nennen. Die spitzen Klammern wie.
2. Starten Sie npm install in das Verzeichnis des Kursrepositories; wir benötigen es zur Installation von Jest, das wir zum Ausführen von Tests verwenden.
3. Erstellen Sie einen Branch und benennen Sie ihn feature. Wechseln Sie zu diesem Branch.

4. Fügen Sie den Testcode ein ci.test.js zwischen den Kommentaren mit der Bitte, dies zu tun.

   it('1. Ziehen Sie den neuesten Code', () => {
     expect(/.*pull.* /ig.test(fileContents)).toBe(true);
   });
   
   it('2. Fügen Sie Commits hinzu', () => {
     expect(/.*commit.* /ig.test(fileContents)).toBe(true);
   });
   
   it('3. Pushen Sie in den Remote-Branch mit demselben Namen', () => {
     expect(/.*push.* /ig.test(fileContents)).toBe(true);
   });
   
   it('4. Erstellen Sie eine Pull-Anfrage und arbeiten Sie weiter', () => {
     expect(/.*pulls+request.* /ig.test(fileContents)).toBe(true);
   });

5. Fügen Sie den Text mit den ersten 4 Schritten in die Datei ci.md.

   1. Ziehen Sie den neuesten Code. Erstellen Sie einen Branch von `master`. Beginnen Sie zu arbeiten.    
   2. Erstellen Sie Commits in Ihrem neuen Branch. Bauen und testen Sie lokal.  
   Bestehen? Gehen Sie zum nächsten Schritt. Fehler? Beheben Sie Fehler oder Tests und versuchen Sie es erneut.  
   3. Pushen Sie in Ihr Remote-Repository oder Remote-Branch.  
   4. Erstellen Sie eine Pull-Anfrage. Diskutieren Sie die Änderungen, fügen Sie weitere Commits hinzu, während die Diskussion fortschreitet. Lassen Sie die Tests im Feature-Branch bestehen.  

   Befehle

# Клонируйте репозиторий курса
git clone <repository URL>
cd <repository name>

# Выполните npm install в каталоге репозитория курса; он установит Jest, который мы используем для запуска тестов.
npm install

# Создайте ветку и назовите ее feature. Переключитесь на эту в ветку.
git checkout -b feature

# Отредактируйте ci.test.js как описано выше.
# Отредактируйте ci.md как описано выше

Erstellen Sie Commits im neuen Branch, führen Sie den Build und testen Sie lokal

Wir werden Tests einrichten, damit sie vor dem Commit ausgeführt werden, und dann den Code committen.

Typische Szenarien, in denen Tests automatisch ausgeführt werden

• Lokal:
  • Ständig oder als Reaktion auf entsprechende Codeänderungen;
  • Bei der Speicherung (für interpretierte oder JIT-kompilierte Sprachen);
  • Bei der Kompilierung (wenn eine Kompilierung erforderlich ist);
  • Bei einem Commit;
  • Bei der Veröffentlichung in ein öffentliches Repository.

• Auf dem Build-Server oder in der Build-Umgebung:
  • Wenn der Code in einen persönlichen Branch / ein Repository veröffentlicht wird.
  • Der Code wird in diesem Branch getestet.
  • Das potenzielle Ergebnis des Merge wird getestet (normalerweise mit master).
  • Im Rahmen der kontinuierlichen Integration / des kontinuierlichen Liefer-Pipelines

In der Regel gilt: Je schneller ein Testsatz ausgeführt wird, desto häufiger können Sie ihn ausführen. Eine typische Verteilung der Phasen könnte so aussehen.

• Schnelle Modultests – bei der Kompilierung, im CI-Pipeline
• Langsame Modultests, schnelle Komponententests und Integrationstests – bei einem Commit, im CI-Pipeline
• Langsame Komponenten- und Integrationstests – im CI-Pipeline
• Sicherheitstests, Lasttests und andere langwierige oder kostenintensive Tests – in CI/CD-Pipelines, aber nur in bestimmten Modi / Phasen / Build-Pipelines, zum Beispiel bei der Erstellung eines Release-Kandidaten oder bei manueller Ausführung.

️ Aufgabe

Ich schlage vor, die Tests zuerst manuell mit dem Befehl zu starten npm test. Lassen Sie uns danach einen Git-Hook hinzufügen, um unsere Tests bei jedem Commit auszuführen. Es gibt ein kleines Problem: Git-Hooks sind nicht Teil des Repositories und können daher nicht zusammen mit dem restlichen Kursmaterial von GitHub geklont werden. Um den Hook einzurichten, müssen Sie install_hook.sh ausführen oder die Datei repo/hooks/pre-commit in das lokale Verzeichnis .git/hooks/.
kopieren. Bei einem Commit sehen Sie, dass die Tests ausgeführt werden, und sie überprüfen, ob bestimmte Schlüsselwörter in der Liste vorhanden sind.

1. Führen Sie die Tests manuell mit dem Befehl aus npm test im Verzeichnis Ihres Kursrepositories. Stellen Sie sicher, dass die Tests ausgeführt wurden.
2. Richten Sie einen Commit-Hook (pre-commit hook) ein, indem Sie install_hook.sh.
3. Änderungen in Ihr lokales Repository committen.
4. Stellen Sie sicher, dass die Tests vor dem Commit ausgeführt werden.

Ihr Repository sollte nach diesen Schritten so aussehen.

Befehle

# Установите pre-commit hook выполнив install_hook.sh.  

# Закоммитьте изменения в локальный репозиторий. Используйте "Add first CI steps" в качестве сообщения при коммите.
git add ci.md ci.test.js
git commit -m "Add first CI steps"

# Убедитесь, что тесты запускаются перед коммитом.  

Veröffentlichen Sie den Code in einem Remote-Repository oder einem Remote-Zweig.

Nachdem Entwickler lokal gearbeitet haben, machen sie ihren Code in der Regel öffentlich, damit er letztendlich in das Gemeinschaftsprojekt integriert werden kann. Mit GitHub wird dies normalerweise erreicht, indem die Arbeit entweder in einer persönlichen Kopie des Repositories (personal fork) oder in einem persönlichen Branch veröffentlicht wird.

• Bei der Verwendung von Forks klont der Entwickler das entfernte gemeinsame Repository und erstellt eine persönliche, entfernte Kopie, die als Fork bekannt ist. Danach klont er dieses persönliche Repository, um lokal damit zu arbeiten. Wenn die Arbeit abgeschlossen ist und die Commits erstellt wurden, fügt er sie in seinen Fork ein, wo sie für andere zugänglich sind und in das gemeinsame Repository integriert werden können. Dieser Ansatz wird normalerweise in Open-Source-Projekten auf GitHub verwendet. Er wird auch in meinem erweiterten Kurs [Team Work and CI with Git] verwendet.http://devops.redpill.solutions/).
• Ein weiterer Ansatz besteht darin, nur ein entferntes Repository zu verwenden und nur den Branch zu berücksichtigen. master verwendetes Repository "geschützt". In diesem Szenario veröffentlichen einzelne Entwickler ihren Code in Branches des entfernten Repositories, sodass andere diesen Code einsehen können; wenn alles in Ordnung ist, wird er mit master dem gemeinsamen Repository zusammengeführt.

In diesem speziellen Kurs werden wir einen Workflow verwenden, der Branches nutzt.

Lassen Sie uns unseren Code veröffentlichen.

️ Aufgabe

• Veröffentlichen Sie die Änderungen in den entfernten Branch mit demselben Namen wie Ihr Arbeitsbranch

Befehle

git push --set-upstream origin feature

Erstellen Sie einen Pull Request

Erstellen Sie einen Pull Request mit dem Titel Schritte zur Überprüfung. Stellen Sie ein feature als "Head Branch" und master als "Base Branch" ein.

Stellen Sie sicher, dass Sie master in seinem das Fork des Repositories als "Base Branch" festgelegt haben; ich werde keine Änderungsanfragen für das Repository mit den Kursmaterialien beantworten.

Im GitHub-Jargon ist "Base Branch" der Branch, auf dem Sie Ihre Arbeit basieren, während "Head Branch" der Branch ist, der die vorgeschlagenen Änderungen enthält.

Diskutieren Sie die Änderungen und fügen Sie neue Commits hinzu, während die Diskussion fortgesetzt wird.

Pull Request (PR)

Pull Request (PR) — ist eine Möglichkeit, über den Code zu diskutieren und ihn zu dokumentieren sowie eine Codeüberprüfung (code review) durchzuführen. Pull Requests sind nach der gängigen Methode benannt, um einzelne Änderungen in den gemeinsamen Code zu integrieren. In der Regel klont eine Person das entfernte offizielle Repository des Projekts und arbeitet lokal am Code. Danach stellt sie den Code in ihr persönliches entferntes Repository und bittet die Verantwortlichen des offiziellen Repositories, ihren Code in ihre lokalen Repositories zu übernehmen, wo sie ihn überprüfen und möglicherweise integrieren.pull)ZusammenführenDieses Konzept ist auch unter anderen Namen bekannt, wie zum Beispiel Merge Requests.

Tatsächlich müssen Sie die Pull Request-Funktion von GitHub oder ähnlichen Plattformen nicht unbedingt verwenden. Entwicklerteams können auch andere Kommunikationsmittel nutzen, einschließlich persönlicher Gespräche, Telefonate oder E-Mails, aber es gibt dennoch eine Reihe von Gründen, Pull Requests im Stil von Diskussionsforen zu verwenden. Hier sind einige davon:

• organisierte Diskussionen zu spezifischen Änderungen am Code;
• als Ort für die Einsichtnahme in Rückmeldungen zu unvollendeter Arbeit sowohl von automatisierten Tests als auch von Kollegen;
• Formalisierung von Codeüberprüfungen;
• um später die Gründe und Überlegungen hinter einem bestimmten Codefragment zu ermitteln.

Normalerweise erstellen Sie einen Pull Request, wenn Sie etwas besprechen oder Feedback erhalten möchten. Wenn Sie beispielsweise an einer Funktion arbeiten, die auf verschiedene Arten implementiert werden kann, können Sie einen Änderungsantrag einreichen, noch bevor Sie die erste Zeile Code schreiben, um Ihre Ideen zu teilen und Ihre Pläne mit Mitautoren zu besprechen. Bei einfacheren Arbeiten wird der Pull Request eröffnet, wenn etwas bereits abgeschlossen, festgeschrieben und zur Diskussion bereit ist. In einigen Szenarien können Sie einen PR nur zu Qualitätskontrollzwecken öffnen: um automatisierte Tests auszuführen oder die Codeüberprüfung einzuleiten. Was auch immer Sie entscheiden, vergessen Sie nicht, @Benutzer zu erwähnen, deren Genehmigung Sie in Ihrem Pull Request benötigen.

Bei der Erstellung eines PR tun Sie normalerweise Folgendes.

• Sie geben an, was Sie vorschlagen zu ändern und wo.
• Sie schreiben eine Beschreibung, die das Ziel der Änderungen erklärt. Möglicherweise möchten Sie:
  • Fügen Sie etwas Wichtiges hinzu, das nicht offensichtlich aus dem Code hervorgeht, oder etwas Nützliches für das Verständnis des Kontexts, z. B. relevante #Bugs und Commit-Nummern;
  • @Erwähnen Sie alle, mit denen Sie zusammenarbeiten möchten, oder Sie können sie später in Kommentaren @erwähnen;
  • Bitten Sie Kollegen um Hilfe bei etwas oder überprüfen Sie etwas Bestimmtes.

Nachdem Sie den PR geöffnet haben, werden die für solche Fälle konfigurierten Tests durchgeführt. In unserem Fall handelt es sich um dasselbe Set von Tests, das wir lokal ausgeführt haben, aber in einem echten Projekt können zusätzliche Tests und Überprüfungen erforderlich sein.

Bitte warten Sie, bis die Tests abgeschlossen sind. Sie können den Status der Tests am Ende der PR-Diskussion in der GitHub-Oberfläche sehen. Fahren Sie fort, wenn die Tests abgeschlossen sind.

️Fügen Sie einen Hinweis zur Willkür der CI-Schritte hinzu

Die in diesem Kurs verwendete Liste ist willkürlich und subjektiv, wir sollten einen Hinweis darauf hinzufügen.

️Aufgabe: Pull-Request für diese Anmerkung erstellen

1. Wechseln Sie zu dem Branch master.
2. Erstellen Sie einen Branch mit dem Namen Bugfix.
3. Fügen Sie den Anmerkungstext ans Ende der Datei hinzu ci.md.

   > **GitHub flow** wird manchmal als Überbegriff für eine Variante der trunk-basierten Entwicklung verwendet, 
   bei der der Code direkt von Feature-Branches bereitgestellt wird. Diese Liste ist nur eine Interpretation, 
   die ich in meinen [DevOps-Kursen](http://redpill.solutions) verwende. 
   Das offizielle Tutorial finden Sie [hier](https://guides.github.com/introduction/flow/).

4. Committen Sie die Änderungen.
5. Veröffentlichen Sie den Branch Bugfix im Remote-Repository.
6. Erstellen Sie einen Pull-Request mit dem Namen Einen Kommentar hinzufügen mit dem Hauptbranch Bugfix und dem Basisbranchmaster.

Stellen Sie sicher, dass Sie master in seinem das Fork des Repositories als "Base Branch" festgelegt haben; ich werde keine Änderungsanfragen für das Repository mit den Kursmaterialien beantworten.

So sollte Ihr Repository aussehen.

Befehle

# Переключитесь на ветку master. Создайте ветку bugfix.
git checkout master

# Создайте ветку bugfix-remark.
git checkout -b bugfix

# Добавьте текст примечания внизу ci.md.

# Закоммитьте изменения
git add ci.md
git commit -m "Add a remark about the list being opinionated"

# Опубликуйте ветку bugfix в удалённый репозиторий.
git push --set-upstream origin bugfix

# Создайте pull request при помощи интерфейса GitHub как описано выше

Genehmigen Sie den Pull-Request "Einen Kommentar hinzufügen"

️ Aufgabe

1. Erstellen Sie einen Pull-Request.
2. Klicken Sie auf "Pull-Request zusammenführen".
3. Klicken Sie auf "Zusammenführung bestätigen".
4. Klicken Sie auf "Branch löschen", da wir ihn nicht mehr benötigen.

Dies ist das Commit-Diagramm nach der Zusammenführung.

️ Fahren Sie fort und fügen Sie Tests hinzu

Die Zusammenarbeit an einem Pull-Request führt oft zu zusätzlicher Arbeit. Dies ist normalerweise das Ergebnis von Code-Überprüfungen oder Diskussionen, aber in unserem Kurs werden wir dies simulieren, indem wir neue Elemente zu unserer CI-Checklist hinzufügen.

Bei der kontinuierlichen Integration wird normalerweise eine gewisse Testabdeckung angewendet. Die Anforderungen an die Testabdeckung variieren und befinden sich normalerweise in einem Dokument mit dem Titel "Beitragsrichtlinien". Wir werden es einfach halten und für jede Zeile in unserer Checkliste einen Test hinzufügen.

Wenn Sie Aufgaben ausführen, versuchen Sie zuerst, die Tests zu committen. Wenn Sie den pre-commit Hook zuvor korrekt eingerichtet haben, wird der gerade hinzugefügte Test ausgeführt, besteht jedoch nicht, und es wird nichts committet. Beachten Sie: So erkennen wir, dass unsere Tests tatsächlich etwas überprüfen. Interessanterweise könnte das Bestehen der Tests, wenn wir mit dem Code vor den Tests begonnen hätten, sowohl bedeuten, dass der Code wie erwartet funktioniert, als auch, dass die Tests tatsächlich nichts überprüfen. Darüber hinaus könnten wir, wenn wir die Tests nicht zuerst geschrieben hätten, diese ganz vergessen, da uns nichts daran erinnert hätte.

Testgetriebene Entwicklung (TDD)

TDD empfiehlt, Tests vor dem Code zu schreiben. Der übliche Prozess bei der Arbeit mit TDD sieht so aus.

1. Fügen Sie einen Test hinzu.
2. Führen Sie alle Tests aus und stellen Sie sicher, dass der neue Test nicht erfolgreich besteht.
3. Schreiben Sie den Code.
4. Führen Sie die Tests aus und stellen Sie sicher, dass alle Tests erfolgreich sind.
5. Refaktorisieren Sie den Code.
6. Wiederholen Sie.

Da die Ergebnisse von nicht bestandenen Tests normalerweise in Rot und von bestandenen Tests in Grün angezeigt werden, wird dieser Zyklus auch als "rot-grün-refactor" bezeichnet.

️ Aufgabe

Versuchen Sie zunächst, die Tests zu committen und ihnen zu erlauben, fehlerhaft abzuschließen. Fügen Sie dann den eigentlichen Text der CI-Schritte hinzu und committen Sie ihn. Sie werden sehen, dass die Tests erfolgreich sind ("grün").
Veröffentlichen Sie dann den neuen Code im Remote-Repository und beobachten Sie, wie die Tests in der GitHub-Oberfläche am Ende der Diskussion über den Pull-Request ausgeführt werden und der PR-Status aktualisiert wird.

1. Wechseln Sie zu dem Branch feature.

2. Fügen Sie diese Tests in ci.test.js nach dem letzten Aufruf it (...);.

   it('5. Merge/rebase commits von master. Lassen Sie die Tests mit dem Merge-Ergebnis bestehen.', () => {
     expect(/.*merge.*commits.*tests+pass.*/ig.test(fileContents)).toBe(true);
   });
   
   it('6. Vom Feature-Branch in die Produktion deployen.', () => {
     expect(/.*Deploy.*to+production.*/ig.test(fileContents)).toBe(true);
   });
   
   it('7. Wenn in der Produktion für eine gewisse Zeit alles gut ist, Änderungen in master zusammenführen.', () => {
     expect(/.*merge.*to+master.*/ig.test(fileContents)).toBe(true);
   });

3. Versuchen Sie, die Tests zu committen. Wenn pre-commit der Hook installiert ist, schlägt der Commit-Versuch fehl.
4. Fügen Sie dann diesen Text hinzu in ci.md.

   5. Zusammenführen/Rebasen von Commits aus dem Master. Stellen Sie sicher, dass die Tests im Ergebnis des Mergers bestehen.  
   6. Deployen Sie aus dem Feature-Branch mit einem heimlichen Bug in die Produktion.
   7. Wenn alles für eine gewisse Zeit gut in der Produktion läuft, ändern Sie die Änderungen im Master. 

5. Nehmen Sie die Änderungen lokal vor und committen Sie diese.
6. Veröffentlichen Sie die Änderungen im Branch feature.

Jetzt sollte es so aussehen

Befehle

# Переключительна ветку feature
git checkout feature

# Добавить тесты в ci.test.js как описано выше

# Добавьте в индекс ci.test.js чтобы позже закоммитить
git add ci.test.js

# Попытайтесь закоммитить тесты. Если pre-commit hook установлены, коммит не произойдёт.
git commit

# Теперь добавьте текст в ci.md как описано выше

# Внесите изменения и закоммитьте их
git add ci.md
git commit -m "Add the remaining CI steps"

# Опубликуйте изменения в ветку feature
git push

Zusammenführungs-Konflikt

Gehen Sie zur Änderungsanforderung Schritte zur Überprüfung.

Obwohl wir nichts Schlechtes getan haben und die Tests für unseren Code erfolgreich waren, können wir den Branch immer noch nicht zusammenführen. feature und master. Das liegt daran, dass ein anderer Branch Bugfix mit master fusioniert wurde, während wir an diesem PR gearbeitet haben.
Dies führt zu einer Situation, in der der entfernte Branch master eine neuere Version hat als die, auf der wir unseren Branch basierten. feature. Deshalb können wir das HEAD nicht einfach zurücksetzen master bis zum Ende des Branches. feature. In dieser Situation müssen wir entweder mergen oder die Commits feature darüber anwenden (rebase). masterGitHub kann tatsächlich automatisiertes Mergen durchführen, wenn es keine Konflikte gibt. Leider haben in unserer Situation beide Branches konkurrierende Änderungen in der Datei ci.md. Diese Situation ist als Merge-Konflikt bekannt, und wir müssen sie manuell lösen.

Merge oder rebase

Zusammenführen

• Erstellt einen zusätzlichen Merge Commit und bewahrt die Historie der Arbeit.
  • Speichert die ursprünglichen Commits der Branches mit den ursprünglichen Zeitstempeln und Autoren.
  • Speichert die SHA der Commits und Verlinkungen zu ihnen in den Diskussionen zu Pull-Requests.
• Erfordert einmalige Konfliktlösung.
• Macht die Historie nicht-linear.
  • Die Historie kann aufgrund der vielen Branches schwer lesbar sein (ähnlich wie ein IDE-Kabel).
  • Erschwert die automatische Fehlerbehebung, zum Beispiel macht es git bisect weniger nützlich – es findet nur den Merge-Commit.

Rebase

• stellt die Commits aus dem aktuellen Branch auf dem Basis-Branch nacheinander wieder her.
  • Es entstehen neue Commits mit neuen SHAs, wodurch die Commits in GitHub mit den ursprünglichen Pull-Requests, jedoch nicht mit den entsprechenden Kommentaren, verknüpft werden.
  • Commits können während des Prozesses rekombiniert und verändert oder sogar zu einem einzigen zusammengeführt werden.
• Es kann erforderlich sein, mehrere Konflikte zu lösen.
• Ermöglicht die Beibehaltung einer linearen Historie.
  • Die Historie kann einfacher zu lesen sein, solange sie nicht zu lang ist, ohne dass es dafür einen vernünftigen Grund gibt.
  • Das automatische Debugging und Troubleshooting ist etwas einfacher: macht es möglich. git bisect, kann automatische Backups klarer und vorhersehbarer gestalten.
• Erforderlich ist die Veröffentlichung des Branches mit übertragenen Commits mit dem Flag --force bei der Verwendung mit Änderungsanfragen.

Normalerweise stimmen Teams immer zu, dieselbe Strategie zu verwenden, wenn sie Änderungen zusammenführen müssen. Dies kann ein "sauberes" Merging oder ein "sauberes" Anwenden von Commits sein, oder etwas dazwischen, wie das Durchführen von Commits im interaktiven Modusgit rebase -i) lokal für Branches, die nicht im gemeinsamen Repository veröffentlicht sind, aber Merging für "öffentliche" Branches.

Hier werden wir Merging verwenden.

️ Aufgabe

1. Stellen Sie sicher, dass der Code im lokalen Branch master aus dem entfernten Repository aktualisiert wurde.
2. Wechseln Sie zu dem Branch feature.
3. Initiieren Sie das Merging mit dem Branch master. Es wird ein Merging-Konflikt gemeldet, der mit konkurrierenden Änderungen in ci.md.
4. Bereinigen Sie den Konflikt so, dass sowohl unsere CI-Schrittliste als auch der Hinweis darauf im Text bleiben.
5. Veröffentlichen Sie den Merging-Commit im entfernten Branch feature.
6. Überprüfen Sie den Status der Pull-Anfrage im GitHub-Benutzerinterface, warten Sie, bis das Merging gelöst ist.

Befehle

# Убедитесь, что код в локальное ветке `master` обновлён из удалённого репозитория.
git checkout master
git pull

# Переключитесь на ветку feature
git checkout feature

# Инициируйте слияние с веткой master 
git merge master

# A merge conflict related to concurrent changes to ci.md will be reported
# => Auto-merging ci.md
#    CONFLICT (content): Merge conflict in ci.md
#    Automatic merge failed; fix conflicts and then commit the result.

# Разрешите конфликт так, чтобы и наш список шагов CI, и замечание о нем остались в тексте.
# отредактируйте ci.md чтоб он не содержал маркеров конфликта слияния
git add ci.md
git merge --continue
# при коммите можете оставить сообщение по умолчанию

# Опубликуйте коммит слияния в удаленную ветку feature.
git push

# Проверьте статус запроса на изменения в пользовательском интерфейсе GitHub, дождитесь пока слияние не будет разрешено.

Großartige Arbeit!

Sie haben die Arbeit an der Liste abgeschlossen und müssen nun den Pull-Request in master.

️ Aufgabe: Bestätigen Sie den Pull-Request "Steps review"

1. Öffnen Sie den Pull-Request.
2. Klicken Sie auf "Pull-Request zusammenführen".
3. Klicken Sie auf "Zusammenführung bestätigen".
4. Klicken Sie auf "Branch löschen", da wir ihn nicht mehr benötigen.

Das ist Ihr Repository im Moment

Fehler in der Produktion

Es wird gesagt, dass „Tests verwendet werden können, um das Vorhandensein von Fehlern zu zeigen, aber niemals, um deren Abwesenheit zu bestätigen“. Trotz der Tatsache, dass wir Tests hatten und diese uns keine Fehler angezeigt haben, hat sich ein heimtückischer Fehler in die Produktion eingeschlichen.

In einem solchen Szenario müssen wir uns um Folgendes kümmern:

• was in der Produktion läuft;
• den Code im Branch master mit dem Fehler, von dem die Entwickler die neue Arbeit beginnen können.

Rollen oder im nächsten Release beheben?

"Rolling back" ist die Bereitstellung einer wissentlich fehlerfreien früheren Version in der Produktionsumgebung und das Rückgängigmachen (revert) von Commits, die den Fehler enthalten. "Fixing forward" bedeutet, dass eine Korrektur in das master und die neue Version so schnell wie möglich bereitzustellen. Da sich API und Datenbankschemata mit der Implementierung des Codes in die Produktionsumgebung ändern, ist das Zurückrollen in einer kontinuierlichen Bereitstellung mit gutem Testdeckungsgrad in der Regel viel komplexer und riskanter als eine Korrektur in der nächsten Version.

Da ein Zurückrollen in unserem Fall kein Risiko darstellt, werden wir diesen Weg einschlagen, denn das ermöglicht es uns

• den Fehler in der Produktion so schnell wie möglich zu beheben;
• den Code in master sofort für neue Arbeiten bereit zu machen.

️ Aufgabe

1. Wechseln Sie zu dem Branch master lokal.
2. Aktualisieren Sie das lokale Repository aus dem Remote-Repository.
3. Den Merge-Commit des PR zurücksetzen Schritte zur Überprüfung in master.
4. Änderungen im Remote-Repository veröffentlichen.

Dies ist die Historie des Repositories mit dem zurückgesetzten Merge-Commit

Befehle

# Переключитесь на ветку master.
git checkout master

# Обновите локальный репозиторий из удалённого репозитория.
git pull

# Отмените коммит слияния PR Steps review в master.
# Мы отменяем коммит слияния, поэтому нам нужно выбрать ветку истории, которую мы захотим оставить
git show HEAD

# предположим, что коммит, который был последним в ветке master до слияния, был отображён предыдущей командой первым
git revert HEAD -m 1
# можете не менять сообщения коммитов

# Опубликуйте изменения в удалённый репозиторий
git push

️ Selbstüberprüfung

Stellen Sie sicher, dass ci.md enthält nach dem Zurücksetzen des Merge-Commits keinen Text mehr "sneaky bug".

Die CI-Schritte korrigieren und wieder in master zurückbringen

Wir haben den Merge-Commit des Branches vollständig zurückgesetzt feature. Die gute Nachricht ist, dass wir jetzt keinen Fehler in mastermehr haben. Die schlechte Nachricht ist, dass auch unsere wertvolle Liste der CI-Schritte verschwunden ist. Idealerweise müssen wir also die Korrektur auf die Commits von feature anwenden und sie zurückbringen. master zusammen mit der Korrektur.

Wir können die Aufgabe unterschiedlich angehen:

• den Commit zurücksetzen, der das Merge rückgängig macht feature mit master;
• Commits von einem vorherigen Branch verschieben feature.

Verschiedene Entwicklerteams verwenden in diesem Fall unterschiedliche Ansätze; wir werden jedoch nützliche Commits in einen eigenen Branch verschieben und eine separate Pull-Request für diesen neuen Branch erstellen.

️ Aufgabe

1. Erstellen Sie einen Branch mit dem Namen feature-fix und wechseln Sie zu diesem.

2. Verschieben Sie alle Commits aus dem vorherigen Branch feature in den neuen Branch. Lösen Sie die Merge-Konflikte, die beim Verschieben aufgetreten sind.

   

3. Fügen Sie einen Regressionstest hinzu in ci.test.js:

   it('does not contain the sneaky bug', () => {
   expect( /.*sneakys+bug.*/gi.test(fileContents)).toBe(false);
   });

4. Führen Sie die Tests lokal aus, um sicherzustellen, dass sie erfolgreich abgeschlossen werden.
5. Entfernen Sie den Text " with a sneaky bug" in ci.md.
6. Fügen Sie die Änderungen der Tests und die Änderungen in der Schritteliste zum Index hinzu und committen Sie sie.
7. Veröffentlichen Sie den Branch im Remote-Repository.

Am Ende sollte etwas Ähnliches herauskommen

Befehle

# Создайте ветку под названием feature-fix и переключитесь на нее.
git checkout -b feature-fix

# Перенесите все коммиты из бывшей ветки feature в новую ветку. Разрешите конфликты слияния, которые возникли при переносе.
# используйте историю чтобы узнать хэши коммитов:
# - предшествующего коммиту с первой частью списка: C0
# - добавляющего последние элементы списка: C2
git log --oneline --graph
git cherry-pick C0..C2
# разрешите конфликты слияния
# - отредактируйте ci.md и/или ci.test.js
# - добавьте файлы в индекс
# - выполните "git cherry-pick --continue", можете не менять сообщение коммита

# Добавьте регрессионный тест в ci.test.js
# Запустите тесты локально, чтобы убедиться, что они не завершаются успешно.

# Удалите текст " with a sneaky bug" в ci.md.

# Добавьте в индекс изменения тестов и в списке шагов и закоммитьте их.
git add ci.md ci.test.js
git commit -m "Fix the bug in steps list"

# Опубликуйте ветку в удалённый репозиторий.
git push --set-upstream origin feature-fix

Erstellen Sie einen Pull-Request.

Erstellen Sie einen Pull Request mit dem Titel Fixing the feature. Stellen Sie ein feature-fix als "head branch", und master als "Base Branch" ein.
Bitte warten Sie, bis die Tests abgeschlossen sind. Sie können den Teststatus am Ende der PR-Diskussion sehen.

Stellen Sie sicher, dass Sie master in seinem das Fork des Repositories als "Base Branch" festgelegt haben; ich werde keine Änderungsanfragen für das Repository mit den Kursmaterialien beantworten.

Genehmigen Sie die Pull-Request "Fixing the feature"

Danke für die Korrektur! Bitte genehmigen Sie die Änderungen in master aus der Pull-Request.

️ Aufgabe

1. Klicken Sie auf "Pull-Request zusammenführen".
2. Klicken Sie auf "Zusammenführung bestätigen".
3. Klicken Sie auf "Branch löschen", da wir ihn nicht mehr benötigen.

Das ist es, was Sie gerade haben sollten.

Herzlichen Glückwunsch!

Sie haben alle Schritte durchgeführt, die Menschen normalerweise im Prozess der kontinuierlichen Integration unternehmen.

Wenn Sie irgendwelche Probleme mit dem Kurs bemerken oder wissen, wie man ihn verbessern kann, erstellen Sie ein Issue im Kursmaterialien-Repository.Dieser Kurs hat auch eine interaktive Version die GitHub Learning Lab als Plattform nutzt.

Quelle: habr.com