Wie und warum richte ich ein C# - build-Maschine?[geschlossen]

https://stackoverflow.com/questions/616149

03-07-2019
|

Frage

Ich arbeite mit einem kleinen (4 person) - Entwicklung team-auf ein C# - Projekt.Ich habe vorgeschlagen, die Einrichtung einer build-Maschine, die nightly builds und tests von dem Projekt, weil ich verstehe, dass dies eine Gute Sache ist.Das Problem ist, wir haben nicht eine ganze Menge von budget hier, so habe ich, um die Kosten zu rechtfertigen, um die Kräfte, die sein.Deshalb möchte ich wissen:

Welche Extras/Lizenzen brauche ich?Jetzt verwenden wir Visual Studio und Smart Versammlung bauen, und Notgedrungen für die Quellcodeverwaltung.Brauche ich etwas anderes, oder gibt es ein äquivalent von einem cron-job für die Ausführung von automatisierten Skripts?

Was genau, wird diese bekommen, mich, andere als ein Indiz für eine defekte bauen?Sollte ich test-Projekte in dieser Lösung (sln-Datei) ausgeführt werden, die von diesen Skripts, also ich kann mit besonderen Funktionen getestet?Wir haben im moment zwei solche tests, weil wir noch nicht die Zeit hatten (oder, ehrlich gesagt, die Erfahrung) gute unit-tests.

Welche hardware brauche ich dafür?

Sobald ein build abgeschlossen und getestet ist, ist es eine gängige Praxis zu setzen, die sich auf eine ftp-site oder auf eine andere Weise für den internen Zugriff?Die Idee ist, dass diese Maschine macht die build, und wir gehen alle, aber können machen debug-builds, wenn wir müssen.

Wie oft sollte man diese Art von bauen?

Wie ist der Raum geschafft?Wenn wir nightly builds, sollten wir uns halten, um alle alten baut, oder Graben Sie nach etwa einer Woche oder so?

Gibt es etwas, was ich nicht sehe hier?

Ich weiß, es ist ein sehr großes Thema, und ich bin erst am Anfang.Ich konnte Sie nicht finden, ein Duplikat von diese Frage hier, und wenn es ein Buch gibt, ich sollte nur kommen, lassen Sie es mich bitte wissen.

EDIT:Ich habe es endlich an die Arbeit!Hudson ist ganz fantastisch, und FxCop, die zeigen, dass einige Funktionen, die wir dachten, waren umgesetzt wurden tatsächlich unvollständig.Wir hatten auch ändern Sie den installer-Typ aus Alten Und Kaputten vdproj zu Neuer Schärfe WiX.

Im Grunde, für diejenigen, die aufmerksam sind, wenn Sie Ihr über die Befehlszeile erstellen, dann können Sie legen Sie es in hudson.Den build von der Befehlszeile aus ausgeführt über MSBuild ist eine nützliche übung in sich selbst, da es Kräfte, die Ihre Werkzeuge zu aktuellen.

Lösung

Update: Jenkins ist die aktuellste Version von Hudson. Jeder sollte jetzt mit Jenkins sein. Ich werde daher die Links werden zu aktualisieren.

Hudson ist kostenlos und extrem einfach auf einer VM zu konfigurieren und leicht ausgeführt werden.

Teilweise aus einem alten Post von mir:

Wir verwenden es auf

Bereitstellen von Windows Dienste
Deploy Web Services
Ausführen MSTests & Display, so viele Informationen wie alle JUnit-Tests
Spur von niedrig, med, hohe Aufgaben
Trenddiagramm Warnungen und Fehler

Hier sind einige der in .net Sachen gebaut, die Hudson unterstützt

Auch Gott bewahre Sie Visual Sourcesafe verwenden, unterstützt dass auch . Ich würde empfehlen, einen Blick auf Redsolo des Artikel über .net Projekte an Hudson mit

Ihre Fragen

F : Welche Tools / Lizenzen benötige ich? Im Moment verwenden wir Visual Studio und Smart Assembly zu bauen, und Perforce für die Quellcodeverwaltung. Muss ich etwas anderes, oder gibt es ein Äquivalent eines Cron-Job für die automatisierte Skripte ausgeführt werden?
A: Ich habe gerade installiert Visual Studio auf eine neue Kopie einer VM ein frisches läuft, geflickt, installieren Sie von einem Windows-Server-Betriebssystem. So sollten Sie die Lizenzen müssen, damit umzugehen. Hudson wird sich als Windows-Dienst installieren und auf Port 8080 laufen und Sie werden festlegen, wie oft Sie wollen, dass es für aktualisierte Code Code-Repository scannen, oder Sie können es zu einem bestimmten Zeitpunkt zu bauen erzählen. Alle konfigurierbar über den Browser.
F: Was genau wird dies hol mich, andere als ein Anzeichen eines gebrochenen bauen? Soll ich einrichten Testprojekte in dieser Lösung (SLN-Datei), die durch diese Skripte ausgeführt werden, so kann ich bestimmte Funktionen getestet haben? Wir haben im Moment zwei solche Tests, weil wir nicht die Zeit haben (oder ehrlich gesagt, die Erfahrung) gute Unit-Tests zu machen.

A: Sie erhalten eine E-Mail auf das erste Mal erhalten ein Build fehlschlägt, oder wird instabil. Ein Build ist instabil, wenn eine Einheit Test fehlschlägt oder sie kann durch eine beliebige Anzahl von Kriterien instabil markiert werden, die Sie festlegen. Wenn ein Gerät zu testen oder Build fehlschlägt, werden Sie per E-Mail und es wird Ihnen sagen, wo, warum und wie es ist fehlgeschlagen. Mit meiner Konfiguration, erhalten wir:
- Liste aller verpflichtet seit dem letzten Arbeits build
- begehen Notizen dieser Commits
- Liste der Dateien in den Commits geändert
- Konsolenausgabe aus dem Build selbst, den Fehler oder Testfehler zeigt
F: Welche Art von Hardware werde ich dafür brauche

A: Eine VM genügt
F: Sobald ein Build abgeschlossen und getestet wurde, ist es üblich, dass aufbauen auf einer FTP-Site zu setzen oder eine andere Art und Weise für den internen Zugriff haben? Die Idee ist, dass diese Maschine die Build macht, und wir alle es gehen, aber kann debuggen baut, wenn wir müssen.

A: Hudson kann tun, was man will, dass sie über den MD5-Hash enthält ID'ing, dem Hochladen, Kopieren es, über seine Archivierung, etc. Es tut dies automatisch und liefert Ihnen mit einer langen Laufgeschichte Build Artefakte.
F: Wie oft sollten wir diese Art von Build machen

A: Wir haben jede Stunde unsere Umfrage SVN, für die Code-Änderungen suchen, dann einen Build ausgeführt wird. Nightly ist ok, aber etwas wertlos IMO da das, was Sie gestern gearbeitet habe gewohnt in Ihrem Kopf am Morgen frisch sein, wenn Sie einsteigen.
F: Wie wird Raum verwaltet? Wenn wir jede Nacht machen baut, sollten wir halten um alle alten baut, oder starten sie nach etwa einer Woche zu Graben oder so?

A: Das ist bis zu Ihnen, nach so langer Zeit ich unseren Build-Artefakte zu Langzeitlagerung zu verschieben oder löschen, aber alle Daten, die in Textdateien / XML-Dateien gespeichert ist, halte ich herum, dies lässt mich lagern Sie das Changelog, Trenddiagramme, etc. auf dem Server mit seeehr wenig Platz verbraucht. Sie können auch Hudson einrichten nur Artefakte aus einem nachgestellten # halten den Builds
F: Gibt es etwas, was ich nicht bin zu sehen hier

A: Nein, Go Hudson bekommt gerade jetzt, Sie werden nicht enttäuscht sein

Andere Tipps

Wir haben großes Glück mit der folgenden Combo haben:

