Git-Verzweigungsstrategie mit Test- / QS-Prozess integriert

Unser Entwicklungsteam hat die GitFlow- Verzweigungsstrategie verwendet und es war großartig!

Kürzlich haben wir einige Tester eingestellt, um unsere Softwarequalität zu verbessern. Die Idee ist, dass jede Funktion von einem Tester getestet / überprüft werden sollte.

In der Vergangenheit haben Entwickler Features in separaten Feature-Zweigen bearbeitet und sie nach Abschluss wieder mit dem developZweig zusammengeführt. Der Entwickler wird seine Arbeit selbst in diesem featureZweig testen . Jetzt mit Testern beginnen wir, diese Frage zu stellen

Auf welchem ​​Zweig sollte der Tester neue Funktionen testen?

Offensichtlich gibt es zwei Möglichkeiten:

• auf dem einzelnen Feature-Zweig
• auf dem developAst

Testen auf Entwicklungszweig

Anfangs glaubten wir, dass dies der sichere Weg ist, weil:

• Die Funktion wird mit allen anderen Funktionen getestet, die developseit Beginn der Entwicklung mit dem Zweig zusammengeführt wurden.
• Konflikte können früher als später erkannt werden
• Dies erleichtert dem Tester die Arbeit, er hat immer nur mit einem Zweig ( develop) zu tun . Er muss den Entwickler nicht fragen, welcher Zweig für welches Feature bestimmt ist (Feature-Zweige sind persönliche Zweige, die ausschließlich und frei von relevanten Entwicklern verwaltet werden).

Die größten Probleme dabei sind:

• Der developZweig ist mit Fehlern verschmutzt.

  Wenn der Tester Fehler oder Konflikte findet, meldet er diese an den Entwickler zurück, der das Problem im Entwicklungszweig behebt (der Feature-Zweig wurde nach dem Zusammenführen abgebrochen). Danach sind möglicherweise weitere Korrekturen erforderlich. Durch das developFestschreiben oder Zusammenführen mehrerer Teilsequenzen (wenn ein Zweig zum Beheben der Fehler erneut vom Zweig neu erstellt wird ) wird das Zurücksetzen des Features aus dem developZweig nach Möglichkeit sehr schwierig. Es gibt mehrere Funktionen, die developzu unterschiedlichen Zeiten mit dem Zweig zusammengeführt und dort fixiert werden . Dies ist ein großes Problem, wenn wir eine Version mit nur einigen Funktionen in der developBranche erstellen möchten

Testen auf Feature Branch

Also überlegten wir noch einmal und beschlossen, Features in den Feature-Zweigen zu testen. Bevor wir testen, führen wir die Änderungen vom developZweig zum Feature-Zweig zusammen (holen Sie den developZweig ein). Das ist gut:

• Sie testen die Funktion weiterhin mit anderen Funktionen im Mainstream
• Weiterentwicklungen (z. B. Fehlerbehebung, Konfliktlösung) verschmutzen den developZweig nicht.
• Sie können leicht entscheiden, die Funktion erst dann freizugeben, wenn sie vollständig getestet und genehmigt wurde.

Es gibt jedoch einige Nachteile

• Der Tester muss den Code zusammenführen und bei Konflikten (sehr wahrscheinlich) den Entwickler um Hilfe bitten. Unsere Tester sind auf Tests spezialisiert und können nicht codieren.
• Ein Feature kann getestet werden, ohne dass ein anderes neues Feature vorhanden ist. Beispiel: Merkmal A und B werden beide gleichzeitig getestet. Die beiden Merkmale sind sich nicht bewusst, da keines von beiden mit dem developZweig zusammengeführt wurde. Dies bedeutet, dass Sie developerneut gegen den Zweig testen müssen, wenn beide Features ohnehin mit dem Entwicklungszweig zusammengeführt werden. Und Sie müssen daran denken, dies in Zukunft zu testen.
• Wenn Feature A und B beide getestet und genehmigt werden, aber beim Zusammenführen ein Konflikt festgestellt wird, glauben beide Entwickler für beide Features, dass dies nicht seine eigene Schuld / Aufgabe ist, da sein Feature-Zweig nach dem Test verzweigt. Die Kommunikation ist mit einem zusätzlichen Aufwand verbunden, und manchmal ist jeder, der den Konflikt löst, frustriert.

