it-swarm.dev

Wann sollten Codeüberprüfungen durchgeführt werden, wenn eine kontinuierliche Integration durchgeführt wird?

Wir versuchen, auf eine kontinuierliche Integrationsumgebung umzusteigen, sind uns jedoch nicht sicher, wann Codeüberprüfungen durchgeführt werden sollen. Nach dem, was ich über kontinuierliche Integration gelesen habe, sollten wir versuchen, Code mehrmals am Tag einzuchecken. Ich gehe davon aus, dass dies sogar für Funktionen bedeutet, die noch nicht vollständig sind.

Die Frage ist also, wann wir die Codeüberprüfungen durchführen.

Wir können dies nicht tun, bevor wir den Code eingecheckt haben, da dies den Prozess verlangsamen würde, bei dem wir keine täglichen Eincheckvorgänge durchführen können, geschweige denn mehrere Eincheckvorgänge pro Tag.

Wenn der Code, den wir einchecken, lediglich kompiliert wird, die Funktion jedoch nicht vollständig ist, ist eine Codeüberprüfung sinnlos, da die meisten Codeüberprüfungen am besten nach Abschluss der Funktion durchgeführt werden. Bedeutet dies, dass wir Codeüberprüfungen durchführen sollten, wenn eine Funktion abgeschlossen ist, dieser nicht überprüfte Code jedoch in das Repository gelangt?

33
SpecialEd

IMO, Sie sollten den Code überprüfen, bevor er in der Hauptzeile veröffentlicht wird, damit die Hauptleitung immer nur den Code mit der höchsten Qualität enthält.

OTOH, es könnte ein guter Punkt angeführt werden: "Warum sollte man sich die Mühe machen, zu überprüfen, ob die CI-Testautomatisierung nicht darauf ausgeführt wurde?". Daher wäre es vielleicht am besten, den Entwicklern jeweils einen privaten Zweig zu geben, den der CI-Server für sie erstellt und testet . Auf diese Weise werden sie zuerst festgeschrieben und dort gepusht. Sobald sie erfolgreich sind, wird sie überprüft und dann zur Hauptlinie zusammengeführt (wo sie erneut über den CI-Server ausgeführt wird).

Sie sollten auf jeden Fall den Code überprüfen, der nicht vollständig ist, um sicherzustellen, dass das Gerüst für zukünftige Funktionen vorhanden ist, oder zumindest, dass nichts eingefügt wird, was die Implementierung dieser zukünftigen Funktionen verhindern würde.

Beachten Sie außerdem, dass Codeüberprüfungen nicht langsam oder synchron sein müssen - ein Tool wie Gerrit oder Reviewboard oder ähnliches kann sie asynchron und ziemlich schmerzlos machen.

(Vollständige Offenlegung: Ich habe früher für SmartBear gearbeitet, Hersteller von Code Collaborator, einem Tool zur Codeüberprüfung.)

12
pjz

Paarprogrammierung einrichten?

Der gesamte Code wird während der Eingabe überprüft, ohne den Prozess zu erweitern oder einen weiteren Schritt einzuführen.

11
Stefan

Hier ist der Auszug aus dem Autor der kontinuierlichen Lieferung:

Jez Humble Schreibt als:

Ich schreibe gerade einen Blog-Beitrag zu diesem Thema. Die kurze Antwort lautet:

  • Der beste Weg, um Code zu überprüfen, ist die Paarprogrammierung
  • Es ist eine schlechte Idee, die Zusammenführung zur Hauptlinie zu steuern, indem beispielsweise ein separater Zweig für einen formellen Überprüfungsprozess erstellt wird. Dies verhindert eine kontinuierliche Integration (der beste Weg, um das Risiko von schlechten Änderungen zu verringern, was Sie wirklich anstreben).
  • Ich denke, Gerrit ist ein nettes Tool, aber es sollte verwendet werden nach Einchecken (so ist es tatsächlich gestaltet). Teil der Aufgabe der leitenden Entwickler ist es, alle Check-Ins zu überprüfen. Sie könnten beispielsweise einen Feed abonnieren.

Zusammenfassend: Codeüberprüfung ist gut. So gut, wir sollten es kontinuierlich tun, indem wir Paare programmieren und Commits überprüfen. Wenn ein älterer Entwickler ein schlechtes Commit findet, sollte er sich mit der Person zusammenschließen, die es begangen hat, um das Problem zu beheben.

Das Zusammenführen der Zusammenführung mit der Hauptlinie bei einer formalen Überprüfung ist schlecht, und das Erstellen von Zweigen dazu ist besonders schlecht, aus dem gleichen Grund, aus dem Feature-Zweige schlecht sind.

Vielen Dank,

Jez.

der ursprüngliche Link lautet: https://groups.google.com/forum/#!msg/continuousdelivery/LIJ1nva9Oas/y3sAaMtibGAJ

7
Alagesan Palani