Visual Studio (genauer gesagt, das Kommandozeilen-Tool MSBuild.exe mit und unsere Lösungsdateien übergeben. Beseitigt die Notwendigkeit für msbuild Skripte)
NAnt (wie die XML-Syntax / Task-Bibliothek besser als MSBuild. Hat auch Optionen für P4 src Steueroperationen )
CruiseControl.net - in Web-Dashboard gebaut für die Überwachung / Ausgangs baut.

CCNet hat in Anmeldern gebaut E-Mails zu senden, wenn erfolgreich / nicht bestanden baut

Auf Begründung: Dies entlastet die Entwickler baut manuell tun und tut viel menschliches Versagen nehmen aus der Gleichung heraus. Es ist sehr schwer, diesen Effekt zu quantifizieren, aber wenn Sie es tun, werden Sie nie mehr zurück. ein wiederholbares Verfahren mit zu bauen und Release-Software ist von größter Bedeutung. Ich bin sicher, Sie haben Orte, an denen sie die Software von Hand bauen und es wird in der Wildnis aus, nur Build Kerl haben, sagen: „Hoppla, ich habe vergessen, muss das neue DLL schließen!“

Auf Hardware: so mächtig wie Sie bekommen können. Mehr Leistung / Speicher = schnellere Zeiten bauen. Wenn Sie es sich leisten können, Sie werden es nie bereuen eine erstklassige Maschine zu bauen bekommen, egal wie klein die Gruppe.

Ein Raum: Hilft viel Festplattenspeicher haben. Sie können Ihre NAnt Skripte löschen Zwischendateien jedes Mal ein Build beginnt, so dass die eigentliche Frage hält Protokoll Geschichten und alte Anwendung Installateure Handwerk. Wir haben Software, die Speicherplatz überwacht und sendet Warnungen. Dann reinigen wir das Laufwerk manuell auf. Normalerweise muss alle 3-4 Monate durchgeführt werden.

Auf Build-Benachrichtigungen: Dies ist in der zu CCNet gebaut, aber wenn Sie vorhaben, automatisierte Tests als zusätzlichen Schritt hinzufügen dann baut diese in das Projekt von dem get-go. Es ist extrem schwer, fit Tests zu unterstützen, sobald ein Projekt groß wird. Es gibt jede Menge Informationen über Test-Frameworks gibt (wahrscheinlich eine Tonne von Informationen über SO als auch), so dass ich zur Namensgebung keine spezifischen Werkzeuge verschieben werden.

Bei meinem früheren Arbeitsplatz haben wir Teamcity . Es ist sehr einfach und leistungsfähig. Es kann mit einigen Einschränkungen kostenlos genutzt werden. Es gibt auch ein Tutorial auf Dime Casts . Der Grund, warum wir nicht CruiseControl.NET verwenden ist, dass wir viele kleine Projekte hatten und es ist ziemlich schmerzhaft jedes in CC.NET bis zu setzen. Ich würde empfehlen, Teamcity. Zusammengefasst, wenn Sie in Richtung Open Source sind, dann ist CC.NET der Grand Daddy mit etwas höheren Lernkurve. Wenn Ihr Budget können Sie auf jeden Fall mit Teamcity gehen oder die kostenlose Version überprüfen.

Wie? Werfen Sie einen Blick auf Carel Lotz Blog rel="nofollow .

Warum? Es gibt mehrere Gründe, die ich mir vorstellen kann:

Eine Arbeits bauen, wenn sie richtig umgesetzt werden, bedeutet, dass alle Entwickler können auf ihre Maschine bauen, wenn der Build-grün ist
Eine Arbeits bauen, wenn sie richtig umgesetzt werden, bedeutet, dass Sie bereit sind, jederzeit bereitstellen
Eine Arbeits bauen, wenn sie richtig umgesetzt werden, bedeutet, dass alles, was Sie veröffentlichen eine Reise zu Ihrem Source-Control-System gemacht hat.
Eine Arbeits bauen, wenn sie richtig umgesetzt werden, bedeutet, dass Sie integrieren früh und häufig, Ihr Integrationsrisiko zu reduzieren.

