Wie und warum richte ich eine C # -Erstellungsmaschine ein? [geschlossen]

Ich arbeite mit einem kleinen Entwicklungsteam (4 Personen) an einem C # -Projekt. Ich habe vorgeschlagen, eine Build-Maschine einzurichten, die nächtliche Builds und Tests des Projekts durchführt, da ich verstehe, dass dies eine gute Sache ist. Das Problem ist, dass wir hier nicht viel Budget haben, also muss ich die Kosten gegenüber den Mächten rechtfertigen. Also möchte ich wissen:

Update: Jenkins ist die aktuellste Version von Hudson. Jeder sollte jetzt Jenkins verwenden. Ich werde die Links entsprechend aktualisieren.

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

Teilweise von einem alten Posten von mir:

Wir benutzen es um

• Stellen Sie Windows-Dienste bereit
• Stellen Sie Webdienste bereit
• Führen Sie MSTests aus und zeigen Sie so viele Informationen an wie alle Junit-Tests
• Behalten Sie niedrige, mittlere und hohe Aufgaben im Auge
• Trendgraph Warnungen und Fehler

Hier sind einige der integrierten .net-Inhalte, die Hudson unterstützt

• MSBuild
• NAnt
• MSTest
• Nunit
• Team Foundation Server
• fxcop
• Stylecop
• Compiler-Warnungen
• Code-Aufgaben

Gott bewahre auch, dass Sie Visual Source Safe verwenden. Dies wird auch unterstützt . Ich würde empfehlen, dass Sie sich Redsolos Artikel über das Erstellen von .net-Projekten mit Hudson ansehen

Deine Fragen

• F : Welche Tools / Lizenzen benötige ich? Derzeit verwenden wir Visual Studio und Smart Assembly zum Erstellen und Perforce zur Quellcodeverwaltung. Benötige ich noch etwas oder gibt es ein Cron-Job zum Ausführen automatisierter Skripte?

• A: Ich habe Visual Studio gerade auf einer neuen Kopie einer VM installiert, auf der eine neue, gepatchte Installation eines Windows Server-Betriebssystems ausgeführt wird. Dazu benötigen Sie die Lizenzen. Hudson installiert sich selbst als Windows-Dienst und wird auf Port 8080 ausgeführt. Sie konfigurieren, wie oft das Code-Repository nach aktualisiertem Code durchsucht werden soll, oder Sie können festlegen, dass es zu einem bestimmten Zeitpunkt erstellt werden soll. Alles über den Browser konfigurierbar.

• F: Was genau bringt mir das außer einem Hinweis auf einen kaputten Build? Sollte ich in dieser Lösung (SLN-Datei) Testprojekte einrichten, die von diesen Skripten ausgeführt werden, damit ich bestimmte Funktionen testen kann? Wir haben im Moment zwei solcher Tests, weil wir nicht die Zeit (oder ehrlich gesagt die Erfahrung) hatten, gute Unit-Tests durchzuführen.

  A: Sie erhalten eine E-Mail, wenn ein Build zum ersten Mal fehlschlägt oder instabil wird. Ein Build ist instabil, wenn ein Komponententest fehlschlägt oder durch eine von Ihnen festgelegte Anzahl von Kriterien als instabil markiert werden kann. Wenn ein Komponententest oder Build fehlschlägt, werden Sie per E-Mail darüber informiert, wo, warum und wie er fehlgeschlagen ist. Mit meiner Konfiguration erhalten wir:

  • Liste aller Commits seit dem letzten funktionierenden Build
  • Notizen zu diesen Commits festschreiben
  • Liste der in den Commits geänderten Dateien
  • Konsolenausgabe vom Build selbst, die den Fehler oder Testfehler anzeigt

• F: Welche Hardware benötige ich dafür?

  A: Eine VM wird ausreichen

• F: Ist es üblich, einen Build nach Abschluss und Test auf einer FTP-Site zu platzieren oder auf andere Weise für den internen Zugriff zu verwenden? Die Idee ist, dass diese Maschine den Build erstellt, und wir alle gehen dorthin, können aber Debug-Builds erstellen, wenn wir müssen.

  A: Hudson kann damit machen, was Sie wollen, einschließlich ID'ing über den md5-Hash, Hochladen, Kopieren, Archivieren usw. Dies geschieht automatisch und bietet Ihnen eine lange Geschichte von Build-Artefakten.

• F: Wie oft sollten wir diese Art von Build machen?

  A: Wir lassen unsere SVN stündlich abfragen, suchen nach Codeänderungen und führen dann einen Build aus. Nächtlich ist in Ordnung, aber etwas wertlos IMO, da das, woran Sie gestern gearbeitet haben, morgens beim Einsteigen nicht frisch in Ihrem Kopf sein wird.

• F: Wie wird der Speicherplatz verwaltet? Wenn wir nächtliche Builds erstellen, sollten wir dann alle alten Builds behalten oder nach etwa einer Woche damit beginnen, sie fallen zu lassen?

  A: Das liegt an Ihnen, nachdem ich unsere Build-Artefakte so lange in einen Langzeitspeicher verschoben oder gelöscht habe, aber alle Daten, die in Textdateien / XML-Dateien gespeichert sind, die ich aufbewahre, kann ich das Änderungsprotokoll, Trenddiagramme usw. speichern. usw. auf dem Server mit sehr wenig belegtem Speicherplatz. Sie können Hudson auch so einrichten, dass nur Artefakte von einer nachfolgenden Anzahl von Builds ferngehalten werden

• F: Gibt es noch etwas, das ich hier nicht sehe?

  A: Nein, hol Hudson jetzt, du wirst nicht enttäuscht sein!

Wir hatten großes Glück mit der folgenden Kombination:

1. Visual Studio (insbesondere die Verwendung des Befehlszeilentools MSBuild.exe und die Übergabe unserer Lösungsdateien macht msbuild-Skripte überflüssig)
2. NAnt (wie die XML-Syntax- / Aufgabenbibliothek besser als MSBuild. Hat auch Optionen für P4-Quellcodeverwaltungsoperationen)
3. CruiseControl.net - Integriertes Web-Dashboard zum Überwachen / Starten von Builds.

CCNet verfügt über integrierte Benachrichtigungen zum Senden von E-Mails, wenn Builds erfolgreich sind / fehlschlagen

Zur Rechtfertigung: Dies entlastet Entwickler bei manuellen Builds und trägt viel dazu bei, menschliches Versagen aus der Gleichung herauszunehmen. Es ist sehr schwer, diesen Effekt zu quantifizieren, aber wenn Sie ihn einmal gemacht haben, werden Sie nie mehr zurückkehren. Ein wiederholbarer Prozess zum Erstellen und Freigeben von Software ist von größter Bedeutung. Ich bin mir sicher, dass Sie Orte waren, an denen die Software von Hand erstellt wurde und sie in freier Wildbahn veröffentlicht wurde, nur um Ihren Build-Mitarbeiter sagen zu lassen: "Ups, ich muss vergessen haben, diese neue DLL aufzunehmen!"

Auf Hardware: so leistungsfähig wie möglich. Mehr Leistung / Speicher = schnellere Bauzeiten. Wenn Sie es sich leisten können, werden Sie es nie bereuen, eine erstklassige Baumaschine bekommen zu haben, egal wie klein die Gruppe ist.

On Space: Hilft, genügend Festplattenspeicher zu haben. Sie können Ihre NAnt-Skripte so gestalten, dass bei jedem Start eines Builds Zwischendateien gelöscht werden. Das eigentliche Problem besteht also darin, Protokollverläufe und alte Anwendungsinstallationsprogramme zu führen. Wir haben eine Software, die den Speicherplatz überwacht und Warnungen sendet. Dann bereinigen wir das Laufwerk manuell. Muss normalerweise alle 3-4 Monate durchgeführt werden.

Bei Build-Benachrichtigungen: Dies ist in CCNet integriert. Wenn Sie jedoch als zusätzlichen Schritt automatisierte Tests hinzufügen möchten, bauen Sie diese von Anfang an in das Projekt ein. Es ist äußerst schwierig, Fit-Tests zu unterstützen, sobald ein Projekt groß wird. Es gibt unzählige Informationen zu Test-Frameworks (wahrscheinlich auch eine Menge Informationen zu SO), daher werde ich die Benennung bestimmter Tools verschieben.

An meinem vorherigen Arbeitsplatz haben wir TeamCity verwendet . Es ist sehr einfach und leistungsstark zu bedienen. Es kann mit einigen Einschränkungen kostenlos verwendet werden. Es gibt auch ein Tutorial zu Dime Casts . Der Grund, warum wir CruiseControl.NET nicht verwendet haben, ist, dass wir viele kleine Projekte hatten und es ziemlich schmerzhaft ist, jedes in CC.NET einzurichten. Ich kann TeamCity nur empfehlen. Zusammenfassend lässt sich sagen, dass CC.NET der Großvater mit einer etwas höheren Lernkurve ist, wenn Sie sich für Open Source interessieren. Wenn Ihr Budget es zulässt, entscheiden Sie sich auf jeden Fall für TeamCity oder sehen Sie sich die kostenlose Version an.

Wie? Schauen Sie sich den Blog von Carel Lotz an .

Warum? Es gibt mehrere Gründe, an die ich denken kann:

• Ein funktionierender Build bedeutet bei ordnungsgemäßer Implementierung, dass alle Ihre Entwickler auf ihrem Computer bauen können , wenn der Build grün ist
• Ein funktionierender Build bedeutet bei ordnungsgemäßer Implementierung, dass Sie jederzeit bereit sind, ihn bereitzustellen
• Ein funktionierender Build bedeutet bei ordnungsgemäßer Implementierung, dass alles, was Sie veröffentlichen, zu Ihrem Versionsverwaltungssystem gelangt ist.
• Ein funktionierender Build bedeutet bei ordnungsgemäßer Implementierung, dass Sie früh und häufig integrieren, wodurch sich das Integrationsrisiko verringert.

Martin Fowlers Artikel über kontinuierliche Integration bleibt der endgültige Text. Schau es dir an!

Das Hauptargument dafür ist, dass dadurch die Kosten Ihres Entwicklungsprozesses gesenkt werden, indem Sie so schnell wie möglich benachrichtigt werden, dass Sie einen fehlerhaften Build haben oder Tests nicht bestehen.

Das Problem der Integration der Arbeit mehrerer Entwickler ist die Hauptgefahr beim Wachstum eines Teams. Je größer das Team wird, desto schwieriger ist es, die Arbeit zu koordinieren und zu verhindern, dass sie sich gegenseitig verändern. Die einzig gute Lösung besteht darin, ihnen zu sagen, sie sollen sich "früh und häufig integrieren", indem sie kleine Arbeitseinheiten (manchmal als "Geschichten" bezeichnet) einchecken, sobald sie fertig sind.

Sie sollten die Build-Maschine JEDES Mal neu einbauen lassen, wenn Sie den ganzen Tag über einchecken. Mit Cruise Control erhalten Sie ein Symbol in Ihrer Taskleiste, das rot wird (und sogar mit Ihnen spricht!), Wenn der Build beschädigt ist.

Anschließend sollten Sie eine nächtliche vollständige Bereinigung durchführen, bei der die Quellversion mit einer eindeutigen Build-Nummer gekennzeichnet ist, die Sie für Ihre Stakeholder (Produktmanager, QS-Mitarbeiter) veröffentlichen können. Dies ist so, dass ein gemeldeter Fehler gegen eine bekannte Build-Nummer verstößt (das ist äußerst wichtig).

Idealerweise sollten Sie eine interne Site haben, auf der Builds heruntergeladen werden können, und eine Schaltfläche, auf die Sie klicken können, um den vorherigen nächtlichen Build zu veröffentlichen.

Ich versuche nur ein bisschen auf dem aufzubauen, was mjmarsh gesagt hat, da er ein großartiges Fundament gelegt hat ...

• Visual Studio. MSBuild funktioniert gut.
• NAnt .
• NantContrib . Dadurch werden zusätzliche Aufgaben wie Perforce-Vorgänge bereitgestellt.
• CruiseControl.net . Dies ist wieder im Grunde Ihr "Build Dashboard".

Alles oben Genannte (außer für VS) ist Open Source, sodass Sie keine zusätzliche Lizenzierung in Betracht ziehen.

Wie Earwicker erwähnte, früh bauen, oft bauen. Zu wissen, dass etwas kaputt ist und Sie ein Ergebnis erstellen können, ist nützlich, um frühzeitig Dinge zu fangen.

NAnt enthält auch Aufgaben für nunit / nunit2 , sodass Sie Ihre Unit-Tests tatsächlich automatisieren können. Sie können dann Stylesheets auf die Ergebnisse anwenden und mithilfe des von CruiseControl.net bereitgestellten Frameworks für jeden Build gut lesbare, druckbare Unit-Testergebnisse erhalten.

Gleiches gilt für die ndoc- Aufgabe. Lassen Sie Ihre Dokumentation für jeden Build erstellen und verfügbar machen.

Sie können die Exec- Task sogar verwenden , um andere Befehle auszuführen, z. B. das Erstellen eines Windows-Installationsprogramms mit InstallShield.

Die Idee ist, den Build so weit wie möglich zu automatisieren, weil Menschen Fehler machen. Die Zeit, die im Voraus verbracht wird, spart Zeit. Die Leute müssen den Build nicht babysitten, indem sie den Build-Prozess durchlaufen. Identifizieren Sie alle Schritte Ihres Builds, erstellen Sie NAnt-Skripte für jede Aufgabe und erstellen Sie Ihre NAnt-Skripte nacheinander, bis Sie Ihren gesamten Build-Prozess vollständig automatisiert haben. Außerdem werden alle Ihre Builds an einem Ort gespeichert, was zu Vergleichszwecken gut ist. In Build 426 ist etwas kaputt gegangen, das in Build 380 gut funktioniert hat? Nun, da sind die Ergebnisse zum Testen bereit - schnappen Sie sie sich und testen Sie sie.

• Keine Lizenzen erforderlich. CruiseControl.net ist frei verfügbar und benötigt zum Erstellen nur die .NET-SDK.
• Ein Build-Server bietet auch ohne automatisierte Komponententests eine kontrollierte Umgebung für Build-Releases. Nicht mehr "John baut normalerweise auf seiner Maschine, aber er ist krank. Aus irgendeinem Grund kann ich nicht auf meiner Maschine bauen."
• Im Moment habe ich eine in einer Virtual PC-Sitzung eingerichtet.
• Ja. Der Build muss an einem zugänglichen Ort abgelegt werden. Bei Entwicklungs-Builds sollte das Debuggen aktiviert sein. Release Build sollte deaktiviert sein.
• Wie oft liegt es an dir. Bei korrekter Einrichtung können Sie nach jedem Check-in nur sehr wenig Aufwand aufbauen. Dies ist eine großartige Idee, wenn Sie Unit-Tests durchgeführt haben (oder planen).
• Halten Sie Meilensteine ​​und Veröffentlichungen so lange wie erforderlich. Alles andere hängt davon ab, wie oft Sie bauen: kontinuierlich? wegschmeißen. Täglich? Halten Sie eine Woche wert. Wöchentlich? Halten Sie zwei Monate wert.

Je größer Ihr Projekt wird, desto mehr sehen Sie die Vorteile einer automatisierten Build-Maschine.

Es geht um die Gesundheit des Builds. Dies bringt Ihnen die Möglichkeit, alle Arten von Dingen einzurichten, die mit den Builds geschehen sollen. Unter diesen können Sie Tests, statische Analysen und Profiler ausführen. Probleme werden viel schneller behoben, als Sie kürzlich an diesem Teil der Anwendung gearbeitet haben. Wenn Sie kleine Änderungen vornehmen, sagt es Ihnen fast, wo Sie es gebrochen haben :)

Dies setzt natürlich voraus, dass Sie es so einrichten, dass es bei jedem Einchecken erstellt wird (kontinuierliche Integration).

Es kann auch helfen, QA und Dev näher zu bringen. Da können Sie Funktionstests einrichten, um damit zu arbeiten, zusammen mit dem Profiler und allem anderen, was das Feedback an das Entwicklerteam verbessert. Dies bedeutet nicht, dass die Funktionstests bei jedem Einchecken ausgeführt werden (kann eine Weile dauern), aber Sie richten Builds / Tests mit Tools ein, die dem gesamten Team gemeinsam sind. Ich habe Rauchtests automatisiert, daher arbeiten wir in meinem Fall noch enger zusammen.

Warum: Vor 10 Jahren haben wir als Softwareentwickler, um etwas bis zum n-ten Grad zu analysieren, die Dokumente (in einer menschlichen Sprache geschrieben) "abgemeldet" und dann angefangen, Code zu schreiben. Wir haben Unit-Test, String-Test und dann Systemtest durchgeführt: Das erste Mal, dass das gesamte System zusammen ausgeführt wird, manchmal Wochen oder Monate, nachdem wir die Dokumente abgemeldet haben. Erst dann konnten wir alle Annahmen und Missverständnisse aufdecken, die wir hatten, als wir alles analysierten.

Kontinuierliche Integration als und Idee führt dazu, dass Sie ein vollständiges (wenn auch anfangs sehr einfaches) System von Ende zu Ende erstellen. Im Laufe der Zeit wird die Systemfunktionalität orthogonal aufgebaut. Jedes Mal, wenn Sie einen vollständigen Build ausführen, führen Sie den Systemtest früh und häufig durch. Dies bedeutet, dass Sie Fehler und Annahmen so früh wie möglich finden und beheben, wenn dies der günstigste Zeitpunkt ist, um sie zu beheben.

Wie: Was das Wie betrifft, habe ich vor einiger Zeit darüber gebloggt: [ Hier klicken ]

In 8 Beiträgen wird Schritt für Schritt beschrieben, wie Sie einen Jenkins-Server in einer Windows-Umgebung für .NET-Lösungen einrichten.