Einführung einer Versionskontroll-Verzweigungsrichtlinie für ein kleines Team

Ich bin ein Auftragnehmer, der kürzlich mit einer Firma angefangen hat.

Das Team besteht aus 3 Entwicklern, bestehend aus 2 Entwicklern der Junior- bis Mittelstufe, von denen einer demnächst auf derselben Stufe startet, und mir selbst (6 Jahre xp). Für die beiden bestehenden Entwickler ist es ihre erste Stelle außerhalb der Universität / Hochschule, und sie hatten noch nie einen leitenden Entwickler, der ihre Arbeit beaufsichtigte.

Es gibt keine explizite Versionskontrollrichtlinie. Entwickler führen die gesamte Entwicklung auf dem Stamm durch und stellen sie dann direkt von ihren Entwicklungsmaschinen in der Produktion bereit. Das bestehende Team ist mit dem Verzweigen nicht vertraut.

Ich ändere das alles und führe CI, TDD-Test- / Staging- / Produktionsserver usw. zusammen mit einer Versionskontrollrichtlinie ein, um dies zu ergänzen.

Das Quellcodeverwaltungssystem ist TFS, das ich noch nie benutzt habe. Es ist als ein riesiges Repository konfiguriert.

Ich habe ein paar Hinweise für sie aufgeschrieben, aber gibt es noch etwas, das ich hinzufügen / ändern sollte, unter Berücksichtigung der Erfahrung des Teams?

Versionskontrollrichtlinie

Die Entwicklung erfolgt am Kofferraum

Wenn eine Änderung voraussichtlich länger als eine Woche dauert, sollte sie auf einem Zweig durchgeführt werden, wobei regelmäßig vom Stamm in den Zweig übergegangen wird, um zu verhindern, dass die beiden nicht mehr synchron sind.

Geben Sie die für den Produktionscode erstellten Zweige frei. Dieser Zweig sollte nur stabilen Code enthalten. Wir können entweder einen Veröffentlichungszweig haben, der einmal pro Sprint vom Stamm aktualisiert wird, oder wir können für jede Woche einen eigenen Veröffentlichungszweig erstellen.

Wenn eine dringende Fehlerbehebung vorgenommen werden muss, die sich auf den Produktionscode auswirkt, wird sie im Release-Zweig durchgeführt und wieder in den Stamm integriert.

Wenn wir die Ein-Release-Zweig-Strategie anwenden, wird der Stamm gegen Ende des Sprints einmal pro Sprint in den Release-Zweig eingebunden.

Wenn wir die Freigabestrategie für einen Zweig anwenden, wird der Trunk NIEMALS in den Freigabezweig eingebunden

In einigen Szenarien kann es erforderlich sein, den Fehler zweimal in verschiedenen Zweigen zu beheben, wenn die Zweige zu stark voneinander abweichen. Wenn wir kurze Sprints machen, sollte dies nicht zu oft passieren.

Ich plane drei Server. Testumgebung, in der immer der neueste Code im Repository ausgeführt wird. Eine Staging-Umgebung, in der der neueste Release Candidate für das Staging / Testen von Release Candidate-Code und UAT-Zwecken ausgeführt wird, sowie die Produktionsumgebung.

Der Grund, warum ich das vorhabe, ist, dass der Client bisher nur interne Software erstellt hat. Das neueste Projekt richtet sich an einen hochkarätigen Medienkunden, und ich bin der Meinung, dass das Team ein professionelleres Entwicklungsmodell übernehmen muss als das, was es derzeit tut.

Im Moment kann ein Benutzer beispielsweise das Team mit einem Fehlerbericht anrufen. Die Entwickler lokalisieren und beheben den Fehler, führen einen schnellen Augentest auf ihren eigenen Computern durch und setzen ihn dann direkt in der Produktion ein. Kein automatisiertes Testen oder so.

Im Nachhinein denke ich, dass der Feature-Zweig ein Schritt zu weit ist und ich werde das entfernen.

Im Wesentlichen handelt es sich also um a) überhaupt keine Verzweigung, b) einen Freigabezweig und den Stamm, und c) einen Freigabezweig pro Freigabe und Stamm.

Ich neigte mich zu Letzterem. Mein erster Gedanke wäre, dass sowohl ein Release-Kandidat als auch ein Release gleichzeitig auf getrennten Servern (UAT / Production) verfügbar sein müssten, aber effektiv ist der Trunk zu jedem Zeitpunkt der Release-Kandidat, also ein Zweig pro Die Befreiung neigt sich dem Wahnsinn zu. Mein einziger Gedanke wäre, wenn wir nicht möchten, dass unsere Stakeholder den Entwicklungscode sehen, dann brauchen wir möglicherweise einen separaten Zweig für Release-Kandidaten, aber YAGNI und all das ...

Für ein Team von 3-4 Entwicklern schlagen Sie viel zu viele Zweige vor.

Jeder Zweig, den Sie erstellen, ist ein zusätzlicher Aufwand, der mit Kosten verbunden ist (Zeitaufwand für das Zusammenführen, Verfolgen des Standorts usw.). Sie müssen sicherstellen, dass der Nutzen einer Niederlassung die Kosten überwiegt.

Denken Sie daran, dass der einzige wirkliche Vorteil einer Verzweigung die Code-Isolierung ist. Das heißt, Sie brauchen einen konkreten Grund, um den Code zu isolieren.

Es ist verrückt, für jeden Sprint einen eigenen Release-Zweig zu haben . Warum brauchen Sie den Code von einem Sprint, der vom Code für den nächsten isoliert ist? Warum nicht einfach einen einzigen stabilen Release-Zweig haben, der bei jedem Sprint übertragen wird?