Martin Fowler Artikel über Continuous Integration bleibt der endgültige Text. Werfen Sie einen Blick auf sie!

Das Hauptargument für ist, dass sie die Kosten für den Entwicklungsprozess geschnitten, indem Sie so schnell wie möglich alarmiert, dass Sie ein defektes Build oder Prüfungen nicht haben.

Das Problem der Arbeit von mehreren Entwicklern der Integration ist die Hauptgefahr, ein Team zu wachsen. Je größer das Team wird, desto schwieriger ist es, ihre Arbeit zu koordinieren und verhindern, dass sie mit dem jeweils anderen Änderungen durcheinander. Die einzige gute Lösung ist, ihnen zu sagen, zu „früh und oft zu integrieren“, indem sie in kleinen Arbeitseinheiten (manchmal auch als „Geschichten“) überprüft, wie sie abgeschlossen sind.

Sie sollten die Build-Maschine machen jedes Mal einige Prüfungen in, im Laufe des Tages wieder aufzubauen. Mit Cruise Control können Sie ein Symbol auf der Taskleiste erhalten, die rot wird (und sogar mit Ihnen spricht!), Wenn der Build gebrochen ist.

Sie sollten dann eine nächtliche voll bereinigter Build tun, wo die Source-Version (da eine eindeutige Build-Nummer) gekennzeichnet ist, die Sie wählen können, um Ihre Stakeholder (Produktmanager, QA Personen) zu veröffentlichen. Dies ist so, dass, wenn ein Fehler gemeldet wird, ist es gegen eine bekannte Build-Nummer (das ist extrem wichtig).

Im Idealfall sollten Sie eine interne Website, wo heruntergeladen werden Builds können, und haben einen Knopf Sie die vorherige Nightly Build veröffentlichen klicken.

Ich versuche nur, ein bisschen auf zu bauen, was mjmarsh sagte, da er ein großes Fundament gelegt ...

Visual Studio. MSBuild funktioniert.
NAnt .
NAntContrib . Dies wird zusätzliche Aufgaben zur Verfügung stellen, wie Perforce-Operationen.
CruiseControl.net . Dies ist wiederum im Grunde Ihre „bauen Armaturenbrett“.

Alle oben genannten (für VS speichern) ist Open Source, so dass Sie suchen nicht jeder zusätzliche Lizenzierung.

Wie Earwicker erwähnt, bauen früh, bauen oft. etwas zu wissen, brach, und Sie können ein lieferbares ist nützlich für den Fang von Sachen früh produzieren.

NAnt umfasst Aufgaben für nunit / nunit2 als auch, so dass Sie tatsächlich Ihre Unit-Tests automatisieren. Sie können dann gelten Sheets auf die Ergebnisse, und mit Hilfe der von CruiseControl.net vorgegebenen Rahmen, haben schön lesbar, bedruckbar Einheit Testergebnis für jeden zu bauen.

Das gleiche gilt für die ndoc Aufgabe. Haben Sie in der Dokumentation produziert und zur Verfügung, für jeden zu bauen.

Sie können sogar die exec Aufgabe andere Befehle auszuführen, zum Beispiel, ein Windows Installer mit Install erzeugen.

Die Idee ist, den Build so weit wie möglich zu automatisieren, weil Menschen Fehler machen. Die Zeit, nach vorne Zeit ist die Straße gerettet unten. Die Menschen, die nicht, indem Sie durch den Build-Prozess den Build babysitten. Identifizieren Sie alle Schritte des Builds erstellen NAnt Skripte für jede Aufgabe, und bauen Sie Ihre NAnt Skripte nacheinander, bis Sie ganz Ihren gesamten Build-Prozess automatisiert haben. Es ist auch dann setzt alle Ihre an einem Ort errichtet, die zu Vergleichszwecken gut ist. Etwas Pause in Build 426, die in Build 380 fein gearbeitet? Nun, es sind die zu erbringenden Leistungen zum Testen bereit - greifen sie und testen weg

Keine Lizenzen erforderlich.CruiseControl.net ist frei verfügbar und muss nur die .NET sdk zu bauen.
Ein build-server, auch ohne automatisierte unit-tests noch bietet eine kontrollierte Umgebung für die Erstellung von releases.Nicht mehr "Johannes in der Regel stützt sich auf seine Maschine, aber er ist krank.Aus irgendeinem Grund kann ich nicht bauen auf meine Maschine"
Jetzt habe ich ein set-up, in einer Virtuellen PC-Umgebung.
Ja.Das bauen muss weggeworfen werden irgendwo zugänglich.Entwicklungsversionen haben sollte-debugging eingeschaltet.Release bauen, sollte es ausgeschaltet haben.
Wie oft ist Ihnen überlassen.Wenn richtig eingerichtet, kann man nach jedem check-in wird sehr wenig Aufwand.Dies ist eine großartige Idee, wenn Sie einen haben (oder planen, mit) unit-tests in Ort.
Halten Sie Meilensteine und releases wie lange, wie Sie benötigt.Alles andere hängt davon ab, wie oft Sie bauen:kontinuierlich?wegwerfen.Täglich?Halten Sie eine Woche.Wöchentlich?Halten Sie zwei Monat Wert ist.

Je größer das Projekt wird, desto mehr sehen Sie die Vorteile eines automatisierten build-Maschine.

Es geht um die Gesundheit des Build. Was dies bringt Sie ist, dass Sie jede Art von Dingen einrichten können Sie passieren sollen, mit dem Builds. Unter diesen können Sie Tests, statische Analyse und Profiler laufen. Probleme werden mit viel viel schneller behandelt werden, wenn Sie in letzter Zeit auf diesem Teil der Anwendung gearbeitet. Wenn Sie kleine Änderungen zu übernehmen, dann fast es sagt Ihnen, wo Sie brach es:)

Dies setzt natürlich voraus, Sie es einrichten mit jedem Check-in (Continuous Integration) zu bauen.

Es kann auch näher kommen QA und Dev helfen. Wie Sie damit Funktionstests eingerichtet laufen kann, zusammen mit Profiler und alles andere, das Feedback an das Entwicklerteam verbessert. Dies bedeutet nicht, die Funktionstests bei jeder Prüfung ausgeführt in (kann eine Weile dauern), aber richten Sie baut / Tests mit Werkzeugen, die an das ganze Team gemeinsam sind. Ich habe Rauch-Tests wurde die Automatisierung, so in meinem Fall arbeiten wir noch enger.

Warum: Vor 10 Jahren, als wir Software-Entwickler verwendet, um etwas zu dem n-ten Grad zu analysieren, um die Dokumente erhalten (in einer menschlichen Sprache geschrieben) ‚abgezeichnet‘, dann starten Code zu schreiben. Wir würden Unit-Test, Testlauf und dann würden wir einen Systemtest getroffen: das erste Mal, das System als Ganzes zusammen laufen würde, manchmal Wochen oder Monate, nachdem wir die Dokumente unterzeichnet habe. Erst dann, dass wir die Annahmen und Missverständnisse alles aufdecken würden wir hatten, als wir alles analysiert.

Continuous Integration als und die Idee, dass du ein komplettes (obwohl zunächst sehr einfach) System Ende bauen zu beenden. Im Laufe der Zeit ist die Systemfunktionalität orthogonal aufgebaut werden. Jedes Mal, wenn Sie eine komplette Build tun tun Sie das System Test früh und häufig. Dies bedeutet, dass Sie Fehler und Annahmen so früh wie möglich zu finden und beheben, wenn es die günstigste Zeit ist, sie zu beheben.

Wie: Wie für die, wie ich darüber ein Weilchen gebloggt vor: [ klicken Sie hier ]

über 8 Beiträge es Schritt für Schritt geht auf wie einen Jenkins-Server in einer Windows-Umgebung für .NET-Lösungen einzurichten.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow