Frage Gated Check-ins / vorab getestete Commits für Git?


Ich betrachte die Migration von TFS (Team Foundation Server) zu Git, kann aber nichts finden, das mit der TFS-Unterstützung für Gated Check-Ins (auch als vorgetestet oder verzögertes Commit bezeichnet) übereinstimmt.

Atlassian Bamboo bietet keine Unterstützung für Gated Check-Ins. TeamCity unterstützt es ("verzögerte Commits" mit ihrer Terminologie), aber nicht für Git. Die Verwendung von Jenkins allein oder Jenkins + Gerrit hat große Nachteile und kommt der Gated-Check-In-Funktionalität in TFS nicht nahe. (Nachteile, die der Autor von Jenkins selbst in diesem Video erklärt: http://www.youtube.com/watch?v=LvCVw5gnAo0)

Git ist sehr beliebt (aus gutem Grund), also wie lösen Menschen dieses Problem? Was ist derzeit die beste Lösung?


24
2017-09-18 20:24


Ursprung


Antworten:


Wir haben gerade begonnen, git zu verwenden, und haben bereits getestete Commits mit Workflows implementiert (ich habe das gerade heute getestet).

Grundsätzlich hat jeder Entwickler ein persönliches Repository, auf das er Lese- / Schreibzugriff hat. Der Build-Server TeamCity baut in unserem Fall auf diesen persönlichen Repositories auf und überträgt dann, wenn er erfolgreich ist, die Änderungen auf das 'grüne' Repository. Entwickler haben keinen Schreibzugriff auf "grün", nur TeamCity Build Agents können dazu schreiben, aber Entwickler holen sich gemeinsame Updates von "grün".

So zieht Dev von "Grün" ab, schiebt sich auf persönliche, TeamCity-Builds von Privat, schiebt auf Grün.

Dieser Blogbeitrag zeigt das Grundmodell, das wir verwenden, mit GitHub-Gabeln für die persönlichen Repositories (die Verwendung von Forks bedeutet, dass die Anzahl der Repositories nicht aus dem Ruder läuft und mehr kostet und dass die Entwickler die persönlichen Builds so verwalten können, wie sie sind Sie können die Team City Build-Jobs erstellen, um ihren Code auf 'grün' zu setzen:

enter image description here

Das ist mehr Arbeit in TeamCity, da jeder Entwickler eine eigene Build-Konfiguration haben muss. Das müssen eigentlich 2 Konfigurationen sein, da TeamCity alle Build-Schritte auszuführen scheint (einschließlich des letzten "Push to Green" -Schritts), selbst wenn die vorherigen Build-Schritte fehlschlugen (wie die Tests :)), was bedeutete, dass wir einen persönlichen haben mussten Build für den Entwickler, dann eine andere Build-Konfiguration, die davon abhängig war, die einfach den Push ausführen würde, vorausgesetzt, der Build funktionierte.


15
2017-09-18 20:35



Auschecken Verigreen - Ein leichtes, serverseitiges Gated-Check-in-System. Es überprüft jedes Commit, bevor es seinen Weg in die Zweige findet, die das System schützt. Verigreen lässt nicht zu, dass ein fehlgeschlagener CI-Commit die Integration, die Veröffentlichung oder einen Zweig, der geschützt werden muss, durchbricht. Außerdem - es ist ein kostenloses, Open-Source-Projekt.

Wie es funktioniert: Verigreen fängt das Einchecken ab und führt die Verifizierung in einem Ad-hoc-Zweig durch - so dass im Falle eines fehlgeschlagenen Commits nur der entsprechende Entwickler betroffen ist.

  • Ein Pre-Receive-Hook fängt ab und erstellt einen Ad-hoc-Zweig des Codes.
  • Die Verifizierung wird über einen Jenkins-Job ausgeführt. Der Inhalt des Überprüfungsauftrags ist vollständig konfigurierbar.
  • Der verifizierte Code wird wieder in den geschützten Zweig eingebunden, während ein fehlgeschlagener Commit mit einer Benachrichtigung blockiert wird, die an den Entwickler gesendet wird.

enter image description here

Entscheidungen werden basierend auf dem folgenden Ablauf getroffen:

Verigreen - Basic Flow

Weitere Informationen finden Sie in der Wiki oder Verigreen.io Seite? ˅


8
2017-10-08 06:47



Ich denke danach 23. Oktober 2013 Die Antwort kann sein - Automatisches Zusammenführen in TeamCity.


3
2017-09-17 16:22



Git hat eine andere Philosophie - Commits sind einfach, begehen, wie Sie es wünschen. Wenn etwas nicht stimmt, können Sie es später ändern. Und Zusammenführungen sind einfach. So könnten Sie einen geeigneten Workflow organisieren, z. Entwickler könnten in einer oder mehreren separaten Zweigstellen festschreiben. Wenn ein Zweig getestet wird, könnte er in einen Hauptzweig zusammengeführt werden.


0
2017-09-18 20:37



Warum nicht TFS als zentrales Repository verwenden und GIT als lokale DVCS-Lösung nutzen?

Dies würde es Ihnen ermöglichen, lokal zu erstellen und zu committen und dann den gewünschten TFS-Server zu pushen und einen gated Build zu erstellen.

Manchmal ist es gut, das Beste aus beiden Welten zu haben ...


0
2017-09-22 21:44



Mit VS Team Services (fka Visual Studio Online) und TFS 2015 oder neuer können Sie verwenden Branch-Richtlinien, die eine Weitergabe erfordern für eine Pull-Anforderung als gated Checkin Workflow mit Git.


0
2018-03-21 13:25