Wenn eine Änderung voraussichtlich länger als eine Woche dauert, sollte sie auf einem Zweig durchgeführt werden, wobei regelmäßig vom Stamm in den Zweig übergegangen wird, um zu verhindern, dass die beiden nicht mehr synchron sind.

Fast jede nicht triviale neue Funktion wird mindestens eine Woche in Echtzeit in Anspruch nehmen, nachdem Sie die Entwicklung, Entwicklertests, täglichen Unterbrechungen und andere Aktivitäten usw. berücksichtigt haben.

Was ist eine "regelmäßige Zusammenführung"? Täglich? Wöchentlich? Jede Zusammenführung benötigt Zeit - Sie müssen sicherstellen, dass der Zielzusammenführungszweig nach Ihren Änderungen erstellt und ausgeführt wird. In einem kleinen Team ist das häufige Zusammenführen mit viel Aufwand verbunden.

Wir haben ein Team von 4 Entwicklern, die an einer Codebasis von über 1 Million Zeilen arbeiten, und so arbeiten wir:

• Hauptzweig, in dem die gesamte Entwicklung stattfindet
• Ein Zweig pro Hauptversion (ungefähr einmal pro Jahr)

Die wichtigste Regel lautet: Checken Sie keinen Code ein, der nicht erstellt wird.

Das ist es. Einfach, leicht zu verstehen, erhält die Isolierung, die wir benötigen (wir können jederzeit ein Release-Build für jede Version erstellen).

Das Beste daran, alle Entwicklungsarbeiten auf einem Zweig erledigen zu lassen:

1. Entwickler sind immer miteinander synchronisiert. Keine schmerzhaften Zusammenschlüsse, da zwei Entwickler wochenlang in ihren eigenen Filialen waren und inkompatible Änderungen verursachten.
2. Beschädigte Builds werden am selben Tag gefunden. Wir haben einen nächtlichen Build, der den neuesten Code auf main ausführt. Wenn jemand Code eincheckt, der aus irgendeinem Grund nicht erstellt wurde, werden wir es sofort wissen.
3. Wenn alle immer am gleichen Code arbeiten, erhöht sich die Wahrscheinlichkeit, dass ein Fehler eher früher als später gefunden wird.
4. Kein Zusammenführungsaufwand außer gezielten Korrekturen zum Freigeben von Zweigen. In einem kleinen Team ist dies das große.

Sie haben ein paar Hinweise für sie aufgeschrieben, aber Sie haben nicht erklärt, warum Ihr Ansatz besser ist als der, den sie bereits verwenden . Dies kann problematisch sein. Wenn Sie der Meinung sind, dass "wir es so machen, weil ich über sechs Jahre Berufserfahrung verfüge und Sie dies nicht tun" (und wenn Sie Ihre Frage lesen, sieht es genau so aus), seien Sie bereit, sich hassen zu lassen Ihre Teammitglieder, die versuchen werden, alles zu tun, um Ihre Konzepte nicht anzuwenden.

Haben sie ein Problem, das gelöst werden muss? Es ist wichtig, diese Frage zuerst zu beantworten, da sie entweder tatsächlich ein Problem haben und Ihre Vorschläge begrüßen, oder sie arbeiten perfekt, so wie sie es derzeit tun, und Sie versuchen nur, Ihre Arbeitsweise voranzutreiben , nur weil Sie es vorziehen arbeite so.

Das Erzwingen der Verwendung von Zweigen kann sich letztendlich äußerst negativ auswirken . Die Arbeit mit einem Kofferraum ist besonders in einer agilen Umgebung einfach. Ein Entwickler schreibt Änderungen am Trunk fest und verarbeitet schließlich kleine Konflikte. Diese Änderungen werden sofort von der Continuous Integration-Plattform verwendet. Mit Zweigen:

• Ein Entwickler muss überlegen, wo sich die Änderung befinden soll.

• Jemand muss Zweige verwalten und von Zweigen zum Stamm verschmelzen,

• Zusammenführungen zwischen Zweigen werden seltener als Commits durchgeführt. Dies bedeutet, dass sich jemand mit Konflikten befassen muss, die größer und schwieriger zu handhaben sind als ein Konflikt zwischen zwei Commits.

• Jeder Commit findet nicht notwendigerweise seinen Weg in die kontinuierliche Integration, wodurch die Informationen, die die Entwickler über die Auswirkungen eines Commits (insbesondere Regressionen) erhalten, verzögert werden.

Die Tatsache, dass:

Das bestehende Team ist mit dem Verzweigen nicht vertraut

macht die Dinge noch schlimmer. Ich arbeitete in einem Team unerfahrener Programmierer, in dem ein unerfahrener Manager beschloss, mit Zweigen zu spielen. Dies führte zu viel ( viel ) Zeitverschwendung und ist genau das, was Sie bei einem Projekt mit Terminen vermeiden möchten.

Wie Mainma sagt, sei vorsichtig mit der Verzweigung. Sie erwähnen, alle paar Wochen zu verzweigen. Ist es wirklich notwendig, viele Zweige zu haben?

Alternativ können Sie auch ein Pull-Modell anstelle eines Push-Modells verwenden. Wenn Sie Git oder Mercurial verwendet haben, kann ein Integrationsserver die Änderungen überprüfen, bevor er sie auf den zentralen Server überträgt. In TFS können Sie etwas Ähnliches mit gated Check-Ins tun . Auf diese Weise können Sie eine Validierung durchführen und die Komplexität von Zweigen vermeiden.