Wie wichtig sind tägliche Builds? [abgeschlossen

Question

Eines der Kriterien der Joel -Test ist täglich Builds. Die Idee ist, dass, wenn der Build gebrochen ist, wer gebrochen hat, es gibt, um es zu reparieren. Wenn der Build nicht repariert werden kann, muss jeder eine alte Version überprüfen und daran arbeiten. Ich kann verstehen, wie dies bei der zentralisierten Versionskontrolle ziemlich schlecht sein kann, wenn es wichtig ist, so weit wie möglich zu verschmelzen und zu verzweigen, aber dies klingt nur nach einem kleinen Ärgernis für die Distributed -Versionskontrolle. Stimmst du dem zu? Gibt es andere Gründe, warum tägliche Builds wichtig sind?

Answer 1

Ich denke, was hier wichtig zu beachten ist, ist das regulär baut Hilfe Fangen Sie eher früher als später Fehler auf. Es tut es nicht haben täglich sein, aber oft genug. Idealerweise kann es auch Ihre Einheitstests ausführen.

Das Ziel ist es, herauszufinden, wann ein Build vor der endgültigen Testphase bricht, um sie so schnell wie möglich zu finden.

Richten Sie es einfach ein, um Ihre Hauptentwicklungszweig (ES) aufzubauen.

Wir verwenden es bei der Arbeit (obwohl wir stündlich bauen), und oft, wenn wir vergessen, uns nur Stunden vor der Veröffentlichung zu Problemen zu stellen.

Answer 2

Müssen dem ein wenig hinzufügen (und @goodenoughs):

Dies klingt jedoch nur nach einem kleinen Ärgernis für die Distributed -Versionskontrolle.

Nachdrücklich nein - was ein "Server" -Build Ihnen sagt, dass Ihr Trunk seine Tests mehr oder weniger aus sauber erstellt und besteht (je weniger Konfiguration, die Sie für Ihre Umgebung benötigen).

Ich denke über einen Wechsel zu DVCs nach, aber selbst wenn Sie es getan haben, werden Sie meine kontinuierliche Integration aus meinen kalten toten Händen ziehen.

Um ein einfaches Beispiel zu nutzen - Sie entwickeln eine Funktion "A" Er entwickelt eine Funktion "B" verteilt oder nicht irgendwann müssen Sie alles zusammenfügen. Wenn Sie sich bei Ihnen verpflichten, vergessen Sie, eine Datei hinzuzufügen, die die App erstellt wird Auf Ihrer Maschine, aber es wird nirgendwo anders. Wenn Sie also den Build auf Ihren "Koffer" drücken Vor Jeder zieht Ihren nicht ganz so vollständigen Code, den Sie Schritte unternehmen können.

Wenn Sie an einem Projekt mit mehreren Entwicklern arbeiten, müssen Sie definieren können, woher Release -Versionen stammen - dem Kofferraum - dies gilt unabhängig davon, wie Ihre Versionskontrolle funktioniert.

Wenn Sie eine Funktion hinzugefügt haben - insbesondere eine, von der andere Personen eine Abhängigkeit haben -, um zuversichtlich zu sein, dass es bei "Leben" zu "leben" wird, die an einem anderen Ort an einem anderen Ort als Ihrer Entwicklungsumgebung riesig ist. Darüber hinaus stelle ich von Builds aus meinem Build -Server ein - so wie man den "definitiven" Build angibt. Letztendlich werde ich den Benutzer ausgelöste Bereitstellungsbaufe ausgelöst. Es ist nicht gut zu sagen, dass Sie es umgehen können - Sie können es nicht können, wenn Sie es brauchen (und ich haben Verrückte runde Entwicklerboxen in einem Büro, um fehlende Dateien zu finden und zu verpflichten).

Ist das alles ein bisschen stark? Ich weiß es nicht - aber mein Build -Server ist eines der Dinge, die ich bekommen habe, wenn ich nicht etwas zurückgeben habe.

Answer 3

Ich glaube, tägliche Builds sind sehr wichtig. Wenn Sie ein verteiltes Team in verschiedenen Zeitzonen haben, ist es am besten, Zeit zu finden, das für den größten Teil des Teams ungefähr das Ende des Tages ist. Wenn die täglichen Builds eine automatisierte Testkomponente haben, ist dies wünschenswerter.

In den Tagen zentraler Quellungssteuerungssysteme befürwortete ich kontinuierliche Builds, die alle 5-10 Minuten ausgeführt werden, wenn etwas im Quellcode geändert wird. Da ein Kompilierungsfehler das Potenzial hat, den größten Teil des Teams zu verlangsamen. Für Organisationen, die verteilte Quellensteuerungssysteme ausführen, ist möglicherweise nicht so viel erforderlich, da Entwickler die "makellose" Code-Base direkt seltener berühren.

Answer 4

Im Idealfall würden Sie mehr als einmal am Tag mehr als einmal am Tag bauen, wenn Sie etwas Massives aufbauen, das mehr als einen halben Tag dauert. Sobald Sie einen kontinuierlichen Integrationsserver eingerichtet haben, z. Hudson oder Teamcity, Die Builds werden automatisch, in der Regel jede Stunde oder in jedem Commit geschehen, und Sie werden benachrichtigt, wenn Probleme auftreten.

Dies ist eine gute Möglichkeit, Fehler frühzeitig zu fangen, insbesondere wenn Sie auch automatisierte Tests im Rahmen des Builds durchführen. Es ist besonders nützlich, um Konfigurationsfehler zu finden, bei denen der Build auf der Maschine eines Entwicklers funktioniert, aber anderswo nicht funktioniert, da etwas aus dem Repository oder der Umgebung weggelassen wurde.

Die fortschrittlicheren, kontinuierlichen Integrationsserver ermöglichen es Ihnen auch, Metriken im Laufe der Zeit zu verfolgen (prozentualer Abdeckungsversicherungszeit, Codezeilen usw.)

Answer 5

Tägliche Builds sind in Ordnung. Sie brauchen sie auf jeden Fall, wenn Sie nichts anderes haben, als ehrlich zu sein, ich denke, Joels Test ist heutzutage ein wenig veraltet.

Meiner Meinung nach sollten Sie sich während des Tages kontinuierlich aufbauen, Ihre Einheiten, System- und Funktionstestfälle ausführen und gleichzeitig idealerweise Verpackungen und Bereitstellungen in eine in einer Phase wie Umgebung bereitgestellte Ausführung haben und gleichzeitig überprüft arbeiten wie erwartet.

Wenn Build- oder Bereitstellungszeiten übermäßig sind, sollten Sie einige dieser Probleme mit physischen oder Software -RAM -Festplatten, schnelleren Internetverbindungen, Parallellisierungsbusten usw. wegnehmen .

Answer 6

Tägliche Builds sind nicht wichtig. Tägliche Builds Das ist immer erfolgreich sind (oder solche, in denen es nur eine Stunde gebrochen ist). CI, wenn der Build 70% der Zeit gebrochen ist, ist nicht sehr nützlich, denn wenn das Ding größtenteils gebrochen ist, hilft es Ihnen nicht, einen Fehler zu identifizieren.

Answer 7

Ich denke, es sollte täglich erstellen, testen und auf dem Staging -Server bereitstellen.

Die Idee hinter 'Daily Build' ist es, immer etwas fertig zu haben, das Tester und Projektmanager laufen können, damit jeder eine Vorstellung davon hat, wie der eigentliche Zustand des Projekts ist.

In der Vergangenheit kann mit Desktop -Apps nach dem 'Daily Build' ein Tester oder ein Projektmanager die App sofort ausführen, sodass kein Bereitstellungsschritt erwähnt werden musste.