4

Im Laufe der Jahre habe ich eine Reihe von NAnt-Skripten erstellt und optimiert, um komplette Projekt-Builds durchzuführen. Das Hauptskript nimmt einen einzelnen Anwendungsendpunkt (z. B. ein Webanwendungsprojekt) und erstellt daraus eine vollständige Quellcodeverwaltung. Die Skripte sind mit den notwendigen Informationen bezüglich Build-Ausgangspositionen, Quellensteueradressen usw. vorkonfiguriert. Der Hauptpunkt ist, dass Sie sehr wenig Informationen einspeisen und ein bestimmtes Projekt von Grund auf erstellen können. Dies befriedigt den "willkürlichen" Teil meiner Frage.Zentralisieren/Steuern beliebiger Builds von .NET-Projekten und -Lösungen

In der Vergangenheit habe ich für Unternehmen gearbeitet, die ein paar Softwareprodukte (meist Webanwendungen) produzieren. Diese Umgebung eignet sich sehr gut für einen typischen kontinuierlichen Integrationsaufbau, bei dem für jedes Produkt ein Integrator vorhanden ist. Ich habe Integratoren eingerichtet, die sowohl als CI-Builds als auch als Integratoren für die Erstellung eines kompletten Release Candidate Builds und QA-Deployments dienen. Diese Integratoren verwenden die Master-Build-Skripte, so dass die Integratoren selbst kaum mehr als die Überwachung der Quellcodeverwaltung und ein Aufruf des Master-NAnt-Skripts sind.

Ich arbeite jetzt für eine Entwicklungsgruppe, die viele Anwendungen erstellt. Oft werden Entwickler aufgerufen, Anwendungen zu unterstützen, die ursprünglich von anderen entwickelt wurden. Als ich anfing, gab es kein Build-Management. Ich bin in einer besonders einzigartigen Position innerhalb der Gruppe als Hauptentwickler eines 4-Personen-Teams für die Produkt-Suite einer Geschäftseinheit (etwa ein halbes Dutzend kompletter Systeme). Ich habe CruiseControl.Net mit den Master-Build-Skripten implementiert, um sowohl CI-Builds als auch RC-Builds zu erstellen. Dies funktioniert für die festgelegte Menge von Projekten innerhalb der Produktsuite des Unternehmens.

Ich benutze CCNet seit vielen Jahren, also weiß ich, was es kann. Ich habe großen Respekt für seinen Beitrag zur kontinuierlichen Integration, da ich ihn für alle Projekte meiner Produktfamilie verwende. Ich habe mein Team auf die Verwendung des offiziellen RC-Build-Integrators als Baumeister für alles hingewiesen, was für einen anderen Ort als die Entwicklung bestimmt ist. Dies bietet eine hervorragende Kontrolle über die festgelegte Menge von Projekten, die unter der Kontrolle von CCNet stehen.

Allerdings gibt es andere Entwickler, die andere Anwendungen erstellen. Einige davon sind 1 Entwicklerprojekte, die oft nicht einmal in der Quellcodeverwaltung sind, bis weit in den Projektlebenszyklus (etwas anderes versuche ich zu ändern). Viele dieser Projekte sind Unikate, die nach ihrer Einführung nicht viel Leben in Entwicklung haben werden. Trotzdem müssen sie immer noch unterstützt werden. Integraler Bestandteil der Unterstützung ist die Tatsache, dass ohne ein zentrales Build-Management dieser Projekte die Release Candidates Builds zur QA erstellt werden und schließlich die Produktion auf einzelnen Entwicklungsmaschinen erfolgen muss. Dies stellt natürlich eine Null-Garantie bereit, dass alles in der Quellcodeverwaltung unter den anderen Faktoren eines Entwickler-Maschinen-Builds ist.

Das Problem, das ich zu lösen versuchte, ist: Welche Art von System kann ich verwenden, um eine zentrale Kontrolle über diese Art von beliebigen Builds zu bieten? Dies ist definitiv kein einzigartiges Problem. Bei vielen der Lektüre, die ich über zentralisierte Builds, Build Automation und kontinuierliche Integration gemacht habe, liegt der Fokus jedoch auf festen Projekten/Produkten und der Aufgabe, deren Weiterentwicklung zu unterstützen. Welche Arten von Prozessen werden von Unternehmen verwendet, die ständig an neuen Projekten arbeiten? Verwenden sie diese Art von Prozessen nicht?

Während sich die Master-Build-Skripte auf dem Build-Server befinden, sind sie unhandlich. Außerdem würde ich es vorziehen, den Konsolenzugriff auf den Build-Server zu beschränken. Daher ist ein Managementsystem erforderlich, um den Zugriff auf willkürliche Builds auf einem zentralen System zu erleichtern.

Ich weiß, dass das, was ich suche, unter den Deckeln von MS Team Build liegen kann. Leider bekomme ich jedesmal, wenn ich darüber lese, das Gefühl von Treibsand, wenn ich anfange, mich in das MS-Marketingmaterial zu stürzen und schnell meinen Weg zu verlieren, nie wirklich herauszufinden, ob das, was ich tun möchte, damit erledigt werden kann.Außerdem wurden die Lizenzkosten in den letzten allgemeinen Diskussionen zum Thema Team Foundation Server und Team System als wahrscheinlicher Show-Stopper angesprochen.

Ich bin gespannt, von jemandem zu hören, der dieses Problem gelöst hat, wer Vorschläge anbieten könnte. Ich habe etwas an einem zentralisierten Build-System gearbeitet, das auf meinen Master-Build-Skripten basiert. Das, was ich habe, steckt jedoch noch in den Kinderschuhen und wurde konstruiert, um hauptsächlich die Arten von Projekten zu unterstützen, an denen ich arbeite. Es fehlt die Art von Unterstützung, die an dieser Stelle erforderlich ist, um viele Anwendungstypen oder die Vielzahl von Projekt-/Lösungskonfigurationen, die mit Visual Studio möglich sind, zu handhaben.

Antwort

3

Das größte Problem, das ich bei einem zentralen Build-System sehe, ist, dass selbst bei bestem Willen der Welt Werkzeuge zwischen den Teams oder im Laufe der Zeit auseinanderlaufen werden.

Ich bevorzuge Entwurf jedes Build-System für ein bestimmtes Projekt, so dass es erfordert, ein einzelnes Modul z. MyProjectBuildEnvironment und dann Ausführen eines einzelnen Skripts auf sehr werkzeugneutrale Weise, z. auf einem Windows-System build.bat

Wo möglich sollten alle von der Build-Umgebung verwendeten Tools ausführbar sein, indem Sie einfach das Modul MyProjectBuildEnvironmen auschecken, anstatt Maschinen-Level-Installer zu benötigen.

Diese zwei Einschränkungen werden die Freiheiten von Teams nicht behindern, die Werkzeuge zu verwenden, die sie zu einer bestimmten Zeit bevorzugen.

Das zentrale Build-System kann dann ein einfaches System sein, das ein Modul pro Projekt auscheckt und einfach die Datei build.bat ausführt. Sie könnten es ein Meta-Build-System nennen.

Um ehrlich zu sein, wäre es wahrscheinlich zu viel Aufwand, da ein einfaches Wiki, das den Namen des Build-Moduls für jedes Projekt beschreibt, ausreicht, damit jeder dieses Modul auschecken und mit dem gemeinsamen Befehl build.bat starten kann.

Als letzte Anmerkung sollte das Skript zum Starten des Builds immer die Umgebung untersuchen und dem Benutzer mitteilen, ob irgendwelche Tools fehlen oder ob eine Maschinenkonfiguration optimiert werden muss, um den Build erfolgreich abzuschließen.

+0

ABSOLUT! Ein Build-Server pro Produkt, ein Quell-Repository, ein Check-Out (Pull) und alle müssen kompiliert und ausgeführt werden. Ich arbeite in einem großen Unternehmen mit zentralisiertem Build-System und als Folge wird die Entwicklungsumgebung mit all den benutzerdefinierten Tools verschmutzt, die an den Entwickler weitergegeben werden, anstatt das zu haben, was auf einem benutzerdefinierten Build-Server benötigt wird. Es gibt eine Menge verlorener Produktivität, wenn man versucht, diese Tools zu bekämpfen und die lokalen Builds arbeiten zu lassen –

Verwandte Themen