Automatisierte Build-Plattform für .NET-Portfolio - beste Wahl? [geschlossen]

Ich beschäftige mich mit der Pflege eines ziemlich großen Portfolios von .NET-Anwendungen. Ebenfalls im Portfolio sind Legacy-Anwendungen, die auf anderen Plattformen basieren - natives C ++, ECLIPS Forms usw.

Ich habe gerade ein komplexes Build-Framework auf NAnt, das die Builds für alle diese Anwendungen verwaltet. Das Build-Framework verwendet NAnt, um verschiedene Dinge zu tun:

• Ziehen Sie Code aus Subversion heraus und erstellen Sie Tags in Subversion
• Erstellen Sie den Code mit MSBuild für .NET oder anderen Compilern für andere Plattformen
• Schauen Sie in AssemblyInfo-Dateien, um die Versionsnummern zu erhöhen
• Löschen Sie bestimmte Dateien, die nicht in Builds / Releases enthalten sein sollten
• Gibt Code in Bereitstellungsordnern frei
• Postleitzahl für Sicherungszwecke
• Bereitstellen von Windows-Diensten; starte und stoppe sie
• Usw.

Die meisten dieser Dinge können nur mit NAnt selbst erledigt werden, aber wir haben einige Erweiterungsaufgaben für NAnt erstellt, um einige Dinge zu erledigen, die für unsere Umgebung spezifisch sind. Außerdem werden die meisten der oben genannten Prozesse generiert und in vielen unserer verschiedenen Anwendungserstellungsskripts wiederverwendet, sodass wir die Logik nicht wiederholen. Es ist also kein einfacher NAnt-Code und keine einfachen Build-Skripte. Es gibt Dutzende von NAnt-Dateien, die zusammenkommen, um einen Build auszuführen.

In letzter Zeit war ich aus mehreren Gründen mit NAnt unzufrieden: (1) Die Syntax ist einfach schrecklich - Programmiersprachen über XML sind wirklich schrecklich zu pflegen. (2) Das Projekt scheint am Rebstock gestorben zu sein. In letzter Zeit gab es nicht viele Updates und es scheint, dass niemand wirklich am Ruder ist. Der Versuch, es mit .NET 4 zum Laufen zu bringen, hat aufgrund dieser mangelnden Aktivität einige Probleme verursacht.

Nach all dem Hintergrund ist hier meine Frage. Angesichts einiger Dinge, die ich basierend auf der obigen Liste erreichen möchte, und angesichts der Tatsache, dass ich mich hauptsächlich in einem .NET-Shop befinde, aber auch Nicht-.NET-Projekte erstellen muss, gibt es eine Alternative zu NAnt, die ich in Betracht ziehen sollte wechseln zu?

Zu den Dingen auf meinem Radar gehören Powershell (mit oder ohne Psake ), MSBuild für sich und Rake . Diese haben alle Vor- und Nachteile. Ist MSBuild beispielsweise leistungsfähig genug? Ich erinnere mich, dass ich es vor Jahren benutzt habe und es schien nicht so viel Kraft zu haben wie NAnt. Möchte ich wirklich, dass mein Team Ruby lernt, nur um Builds mit Rake zu erstellen? Ist psake wirklich ausgereift genug für ein Projekt, an das ich mein Portfolio binden kann? Ist Powershell "zu nah am Metall" und ich muss am Ende meine eigene Build-Bibliothek schreiben, die psake ähnelt, um sie alleine zu verwenden?

Gibt es andere Tools, die ich berücksichtigen sollte? Welches Build-Tool würden Sie in Betracht ziehen, wenn Sie an der Pflege eines .NET-Portfolios mit erheblicher Komplexität beteiligt wären? Was verwendet Ihr Team derzeit?

Wenn Sie TeamCity bereits verwenden, sollten Sie in der Lage sein, die vorhandenen Funktionen für die meisten Ihrer Anforderungen zu verwenden. Es unterstützt nativ das Erstellen von .sln-Dateien in Visual Studio. Wenn Sie zusätzliche Aufgaben für alle Ihre Projekte benötigen, können Sie die .targets-Dateien von .NET Framework auf Ihren Build-Computern ändern, sodass Sie nicht einzelne csproj-Dateien ändern müssen.

Es wird automatisch aus Subversion ausgecheckt, Zip-Artefakte, mit denen Sie steuern können, welche Dateien als bereitstellbare Artefakte gelten. Die neue Version (6.0) ermöglicht auch mehrere Erstellungsschritte, sodass die xcopy-Bereitstellung von Artefakten für eine Freigabe möglich ist.

Sie können auch Ihre eigenen Apps / Aufgaben schreiben, die als Teil eines Builds (über den Befehlszeilen-Runner) ausgeführt werden können, und alles tun, was Sie möchten (z. B. Windows-Prozesse starten / stoppen).

Wir betrachten die Dinge als drei verschiedene Aktivitäten: Erstellen, Bereitstellen und Installieren. Wir verwenden TFS für den Build-Server mit einigen Beschriftungen für Powershell. Wir verwenden dann Powershell, um alle Deploy- und Install-Teile auszuführen, die ziemlich komplex sind und sich über mehrere Server sowohl lokal als auch in der Cloud erstrecken. Ich war sehr zufrieden mit dem Erlernen von Powershell über MSBuild oder ein anderes Tool. Ich habe in der Vergangenheit auch gute Erfahrungen mit Visual Build gemacht.

Schauen Sie sich Hudson und MSBuild als Paar an. Die Leistung kommt mit den starken Fähigkeiten von MSBuild und den Hudson- Plugins .

Sie können beispielsweise Hudson verwenden und Ihre NAnt-Skripte ausführen, bis Sie zu MSBuild migrieren. Anschließend können auch Ihre MSBuild-Skripte ausgeführt werden.

Speziell auf Ihre Punkte eingehen:

• Subversion und Tagging
• MSBuild
• Ein Blick in AssemblyInfo wurde auf SO gefragt , aber die Lösung könnte nicht Ihren Wünschen entsprechen
• MSBuild kann Dateien problemlos löschen
• "Code für Bereitstellungsordner freigeben" - Sie können das Build-System diesen Schritt überspringen lassen und ihn mithilfe einer Reihe von Methoden automatisch bereitstellen. Oder Sie können FTP, wenn Sie möchten.
• MSBuild kann zippen
• Windows-Dienste, wieder ist MSBuild Ihr Freund hier.

Ich benutze Automated Build Studio . Ich möchte es loswerden.

Der einzige Grund, warum ich nicht zu 100% MS Build oder Team Foundation Build wechsle, sind die Kosten für die Neuerstellung der Skripte, die heute einwandfrei funktionieren. Die Skripte ändern sich nicht viel ...

Für das nächste Produkt ist dies jedoch Team Foundation Build ohne zu zögern aus den folgenden Hauptgründen (es sind viele weitere):

• Es ist einfach bereitzustellen (neueste Version: 2010)
• Es ist vollständig in Visual Studio und Team Foundation Server integriert
• Es wird zu einem Standard wie MS Build
• Es ist kostenlos mit Bizspark (für Startups)

Da Sie auch in .NET sind, empfehle ich Ihnen dringend, TFB zu verwenden.

Wenn Sie Bizspark nicht beantragen können oder es sich nicht leisten können, die Lizenz zu erwerben, können Sie sich für CruiseControl.NET + MS Build und einige Support-Skripte entscheiden. Bei einem großen Versorgungsunternehmen, für das ich gearbeitet habe, hatten wir CruiseControl.NET verwendet , um alle unsere Projekte zu erstellen, zu testen, bereitzustellen und zu melden. Es beinhaltete die automatische Bereitstellung von Webdiensten.

FinalBuilder kann alle von Ihnen angeforderten Aufgaben ausführen , wobei eine schöne Benutzeroberfläche und eine Builder-Serveranwendung kostenlos zur Verfügung stehen.

Ich mache gerade das, was Sie tun (dh vom Build über das Packen bis zur Bereitstellung), mit MSBuild (> 3000 Skriptzeilen). Das CI verwendet CruiseControl.Net und ich hoffe, dass ich in Zukunft zu TeamBuild wechseln kann. MSBuild ist umständlich (Programmierung in XML), aber es ist sehr leistungsfähig, insbesondere bei der Stapelverarbeitung und der Abhängigkeitsverfolgung. Es wird in neuen .NET-Versionen aktiv gewartet und verbessert und ist die Grundlage für das Buildsystem in Visual Studio und TFS. Auch Visual Studio-Projektdateien sind eigentlich MSBuild-Projekte und ich kann mich an verschiedene Erweiterungspunkte anschließen. Das MSBuild-Erweiterungspakethat viele zusätzliche Aufgaben und es ist trivial einfach, eigene Aufgaben programmgesteuert zu erstellen. Ich schlage vor, MSBuild ernsthaft zu überlegen. In letzter Zeit lerne ich auch Powershell und finde es einfach für bestimmte Aufgaben, insbesondere in der Bereitstellungsphase, wie das Installieren und Konfigurieren von Zertifikaten, IIS usw.

Bearbeiten Sie das MSBuild-Projekt in VisualStudio, da es die Syntax versteht und Ihnen Intellisense bietet. Hier sind einige andere gute Dienstprogramme, die bei MSBuild helfen.
MSBuild Launch Pad - Für Shell-Erweiterungen
MSBuild SideKicks - Skripts grafisch bearbeiten, ausführen und debuggen.

Vielleicht fordern Sie zu viel von Ihrem Build-Skript und nicht genug von Ihrem Build-Server - mit Team City könnten Sie leicht einfache Skripte haben, die jede Ihrer Aufzählungszeichen in jeder Sprache oder in jedem Stapel ausführen, die sinnvoll sind, und TeamCity-Build-Aufgaben verwenden verketten Sie die Dinge nach Bedarf.

Ich empfehle TeamCity dringend, es ist einfach zu konfigurieren und einzurichten. MSBuild ist NAnt vorzuziehen, da alle Projekt- / Lösungsdateien im vs2008 / 2010 technisch gesehen MSBuild-Dateien sind. Sie können TeamCity jedoch mit MSBuild oder NAnt konfigurieren.

Natürlich kostet Sie TeamCity. Ich persönlich habe eine Wahl getroffen, würde Rechen bevorzugen, einfach weil die Reibung mit Ruby-Werkzeugen im Vergleich zu anderen, obwohl Psake auch ein guter Kandidat ist.

Hast du Hudson in Betracht gezogen ? Es ist vielleicht ein bisschen mühsam, da Java App Server ausgeführt werden muss, aber ich denke , Sie können damit Ihr aktuelles NAnt-Skript verwenden und mit anderen Tools darauf aufbauen.