Ich weiß nicht, ob es der beste Weg ist, es zu tun ... aber ich werde erklären, wie wir es tun. Ein oder mehrere Entwickler arbeiten an einem bestimmten Zweig und schreiben ihren Code so oft wie möglich fest, um Zeitverschwendung beim Zusammenführen zu vermeiden, die sonst nicht möglich gewesen wäre. Erst wenn der Code fertig ist, wird er in den Kopf übernommen. Nun, das ist für die Commits und Branch/Head-Sache.

Für die Codeüberprüfung verwenden wir Sonar als unser kontinuierliches Integrationstool (und Maven/Jenkins für die Interaktion mit Sonar), um uns jeden Morgen neue Testergebnisse, Codeabdeckung und automatische Codeüberprüfung zu liefern (Builds) werden jeden Abend durchgeführt), damit wir Entwickler jeden Morgen maximal eine Stunde damit verbringen können, ihre Probleme/Code-Gerüche zu beheben. Jeder Entwickler übernimmt die Verantwortung (auch stolz!) Für die Funktion, die er schreibt. Das ist eine automatische Codeüberprüfung, die sich hervorragend dazu eignet, potenzielle technische/architektonische Probleme zu finden. Wichtiger ist jedoch zu testen, ob diese neu implementierten Funktionen das tun, was das Unternehmen von ihnen verlangt.

Und dafür gibt es zwei Dinge: Integrationstests und Peer-Code-Überprüfung. Integrationstests helfen dabei, hinreichend sicher zu sein, dass der neue Code den vorhandenen Code nicht beschädigt. Die Peer-Code-Überprüfung wird am Freitagnachmittag durchgeführt, was etwas entspannter ist :-) Jeder Entwickler ist einem Zweig zugeordnet, an dem er nicht arbeitet. Er benötigt einige Zeit, um die Anforderungen des zu lesen neue Funktion zuerst und prüft dann, was getan wurde. Seine wichtigste Aufgabe ist es, sicherzustellen, dass der neue Code wie erwartet funktioniert , wenn die Anforderungen erfüllt sind, und nicht gegen unsere eigenen "Regeln" verstößt (verwenden Sie dieses Objekt für das und nicht das eine) ist leicht zu lesen und ermöglicht eine einfache Erweiterung.

Wir haben also zwei Codeüberprüfungen, eine automatische und eine "menschliche", und wir versuchen zu vermeiden, dass nicht überprüfter Code in den Zweig HEAD) übernommen wird. Jetzt ... kommt es manchmal aus verschiedenen Gründen vor, wir ' Wir sind alles andere als perfekt, aber wir versuchen, ein faires Gleichgewicht zwischen Qualität und Kosten zu halten (Zeit!)

@pjz bietet auch eine gute Antwort und er erwähnt Tools zur Codeüberprüfung. Ich habe noch nie etwas benutzt, daher kann ich nichts dazu sagen ... obwohl ich in der Vergangenheit versucht war, mit Crucible zu arbeiten, da wir bereits JIRA .

5
Jalayn

Ich denke, das Hauptkonzept, das helfen wird, ist das eines "Staging" -Bereichs.

Ja, Sie möchten keinen fehlerhaften Code einchecken. Sie sollten aber auch häufig Code einchecken. Bedeutet dies Perfektion? ;) Nein. Verwenden Sie einfach mehrere Bereiche und ein DVCS wie git.
Auf diese Weise nehmen Sie Änderungen (lokal) vor und übernehmen diese häufig, während Sie testen und entwickeln, bis die Tests bestanden sind. Anschließend drücken Sie zur Codeüberprüfung in einen Staging-Bereich.

Sie sollten dann von Staging zu anderen QS-Maßnahmen wie Browsertests und Benutzertests wechseln. Schließlich können Sie zu einem Volumentestbereich gehen und schließlich produzieren.

Es gibt auch Workflows innerhalb dieses Bereichs, z. B. alle, die in der Hauptniederlassung arbeiten oder einzelne Zweige für alle Bemühungen verwenden.

Die kontinuierliche Integration selbst kann auch auf mehreren Ebenen erfolgen. Es kann lokal für einen Entwicklercomputer sein, bis die Tests bestanden sind, und es kann sich auch in Staging- und Qa-Bereichen befinden, wenn Code an sie gesendet wird.

4
Michael Durrant

Codeüberprüfung und kontinuierliche Integration entkoppeln!

Warum hast du sie kombiniert?

3
Nikolay Fominyh

Wir verwenden git flow für unsere Repositorys und führen unsere Codeüberprüfungen durch, wenn es darum geht, in den Entwicklungszweig zu verschmelzen.

Alles, was sich in der Entwicklung befindet, ist vollständig, bereitstellbar und wird auf Code überprüft.

Wir haben auch CI für unsere Entwicklungs- und Master-Niederlassungen eingerichtet.