Oben ist unsere Geschichte. Mit begrenzten Ressourcen möchte ich vermeiden, alles überall zu testen. Wir suchen immer noch nach einem besseren Weg, um damit umzugehen. Ich würde gerne hören, wie andere Teams mit solchen Situationen umgehen.

So machen wir das:

Wir testen die Feature-Zweige, nachdem wir den neuesten Entwicklungszweigcode auf ihnen zusammengeführt haben. Der Hauptgrund ist, dass wir den Entwicklungszweigcode nicht "verschmutzen" möchten, bevor eine Funktion akzeptiert wird. Falls ein Feature nach dem Testen nicht akzeptiert wird, wir aber andere Features veröffentlichen möchten, die bereits bei der Entwicklung zusammengeführt wurden, wäre das die Hölle. Entwickeln ist ein Zweig, aus dem eine Veröffentlichung erfolgt, und sollte sich daher besser in einem freigebbaren Zustand befinden. Die lange Version ist, dass wir in vielen Phasen testen. Analytischer:

1. Der Entwickler erstellt für jedes neue Feature einen Feature-Zweig.
2. Der Feature-Zweig wird (automatisch) in unserer TEST-Umgebung mit jedem Commit bereitgestellt, den der Entwickler testen soll.
3. Wenn der Entwickler mit der Bereitstellung fertig ist und das Feature zum Testen bereit ist, führt er den Entwicklungszweig im Feature-Zweig zusammen und stellt den Feature-Zweig bereit, der die neuesten Entwicklungsänderungen in TEST enthält.
4. Der Tester testet auf TEST. Wenn er fertig ist, "akzeptiert" er die Geschichte und führt den Feature-Zweig bei der Entwicklung zusammen. Da der Entwickler zuvor den Entwicklungszweig für Funktionen zusammengeführt hat, erwarten wir normalerweise nicht zu viele Konflikte. In diesem Fall kann der Entwickler jedoch helfen. Dies ist ein kniffliger Schritt. Ich denke, der beste Weg, dies zu vermeiden, besteht darin, die Funktionen so klein / spezifisch wie möglich zu halten. Verschiedene Funktionen müssen schließlich auf die eine oder andere Weise zusammengeführt werden. Natürlich spielt die Größe des Teams eine Rolle für die Komplexität dieses Schritts.
5. Der Entwicklungszweig wird auch (automatisch) auf TEST bereitgestellt. Wir haben die Richtlinie, dass der Entwicklungszweig niemals fehlschlagen sollte, obwohl die Builds der Feature-Zweige fehlschlagen können.
6. Sobald wir ein Einfrieren der Funktionen erreicht haben, erstellen wir eine Version von Develop. Dies wird beim STAGING automatisch bereitgestellt. Dort finden vor der Produktionsbereitstellung umfangreiche End-to-End-Tests statt. (ok, vielleicht übertreibe ich ein bisschen, sie sind nicht sehr umfangreich, aber ich denke, sie sollten es sein). Idealerweise sollten Betatester / Kollegen, dh echte Benutzer, dort testen.

Was halten Sie von diesem Ansatz?

Vor dem Test führen wir die Änderungen vom Entwicklungszweig zum Feature-Zweig zusammen

Nein, nicht, besonders wenn 'wir' der QS-Tester ist. Das Zusammenführen würde das Lösen potenzieller Konflikte beinhalten, was am besten von Entwicklern (sie kennen ihren Code) und nicht von QS-Testern (die so schnell wie möglich testen sollten) durchgeführt wird.

Lassenfeaturedevel Sie den Entwickler eine Neubasis seines Zweigs über dem Zweig durchführen und verschieben Sie diesen featureZweig (der vom Entwickler als Kompilieren und Arbeiten über dem neuesten develZweigstatus bestätigt wurde).
Das ermöglicht:

• Eine sehr einfache Integration in den Feature-Zweig (trivialer Fast-Forward-Merge).
• oder, wie von Aspasia unten in den Kommentaren empfohlen , eine Pull-Anforderung (GitHub) oder eine Zusammenführungsanforderung (GitLab) : Der Betreuer führt eine Zusammenführung zwischen dem PR / MR-Zweig der Funktion und durch develop, jedoch nur dann, wenn von GitHub / GitLab kein Konflikt erkannt wird.

Jedes Mal, wenn der Tester einen Fehler erkennt, meldet er ihn dem Entwickler und löscht den aktuellen Feature-Zweig.
Der Entwickler kann:

• Beheben Sie den Fehler
• Rebase auf einem kürzlich abgerufenen Entwicklungszweig (erneut, um sicherzustellen, dass sein Code in Integration mit anderen validierten Funktionen funktioniert)
• Schieben Sie den featureAst.

Allgemeine Idee: Stellen Sie sicher, dass der Zusammenführungs- / Integrationsteil vom Entwickler ausgeführt wird, und überlassen Sie die Tests der Qualitätssicherung.

Der beste Ansatz ist die kontinuierliche Integration , bei der die allgemeine Idee darin besteht, die Feature-Zweige so häufig wie möglich mit dem Entwickler-Zweig zusammenzuführen. Dies reduziert den Aufwand für das Zusammenführen von Schmerzen.

Verlassen Sie sich so weit wie möglich auf automatisierte Tests und lassen Sie Builds automatisch mit Unit-Tests von Jenkins starten. Lassen Sie die Entwickler die gesamte Arbeit mit dem Zusammenführen ihrer Änderungen in der Hauptniederlassung erledigen und Unit-Tests für den gesamten Code bereitstellen.

Die Tester / QS können an Codeüberprüfungen teilnehmen, Unit-Tests abhaken und automatisierte Integrationstests schreiben, die der Regressionssuite hinzugefügt werden, wenn die Funktionen abgeschlossen sind.

Weitere Informationen finden Sie unter diesem Link .

Wir verwenden das, was wir "Gold", "Silber" und "Bronze" nennen. Dies könnte als Prod, Inszenierung und Qa bezeichnet werden.

Ich bin gekommen, um dies das Schmelztiegelmodell zu nennen. Dies funktioniert gut für uns, da wir auf der Geschäftsseite einen enormen Bedarf an Qualitätssicherung haben, da die Anforderungen im Vergleich zu den technischen Daten schwer zu verstehen sind.

Wenn ein Fehler oder eine Funktion zum Testen bereit ist, wird sie in "Bronze" umgewandelt. Dies löst einen Jenkins-Build aus, der den Code in eine vorgefertigte Umgebung überträgt. Unsere Tester (übrigens keine Supertechniker) haben einfach einen Link getroffen und kümmern sich nicht um die Quellcodeverwaltung. In diesem Build werden auch Tests usw. ausgeführt. Wir haben diesen Build hin und her verschoben und den Code tatsächlich in die Testumgebung übertragen, wenn die Tests (Einheit, Integration, Selen) fehlschlagen. Wenn Sie auf einem separaten System testen (wir nennen es Lead), können Sie verhindern, dass die Änderungen in Ihre QA-Umgebung übertragen werden.

Die anfängliche Angst war, dass wir viele Konflikte zwischen diesen Merkmalen haben würden. Es kommt vor, dass Feature X den Anschein erweckt, als würde Feature Y kaputt gehen, aber es ist selten genug und hilft tatsächlich. Es hilft dabei, eine breite Palette von Tests außerhalb des scheinbaren Kontextes der Änderung durchzuführen. Durch Glück werden Sie oft herausfinden, wie sich Ihre Veränderung auf die parallele Entwicklung auswirkt.

Sobald ein Feature die Qualitätssicherung bestanden hat, verschieben wir es in "Silber" oder "Inszenierung". Ein Build wird ausgeführt und die Tests werden erneut ausgeführt. Wöchentlich übertragen wir diese Änderungen auf unseren "Gold" - oder Produktbaum und stellen sie dann in unserem Produktionssystem bereit.

Entwickler beginnen ihre Änderungen mit dem Goldbaum. Technisch könnte man von der Inszenierung ausgehen, da diese bald steigen werden.

Notfallkorrekturen werden direkt in den Goldbaum geworfen. Wenn eine Änderung für die Qualitätssicherung einfach und schwierig ist, kann sie direkt in Silber übergehen, das den Weg zum Testbaum findet.

Nach unserer Veröffentlichung verschieben wir die Änderungen in Gold (Prod) in Bronze (Test), um alles synchron zu halten.

Möglicherweise möchten Sie die Basis neu erstellen, bevor Sie sie in Ihren Staging-Ordner verschieben. Wir haben festgestellt, dass das Löschen des Testbaums von Zeit zu Zeit ihn sauber hält. Es gibt Zeiten, in denen Funktionen im Testbaum aufgegeben werden, insbesondere wenn ein Entwickler das Programm verlässt.

Für große Funktionen für mehrere Entwickler erstellen wir ein separates gemeinsames Repo, fügen es jedoch gleich in den Testbaum ein, wenn wir alle bereit sind. Die Dinge neigen dazu, von der Qualitätssicherung abzuprallen. Daher ist es wichtig, dass Sie Ihre Änderungssätze isoliert halten, damit Sie sie hinzufügen und dann in Ihren Staging-Baum einfügen / quetschen können.

"Backen" ist auch eine schöne Nebenwirkung. Wenn Sie eine grundlegende Veränderung haben, möchten Sie eine Weile sitzen lassen, es gibt einen schönen Platz dafür.

Denken Sie auch daran, dass wir frühere Releases nicht pflegen. Die aktuelle Version ist immer die einzige Version. Trotzdem könnten Sie wahrscheinlich einen Master-Backbaum haben, in dem Ihre Tester oder Ihre Community sehen können, wie verschiedene Mitwirkende interagieren.

Ich würde mich nicht nur auf manuelle Tests verlassen. Ich würde das Testen jedes Feature-Zweigs mit Jenkins automatisieren. Ich habe ein VMWare-Labor eingerichtet, um Jenkins-Tests unter Linux und Windows für alle Browser auszuführen. Es ist wirklich eine großartige Cross-Browser- und plattformübergreifende Testlösung. Ich teste die Funktion / Integration mit Selenium Webdriver. Meine Selentests laufen unter Rspec. Und ich habe sie speziell geschrieben, um sie von jRuby unter Windows zu laden. Ich führe traditionelle Unit-Tests unter Rspec und Javascript-Tests unter Jasmine durch. Ich habe Headless-Tests mit Phantom JS eingerichtet.

In unserem Unternehmen können wir keine agile Entwicklung verwenden und benötigen für jede Änderung durch das Unternehmen eine Genehmigung. Dies verursacht viele Probleme.

Unser Ansatz für die Arbeit mit GIT ist folgender:

Wir haben "Git Flow" in unserem Unternehmen implementiert. Wir verwenden JIRA und nur genehmigte JIRA-Tickets sollten in Produktion gehen. Für die Testgenehmigung haben wir es mit einem separaten Testzweig erweitert.

Schritte zur Bearbeitung eines JIRA-Tickets sind:

1. Erstellen Sie einen neuen Zweig aus Develop-Branch
2. Nehmen Sie die Codeänderungen im Feature-Zweig vor
3. Ziehen Sie von Feature die Änderungen in den Test- / QS-Zweig
4. Nach der Genehmigung durch das Unternehmen ziehen wir den Wechsel vom Feature-Zweig in die Entwicklung
5. Die Entwicklung erfolgt häufig in einem Release und schließlich in der Hauptniederlassung

Durch die Aufteilung jeder Anforderung in eine eigene Funktion wird sichergestellt, dass nur genehmigte Änderungen in die Produktion übernommen wurden.

Der gesamte Prozess sieht folgendermaßen aus: