Der Prozess beginnt mit einer Aufgabe in Ihrem Issue Tracker oder Projektmanagementsystem: Jira, Bugzilla, Mantis, OnTime oder Ihre eigene interne Lösung. Der Schlüssel dazu ist, dass alles, was Sie tun, mit einer Aufgabe verbunden sein muss. Ganz gleich, ob es sich um eine neue Funktion oder eine Fehlerbehebung handelt - erstellen Sie eine Aufgabe dafür.

Als nächstes erstellen Sie einen Zweig für diese Aufgabe.

Wir empfehlen eine einfache Namenskonvention für die Verzweigungen: Ein Präfix ("Aufgabe" im Beispiel), gefolgt von der Aufgabennummer im Issue Tracker. Auf diese Weise können Sie Änderungen vollständig nachvollziehen.

Bearbeiten Sie den Aufgabenzweig und nehmen Sie so viele Überprüfungen vor wie nötig. Erläutern Sie jeden Schritt in den Kommentaren, um jedem Prüfer Klarheit zu verschaffen.

Wenn die Aufgabe erledigt ist, setzen Sie ein "Status"-Attribut für den Zweig auf "gelöst".

Alternativ können Sie es auch in Ihrem Issue Tracker als abgeschlossen markieren. Es hängt alles von Ihren speziellen Werkzeugen ab und davon, wie Sie den Arbeitsablauf am Ende tatsächlich umsetzen wollen.

Sobald Sie Ihre Aufgabe als erledigt markieren, kann sie von einem Kollegen überprüft werden.

Jetzt ist der Prüfer an der Reihe, sich Ihre Änderungen anzusehen und zu prüfen, ob er Fehler, Unstimmigkeiten oder Ungereimtheiten in Ihrem Kodierungsstil oder irgendwelche Aspekte des Designs entdecken kann, die geändert werden sollten. Ist dies der Fall, wird die Aufgabe erneut geöffnet und der Zyklus beginnt von neuem.

Die Validierung ist ein optionaler Schritt.

Einige Teams "validieren" die Aufgabe - ein anderes Teammitglied führt einen kurzen Sondierungstest durch, um sicherzustellen, dass die neue Funktion oder Änderung sinnvoll ist. Sie suchen nicht nach Fehlern (dafür sorgen automatisierte Tests), sondern betrachten die Änderung aus der Sicht des Kunden. Der Status kann im Attribut auf "validiert" gesetzt werden.

Konfigurieren Sie Ihr Continuous-Integration-System (CI) so, dass es alle Zweige überwacht, die ein bestimmtes Attribut gesetzt haben. Ein Zweig wird erst dann vom CI-System berücksichtigt, wenn er einen bestimmten Status erreicht (in diesem Fall "validiert").

Sobald die Aufgabe überprüft/validiert ist, wird der Aufgabenzweig automatisch getestet, bevor er mit dem Hauptprojekt zusammengeführt wird.

Wenn die Testsuite die Zusammenführung besteht, wird sie bestätigt und an das CI-System zum Erstellen und Testen übergeben. Dieses Verfahren trägt dazu bei, dass der Aufbau nicht unterbrochen wird. Wenn dies fehlschlägt, wird der Prozess neu gestartet, und Sie müssen von der Hauptseite aus neu basen, um alle Konflikte zu lösen.

Wenn die Tests erfolgreich sind, wird die Zusammenführung eingecheckt und der Zweig ist nun bereit, ausgeliefert zu werden. Beachten Sie, dass der Status jetzt auf "zusammengeführt" gesetzt ist.

Wenn die neue Version bereit für den Einsatz ist, wird der neue Änderungssatz auf main als solcher gekennzeichnet und die Software in der Produktion eingesetzt.

Sie können nach jeder neuen Aufgabe, die diesen Zyklus durchläuft, eine neue Freigabe erhalten, oder Sie können beschließen, einige davon zu gruppieren. Bei der kontinuierlichen Bereitstellung ist die Bereitstellung jeder Aufgabe in der Produktion der logischste Arbeitsablauf.

Mit Unity Version Control kann der Schritt des automatisierten Testens und Zusammenführens mithilfe des Plug-ins für das von Ihnen gewählte CI-Tool, wie Jenkins, Bamboo oder Unity Cloud Build, konfiguriert werden .

Dieser Schritt kann auch mit der Mergebot-Funktion von Unity Version Control orchestriert werden. Der Mergebot kann die Zweige zusammenführen und einen Build auslösen, um sicherzustellen, dass es funktioniert. Zusammenführungen werden nur bestätigt, wenn der Build gut ist, um fehlerhafte Builds zu vermeiden.

Wir halten uns gerne an die folgende Namenskonvention: Präfix + Aufgabennummer. Die Zweige könnten zum Beispiel die Namen Aufgabe1213, Aufgabe1209 und Aufgabe1221 tragen. Das Präfix ist "Aufgabe", und die Zahl steht für die tatsächliche Aufgabennummer im zugehörigen Issue Tracker.

Der Screenshot zeigt auch eine Beschreibung für jeden Zweig zusammen mit der Nummer, da der Zweig-Explorer die Nummer aus dem Issue Tracker abruft. Sie können auch die Zweigbeschreibung sehen, indem Sie "Zweigaufgabeninfo anzeigen" wählen.

Die Scrum-Regeln besagen, dass Aufgaben nicht länger als 16 Stunden dauern sollten. Auf diese Weise bleiben die Projektfristen unter Kontrolle.