2
sevenseacat

Ich denke wirklich, wirklich, wirklich, dass Sie ein DVCS (z. B. Mercurial, Git) benötigen würden, um dies natürlich zu tun. Mit einem CVCS würden Sie einen Zweig brauchen und hoffen, dass es für jeden Gott, den Sie haben, keine verschmelzende Hölle gibt.

Wenn Sie ein DVCS verwenden, können Sie den Integrationsprozess so gestalten, dass der Code ihn bereits überprüft, bevor er auf dem CI-Server eintrifft. Wenn Sie kein DVCS haben, kommt der Code vor der Überprüfung auf Ihrem CI-Server an, es sei denn, Codeprüfer überprüfen den Code auf dem Computer jedes Entwicklers, bevor sie ihre Änderungen übermitteln.

Eine erste Möglichkeit, insbesondere wenn Sie keine Repository-Verwaltungssoftware haben, mit deren Hilfe persönliche Repositorys veröffentlicht werden können (z. B. Bitbucket, Github, Rhodecode), besteht darin, hierarchische Integrationsrollen zu haben. In den folgenden Diagrammen können Sie die Arbeit der Entwickler durch Leutnants überprüfen lassen und den Diktator als Hauptintegrator überprüfen lassen, wie die Arbeit der Leutnants zusammengeführt wurde.

enter image description here

Eine andere Möglichkeit, dies zu tun, wenn Sie über eine Repository-Verwaltungssoftware verfügen, besteht darin, einen Workflow wie den folgenden zu verwenden:

enter image description here

Repository-Verwaltungssoftware hilft normalerweise dabei, Benachrichtigungen auszugeben, wenn Aktivitäten in Repositorys (z. B. E-Mail, RSS) vorhanden sind, und Pull-Anfragen zuzulassen. Die Codeüberprüfung kann organisch während Pull-Anforderungen erfolgen, da Pull-Anforderungen normalerweise dazu führen, dass Personen Gespräche führen, um den Code zu integrieren. Nehmen Sie als Beispiel diese öffentliche Pull-Anfrage . Der Integrationsmanager kann tatsächlich nicht zulassen, dass Code in das gesegnete Repository (auch als "zentrales Repository" bezeichnet) gelangt, wenn der Code korrigiert werden muss.

Am wichtigsten ist, dass Sie mit einem DVCS weiterhin einen zentralisierten Workflow unterstützen können. Sie müssen keinen weiteren ausgefallenen Workflow haben, wenn Sie nicht möchten. Mit einem DVCS können Sie jedoch ein zentrales Entwicklungsrepository vom CI trennen server und geben Sie jemandem die Berechtigung, die Änderungen vom Entwickler-Repo zum CI-Repo zu übertragen, sobald eine Code-Überprüfungssitzung durchgeführt wurde.

P.: Gutschrift für die Bilder gehen zu git-scm.com

2
dukeofgaming

Bedeutet dies, dass wir Codeüberprüfungen durchführen sollten, wenn eine Funktion abgeschlossen ist, dieser nicht überprüfte Code jedoch in das Repository gelangt?

Weit oben ist die Art und Weise, wie ich es in mindestens drei Projekten gesehen habe, die sich intensiv mit kontinuierlicher Integration beschäftigten, und meiner Erinnerung nach hat es wie ein Zauber funktioniert. Diese Vorgehensweise ist bekannt als Code-Überprüfungen nach dem Festschreiben - Suchen Sie im Internet nach diesem Begriff, wenn Sie an Details interessiert sind.

  • Auf der anderen Seite war der einzige Fall, in dem ich im Projekt versucht habe, Codeüberprüfungen vor dem Festschreiben mit CI zu "heiraten", ziemlich schmerzhaft. Nun, wenn die Dinge zu 100% reibungslos liefen, war es in Ordnung - aber selbst seltene Unterbrechungen (wie wenn Haupt- und Backup-Prüfer beispielsweise einige Stunden lang nicht verfügbar waren) machten spürbaren Stress. Mir ist auch aufgefallen, dass die Moral des Teams etwas gelitten hat - es gab etwas zu viele Konflikte.
1
gnat

Warum nicht mehr als ein Repository haben? Eine für "tägliche" Arbeit, das Fahren eines Servers für kontinuierliche Integration, das Ausführen aller Komponententests und Integrationstests, um die enge Rückkopplungsschleife von Nizza zu erhalten, und eine andere für "stabile" Arbeit, bei der Commits weniger häufig sind, aber überprüft werden müssen.

Abhängig von dem Pfad, den Änderungen beim Durchlaufen des Systems einschlagen, kann dies eine komplexe Lösung sein und funktioniert möglicherweise am besten, wenn Tools wie Git oder Mercurial Queues verwendet werden (Einschränkung: Ich habe keine im Zorn verwendet). Aber viele Organisationen machen etwas Ähnliches.

1
William Payne