In einem 1-Mann-Geschäft oder sogar (besonders) größeren Geschäften, wie in der Welt können Sie einen täglichen Build aufrechterhalten?
Wenn Sie die API oder die Datenbanktabelle usw. ändern, müssen Sie möglicherweise so viele Ebenen in der Anwendung ändern, oder sagen Sie das SQL-Initialisierungsscript usw.
Wie können Sie erwarten, dass das Projekt für Änderungen erstellt wird, die mehr als einen Tag dauern?
Ist es ein Entwicklungsziel, sicherzustellen, dass der Build bei jeder einzelnen Änderung funktioniert?
(Übrigens, was ich von einem 'täglichen Build' verstehe, ist ein Knopfdruck und produktionsfertiger Code zum Versenden ... Ich habe das Gefühl, ich habe die falsche Option hehe)
Bei einem täglichen Build sollten Sie keinen Knopf drücken müssen. Dies sollte automatisch geschehen, entweder nach einem bestimmten Zeitplan oder basierend auf anderen Ereignissen wie Code-Check-Ins.
Es ist eine gute Idee, Code in der Hauptverzweigung in einem permanent umsetzbaren Zustand zu haben. Überprüfen Sie den Code in diesem Zweig erst, wenn er funktioniert. Sie können größere Änderungen entweder in Ihrer eigenen Zweigstelle bearbeiten oder indem Sie einige der neuen Logik Ihrer Anwendung mit Flags ausblenden.
Sie können mit Anforderungen wie Datenbankschema usw. umgehen, indem Sie Ihr tägliches Build-Skript alle erforderlichen Einstellungen vornehmen lassen. Denken Sie daran, dass Sie das Produktionsschema nicht ändern müssen, da Sie den Build nicht jeden Tag bereitstellen - er sollte nur zum Testen verwendet werden, damit Sie Regressionen so schnell wie möglich identifizieren können.
In einem 1-Mann-Geschäft oder sogar (besonders) größere Geschäfte, wie in der Welt können Sie einen täglichen Build beibehalten?
Wie können Sie in der Welt erwarten, dass die Dinge ohne einen zusammenbleiben? Das Ziel ist, dass jedes Einchecken in das Repository einen sauberen Build generieren kann. Wenn es nicht möglich ist, machen Sie die Dinge nicht richtig.
Dies ist besonders kritisch, wenn große Änderungen in das Quellcode-Repository eingegeben werden.
Wie können Sie das Projekt erwarten? Build für Änderungen, die mehr als nehmen ein Tag zu vervollständigen?
Einfach, nur auf dem Repository aufbauen. Prüfe nur Sachen in das Repository, das funktioniert.
Ist es ein Entwicklungsziel, die Build arbeitet über jeden einzelnen ändern?
Ja, das ist das Ziel. Wie bei den meisten Bestrebungen wird es wahrscheinlich nicht erfüllt, aber wenn man es als Ziel hat, gibt es ein gutes Feedback darüber, was mit der Code-Basis passiert.
Ja, die Idee der täglichen Builds besteht darin, zu testen, ob Ihr Hauptzweig des Codes stabil ist, Tests besteht und jederzeit versandbereit ist.
Wenn Sie eine Änderung haben, die mehr als eine einzige Festschreibung in Ihrem Revisionskontrollsystem erfordert, sollten Sie einen Entwicklungszweig erstellen, damit Sie frei committen können, ohne den Hauptzweig zu destabilisieren.
Beachten Sie, dass Ihre Datenbank für jede Verzweigung ein separates Testschema benötigt. Ich empfehle ohnehin für jede Testumgebung eine eigene Datenbankinstanz, das sollte also kein Problem sein.
Sobald Sie diese Refactoring- und aktualisierten Tests abgeschlossen haben, sollten Sie in der Lage sein, manuell zu überprüfen, dass der Code die Tests besteht und Ihr täglicher Build nicht unterbrochen wird.
Dann können Sie die Änderungen von Ihrem Entwicklungszweig zum Hauptzweig zusammenführen.
Ich habe CruiseControl verwendet, um Continues Integration zu implementieren, das sogar neue Builds erstellt und sie auf jedem SVN-Checkin bereitstellt, so dass die Antwort auf diese Frage ein definitives JA ist ...;)
Ich habe diese Beschwerde oft gehört und sogar bei meiner Firma. Es ist nur eine Art zu arbeiten. Wenn Sie nicht in der Lage sind, Ihre Daten jederzeit kompilierbar und testbar zu haben, arbeiten Sie wahrscheinlich auf eine unberechenbare Weise an Ihren Problemen und berühren zu viel Code auf einmal. Du bist ein Jongleur. Jongleure programmieren nicht.
Bei all meinen Projekten machen wir HOURLY Builds. Wir verwenden Luntbuild, um dies zu tun, und es wird alle Projektmitglieder mailen, sobald der Build fehlschlägt, und wird weiterversenden, bis der Build funktioniert. Gebrochener Code wird nicht eingecheckt, und wenn jemand den Build bricht, muss er Cookies für das ganze Team bekommen (oder andere passende "Demütigungen" :-)).
Jede Woche versuchen wir, die Software auf unseren Testservern zu installieren, damit unsere Testabteilung die Software testen kann.
Sie werden feststellen, dass dies zu fast jedem Zeitpunkt während des Projekts zu einem besseren Code und einem lieferbaren Projekt führt, weil:
Mir ist klar, dass dies keine wirkliche Antwort auf die Frage "Wie hältst du die Builds?" gibt. Ich denke, dafür gibt es keine wirkliche Silberkugel-Antwort. Du musst es einfach machen und sehen, ob es für dich funktioniert. Ich denke, der größere Teil der professionellen Programmierer ist sich einig, dass kontinuierliche Integration, automatisierte Tests und tägliche Builds eine gute Sache sind.
Mein aktuelles Projekt hat zwei Probleme, eines davon ist, dass der Buildserver aufgrund eines Netzwerkproblems nicht mailt, und das andere ist, dass es zu viel Panik gibt. Dies bedeutet, dass fehlgeschlagene stündliche Builds viel später bemerkt werden und wöchentliche Installationen aufgrund nicht bearbeiteter Funktionalität nicht möglich sind. Sie können sofort Reflexionen dieses Problems an das Projekt und die Motivation der Teammitglieder sehen. Es läuft einfach nicht "reibungslos".
Ich hoffe, das hilft. Halte sie grün! (die Unittests, das ist)
edit: Das "Drücken der Taste", auf das Sie sich beziehen, ist der "single step build". Das bedeutet, dass Sie ein Skript haben, das Ihren Build erstellt (oder ant oder maven oder was auch immer), und Sie verwenden dieses Skript, um die Tests durchzuführen. Wenn Ihr automatisierter Buildprozess funktioniert, wissen Sie, dass Sie ein lieferbares Produkt haben. Sie führen einfach das Skript aus und senden die Ausgabe an den Kunden. Unser Build-Skript erzeugt eine Verzeichnisstruktur, die 1-auf-1 auf die CD kopiert wird, mit der wir die Software liefern.
Kurz gesagt ...
Automatisieren.
Überprüfe es nicht bis es fertig ist.
Ja.
Der einfachste Weg tägliche Builds zu haben ist, in Streams zu arbeiten.
Habe einen Entwicklungs-Stream, einen QA (oder Test) -Stream und schließlich einen Release-Stream.
Erstelle deine QA und gib Streams frei, wenn sie sich ändern. Erstellen Sie Ihren Entwicklungsstream nur dann, wenn Sie es benötigen.
Jetzt können Sie größere Änderungen an Ihrem Entwicklungsdatenstrom vornehmen und diese dann (in der Quellcodeverwaltung) in einigen einfacheren Schritten zusammenführen und der automatische Erstellungsprozess wird gestartet.
Wenn es auf Ihrem Computer erstellt wird, sollte es auf dem Server erstellt werden. Die Sache ist, dass Sie nur einchecken, wenn Sie mit Ihrer Aufgabe fertig sind, oder Zweige verwenden, damit Sie den Build nicht unterbrechen.
Die Leute tun das nicht unbedingt, um das Produkt an irgendeinem Tag in eine Schachtel zu legen, sicher, es kann Routinen geben, die vor der Veröffentlichung gemacht werden müssen, aber die Idee ist, dass jeder Entwickler den neuesten Code bekommen kann im Server und es wird in ihren Maschinen eingebaut. Es wird auch für automatisierte Komponententests verwendet. Wenn der Code nicht kompiliert, können Sie sie nicht ausführen.
So ziemlich jede große Software-Firma verwendet tägliche Builds (eigentlich mehrere Builds pro Tag), also ja, es ist machbar und eine gängige Praxis.
Bei meinem aktuellen Gig machen wir unsere Java EE App täglich mit CruiseControl, einem Ivy Repo, Ant & amp; Klarer Fall. Wir sind ein großes Team und können uns ein Build-Team (von 3) leisten und Server bauen.
Ja, die Probleme, die Sie nennen, wie falsche DB-Änderungen, falsche Zusammenführungen, fehlerhafte Kompilierungen & amp; Tests. Aber insgesamt hätten wir keinen anderen Weg.
Tags und Links continuous-integration build-process