Aufgabenverzweigungen müssen schnell geschlossen werden. Idealerweise sollten Sie viele kleine Aufgaben haben, die Sie in wenigen Stunden erledigen können. Diese Struktur hilft, den Projektrhythmus beizubehalten und erleichtert die kontinuierliche Bereitstellung. Eine größere Aufgabe, die sich zum Beispiel über eine Woche erstreckt, bringt den Zyklus zum Stillstand.

Eine rote Fahne, die Sie im Auge behalten sollten: Erstellen Sie keine "Machetenschnitt"-Aufgaben. Wenn Sie eine Aufgabe in kleinere Teile zerlegen müssen, vergewissern Sie sich, dass die Aufgabe für sich genommen immer noch sinnvoll ist und unabhängig eingesetzt werden kann.

Aufgabenverzweigungs-Workflows können nur dann erfolgreich sein, wenn sie vom gesamten Team mitgetragen werden.

Wie bei jedem DevOps-Prozess gibt es auch bei diesem Arbeitsablauf eine kulturelle Komponente. Bei den Aufgabenbereichen geht es darum, Fortschritte offen zu kommunizieren und Silos zu vermeiden. Bevor Sie einen Arbeitsablauf oder eine bestimmte Art der Aufgabenbearbeitung vorschreiben, müssen Sie sich um eine Anpassung bemühen. Helfen Sie den Teammitgliedern zu verstehen, welche Vorteile es hat, einen kleinen Teil einer größeren Aufgabe heute abzuschließen, anstatt sich länger mit größeren Aufgaben herumzuschlagen.

Fragen Sie sich selbst (oder Ihre Teamkollegen): Brauchen Sie wirklich den Code, den Sie gerade in Aufgabe1213 fertiggestellt haben, um Aufgabe1209 zu starten?

Die Aufgaben sind in der Regel viel unabhängiger, als Sie vielleicht denken. Ja, sie können dasselbe Thema betreffen, aber Sie müssen nicht genau denselben Code anfassen. Sie können einfach etwas Neues hinzufügen und darauf vertrauen, dass die Zusammenführung ihre Aufgabe erfüllt.

Nehmen wir an, dass es sich bei 1213 und 1209 im obigen Beispiel um Fehlerbehebungen und nicht um Aufgaben handelt. Sie wollen nicht, dass das eine vom anderen abhängt. Sie wollen, dass sie so schnell wie möglich in die Hauptrolle schlüpfen und freigelassen werden. Auch wenn sie denselben Code berühren, handelt es sich um unterschiedliche Korrekturen.

Jede Überprüfung muss dem Prüfer helfen, Ihren Gedankengang und Prozess nachzuvollziehen, um zu verstehen, wie Sie die Aufgabe angegangen sind.

Das Hinterlassen von Details in den Kommentaren zu Ihrem Checkin hilft dem Prüfer, da er nicht die gesamte Filiale durchsuchen muss. Stattdessen diffundieren sie Changeset für Changeset. Und sie folgen der aufgezeichneten Erklärung, die Sie zur Verdeutlichung der einzelnen Phasen der Aufgabe aufgenommen haben. Sie werden keine fett gedruckte Liste mit über 100 geänderten Dateien vorfinden. Stattdessen werden sie Schritt für Schritt vorgehen.

Jeder Aufgabenzweig muss nach seiner Fertigstellung integrationsfähig sein. Wenn eine Änderung empfindlich ist oder das Produkt in eine unangenehme Lage bringt, sollte die Aufgabe nicht als abgeschlossen betrachtet werden.

Dies ist ein geringer Preis für die Vorteile der Automatisierung. Das Team muss sich auf die Definition von "fertig", d. h. "produktionsreif" einigen. Im Gegenzug haben Sie die Gewissheit, dass die Überführung Ihrer Aufgabe in die Produktion einfach und vollständig automatisiert ist und nicht zu einer Feueralarmübung um 2:00 Uhr morgens führen wird.

Was sind Toggle-Funktionen? Diese sind für die kontinuierliche Bereitstellung entscheidend. Diese Technik der Softwareentwicklung ermöglicht es, Funktionen zu testen, bevor sie fertiggestellt und zur Veröffentlichung bereit sind.

Ein Feature Toggle kann das Feature während der Laufzeit ausblenden, aktivieren oder deaktivieren. Damit können Sie eine Funktion nur für das Entwicklerteam, eine kleine Anzahl von Early Adopters oder für alle aktivieren. So kann ein Entwickler beispielsweise eine Funktion für Tests aktivieren und sie für andere Benutzer während der Entwicklung deaktivieren.

Schauen wir uns ein Beispiel an. Sie haben eine große Funktion, die in sieben Teile aufgeteilt ist, die in Aufgaben umgewandelt und mit Hilfe von Aufgabenzweigen implementiert werden sollen. Wie ist es möglich, Teil 4 einzusetzen, wenn sonst nichts fertig ist?

Teil 4 kann mit dem Hauptzweig zusammengeführt und sogar eingesetzt werden, während er noch versteckt ist, indem man eine Funktion umschaltet.

Versteckt bedeutet nicht, dass der neue Code vor der Veröffentlichung nicht mehr getestet wird. Wenn die gesamte Funktion aktiviert werden kann, sind die einzelnen Teile bereits mehrfach getestet worden. Die Integration des letzten Teils wird keinen Big-Bang-Zusammenschluss auslösen; es handelt sich nur um einen kleineren Teil, der in den Hauptteil übergeht.