Verbessern Sie Ihren Build-Prozess

StackOverflow https://stackoverflow.com/questions/14893

Frage

Oder tatsächlich einen Build-Prozess etablieren, wenn von Anfang an noch nicht viel davon vorhanden ist.

Derzeit ist das in etwa die Situation, mit der meine Gruppe konfrontiert ist.Wir entwickeln hauptsächlich Web-Apps (derzeit jedoch keine Desktop-Entwicklung).Softwarebereitstellungen sind selbst mit unseren bescheidenen Apps hässlich und unhandlich, und in den zwei Jahren, in denen ich Teil dieses Teams (und Unternehmens) bin, sind viel zu viele Probleme aufgetreten.Es ist an der Zeit, etwas dagegen zu unternehmen, und das Ergebnis ist, dass wir zwei Joel-Test-Fliegen mit einer Klappe schlagen können (Tages-Builds und One-Step-Builds, von denen keines in irgendeiner Form existiert).

Was ich hier suche, sind allgemeine Einblicke in die Art von Dingen, die ich tun oder über die ich nachdenken muss, von Leuten, die schon länger in der Softwareentwicklung tätig sind als ich und auch über ein größeres Gehirn verfügen.Ich bin zuversichtlich, dass dies die meisten Leute sein werden, die derzeit in der Beta posten.

Relevante Tools:Visual Build Source Safe 6.0 (ich weiß, aber ich kann nichts dagegen tun, ob wir die Safe von Source Safe zu diesem Zeitpunkt verwenden.Das könnte der nächste Kampf sein, den ich kämpfe.)

Vorläufig habe ich ein Visual Build-Projekt, das Folgendes tut:

  1. Rufen Sie die Quelle ab und platzieren Sie sie im lokalen Verzeichnis, einschließlich der für das Projekt erforderlichen DLLs.
  2. Rufen Sie Konfigurationsdateien ab und benennen Sie sie nach Bedarf um (wir speichern sie in einem speziellen Unterverzeichnis, das nicht Teil der eigentlichen Anwendung ist, und sie werden entsprechend ihrer Verwendung benannt).
  3. Erstellen Sie mit Visual Studio
  4. Über die Befehlszeile vorkompilieren und in ein späteres „Build“-Verzeichnis kopieren
  5. Zum Ziel kopieren.
  6. Besorgen Sie sich alle erforderlichen zusätzlichen Ressourcen – hauptsächlich Dinge wie Dokumente, Bilder und Berichte, die mit dem Projekt verknüpft sind (und ab Schritt 5 im Verzeichnis abgelegt werden).Es gibt eine Menge davon, und ich wollte es vorher nicht einbeziehen.Allerdings werde ich nur geänderte Elemente kopieren, daher ist das vielleicht irrelevant.Ich war mir nicht sicher, ob ich dieses Zeug wirklich in frühere Schritte einbeziehen wollte.

Ich muss mich für all das noch dazu überreden, mich von Visual Build abzumelden, aber ich bin noch nicht an dem Punkt, an dem ich das tun muss.

Hat jemand Ratschläge oder Vorschläge?Ich stelle fest, dass wir derzeit kein Bereitstellungsprojekt verwenden.Ich gehe davon aus, dass einige der in diesem Build erforderlichen Schritte entfernt werden würden (z. B. der Austausch von web.config).

War es hilfreich?

Lösung

Wenn Sie ein Projekt in Angriff nehmen, für das noch nie ein automatisierter Build-Prozess stattgefunden hat, ist es einfacher, es schrittweise anzugehen.Versuchen Sie nicht, zu viel auf einmal zu schlucken, da es sich sonst überwältigend anfühlen kann.

  1. Lassen Sie Ihren Code zunächst in einem Schritt mit einem automatisierten Build-Programm kompilieren (z. B.nant/msbuild).Ich werde nicht darüber diskutieren, welches besser ist.Finden Sie eines, das sich für Sie angenehm anfühlt, und verwenden Sie es.Lassen Sie die Build-Skripte mit dem Projekt in der Quellcodeverwaltung live.
  2. Finden Sie heraus, wie Ihr automatisierter Build ausgelöst werden soll.Egal, ob Sie es an CruiseControl anschließen oder eine nächtliche Build-Aufgabe mithilfe geplanter Aufgaben ausführen.CruiseControl oder TeamCity sind hierfür wahrscheinlich die beste Wahl, da sie viele Tools enthalten, mit denen Sie diesen Schritt erleichtern können.CruiseControl ist kostenlos und TeamCity ist bis zu einem gewissen Grad kostenlos, sodass Sie möglicherweise dafür bezahlen müssen, je nachdem, wie groß das Projekt ist.
  3. Ok, zu diesem Zeitpunkt werden Sie mit den Werkzeugen ziemlich vertraut sein.Jetzt können Sie weitere Aufgaben hinzufügen, je nachdem, was Sie zum Testen, Bereitstellen usw. tun möchten.

Hoffe das hilft.

Andere Tipps

Ich habe eine Reihe von Powershell-Skripten, die das alles für mich erledigen.

Skript 1:Build – dieser ist einfach, er wird größtenteils durch einen Aufruf von msbuild abgewickelt und erstellt außerdem meine Datenbankskripte.

Skript 2:Paket – Dieses verwendet verschiedene Argumente, um eine Version für verschiedene Umgebungen zu packen, z. B. Testumgebungen und Teilmengen der Produktionsumgebung, die aus vielen Maschinen besteht.

Skript 3:Bereitstellen – Dies wird auf jedem einzelnen Computer aus dem vom Paketskript erstellten Ordner ausgeführt (das Bereitstellungsskript wird als Teil des Pakets kopiert).

Mithilfe des Deploy-Skripts überprüfe ich Dinge wie den Maschinennamen auf Plausibilität, damit Dinge nicht versehentlich an der falschen Stelle bereitgestellt werden.

Für web.config-Dateien verwende ich die 

<appSettings file="Local.config">

Diese Funktion verfügt über Überschreibungen, die bereits auf den Produktionsmaschinen vorhanden sind, und sie sind schreibgeschützt, damit sie nicht versehentlich überschrieben werden.Die Local.config-Dateien werden nicht eingecheckt und ich muss zur Erstellungszeit keine Dateiwechsel vornehmen.

[Bearbeiten] Das Äquivalent von appSettings file= für einen Konfigurationsabschnitt ist configSource="Local.config"

Wir sind vor zwei Jahren von der Verwendung eines Perl-Skripts auf MSBuild umgestiegen und haben es nicht bereut.Das Erstellen von Visual Studio-Lösungen kann durch einfaches Angeben in der XML-Hauptdatei erfolgen.

Für alles, was komplizierter ist (Ihren Quellcode abrufen, Komponententests ausführen, Installationspakete erstellen, Websites bereitstellen), können Sie einfach eine neue Klasse in .net erstellen, die von abgeleitet ist Aufgabe Dies überschreibt die Execute-Funktion und verweisen Sie dann in Ihrer Build-XML-Datei darauf.

Eine ziemlich gute Einführung gibt es hier:Einführung

Ich habe nur an ein paar .Net-Projekten gearbeitet (ich habe hauptsächlich Java gemacht), aber eine Sache, die ich empfehlen würde, ist die Verwendung eines Tools wie NAnt.Ich habe ein echtes Problem mit der Kopplung meines Builds an die IDE. Dadurch wird es zu einem echten Problem, später Build-Server einzurichten, da Sie auf jeder Box, von der aus Sie erstellen möchten, eine vollständige VS-Installation durchführen müssen Zukunft.

Allerdings ist jeder automatisierte Build besser als kein automatisierter Build.

Unser Build-Prozess besteht aus einer Reihe selbst erstellter Perl-Skripte, die über ein Jahrzehnt oder so entwickelt wurden. Nichts Besonderes, aber es erledigt den Job.Ein Skript ruft den neuesten Quellcode ab, ein anderes erstellt ihn, ein drittes stellt ihn an einem Netzwerkspeicherort bereit.Wir entwickeln Desktop-Anwendungen, daher erstellt unser Staging-Prozess auch Installationspakete zum Testen und schließlich zum Versand an Kunden.

Ich schlage vor, dass Sie es in einzelne Schritte aufteilen, da es Zeiten geben wird, in denen Sie neu erstellen möchten, aber nicht auf dem neuesten Stand sind, oder vielleicht einfach eine Neubereitstellung durchführen müssen.Unsere Skripte können auch den Aufbau aus verschiedenen Zweigen bewältigen. Berücksichtigen Sie dies also auch bei jeder Lösung, die Sie entwickeln.

Schließlich verfügen wir über eine dedizierte Build-Maschine, die jede Nacht die Trunk- und Wartungszweige neu erstellt und bei Problemen oder bei erfolgreichem Abschluss eine E-Mail sendet.

Eines würde ich vorschlagen: Stellen Sie sicher, dass sich Ihr Build-Skript (und Ihr Installationsprojekt, falls in Ihrem Fall relevant) in der Quellcodeverwaltung befindet.Ich verwende in der Regel ein sehr einfaches Skript, das einfach das „Haupt“-Build-Skript auscheckt/aktuell abruft und es dann startet.

Ich sage das, weil ich sehe, dass Teams einfach die neueste Version des Build-Skripts auf dem Server ausführen, es aber entweder nie in die Quellcodeverwaltung stellen oder wenn sie es tun, sie es nur nach dem Zufallsprinzip einchecken.Wenn Sie den Build-Prozess so gestalten, dass er von der Quellcodeverwaltung „abruft“, werden Sie gezwungen, das neueste und beste Build-Skript dort zu behalten.

Unser Build-System ist ein Makefile (oder zwei).Es hat ziemlich viel Spaß gemacht, es zum Laufen zu bringen, da es sowohl unter Windows (als Build-Task unter VS) als auch unter Linux (als normale „Make Bla“-Task) laufen muss.Das wirklich Lustige daran ist, dass der Build die eigentliche Dateiliste aus einer .csproj-Datei abruft, daraus (ein weiteres) Makefile erstellt und dieses ausführt.In den Prozessen ruft sich die Make-Datei tatsächlich selbst auf.

Wenn dieser Gedanke den Leser nicht erschreckt, dann (entweder sind sie verrückt oder) können sie wahrscheinlich make + „deinen Lieblings-Stringmangler“ für sich arbeiten lassen.

Wir verwenden UppercuT.UppercuT verwendet NAnt zum Erstellen und ist äußerst einfach zu verwenden.

http://code.google.com/p/uppercut/

Einige gute Erklärungen hier: UppercuT

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top