2009-05-03 5 views
2

Angenommen, Sie haben zwei Entwickler, die lokal an einem Projekt auf ihren Laptops arbeiten (A und B). Sie haben jeweils Arbeitskopien des SVN-Repos, und sie codieren in VS weg. Jeder hat eine voll funktionsfähige Kopie der App. Sie verpflichten sich bei jedem Haltepunkt zu SVN.Wie bewirken Sie einen Build auf einem Integrationsserver?

Sie verfügen über einen Integrations-/Testserver (C) mit einer anderen Arbeitskopie, die aktualisiert wird, wenn Sie sie testen möchten.

Sie auch Produktionsserver (D) aufweisen, die ein Postbuild xcopy von C.

der Code Sagen hat, ist ein Web Application Project, so dass es erfordert eine explizite Build (im Gegensatz zu einer Web-Site gegen Projekt, das nur den Quellcode nimmt und on-the-fly erstellt.

Wie verwalten Sie dies auf dem Integrationsserver (C)?

Wenn die Entwickler auf ihren Maschinen (A und B) bauen, dann drücken Sie die DLLs auf den Integrationsserver (C) ... das wird nicht funktionieren, weil der Integrationsserver Code von beiden nehmen muss Entwickeln Sie eine gemeinsame DLL. Also, der ganze Quellcode muss zum Integrationsserver (C) gehen, dort gebaut werden, und nur die erforderlichen Dateien und DLL zur Produktion geschoben (D).

Wie verwalten Sie den Build auf dem Integrationsserver (C)? Haben Sie eine zeitgesteuerte Erstellung von der Befehlszeile? Installieren Sie VS auf dem Integrationsserver (C) und bauen Sie so auf? Wie verwaltet man die erforderlichen Referenzen und andere Einstellungen, die VS normalerweise in einer CSPRJ- oder einer SLN-Datei verwaltet, wenn dies über die Befehlszeile geschieht?

+0

Danke an alle, die kommentiert haben. Am Ende haben wir CruiseControl eingerichtet, und wir verwenden die CSC-Task in Nant, um direkt von der Befehlszeile auf dem Integrationsserver zu erstellen. Es funktioniert sehr gut und bietet uns den Vorteil eines kontrollierteren und standardmäßigen Builds, den man von einer Reihe von Entwicklern erhält, die ihre lokalen VS-Kopien erstellen. – Deane

Antwort

2

Die beste Lösung für diese Frage ist die Verwendung einer Continuous-Build-Lösung wie CruiseControl. Sie haben alle Fehler, die Sie selbst gemacht haben, richtig erkannt, und am Ende wird es viel einfacher sein, ein Paket für Dritte zu erstellen und diese Probleme nicht selbst zu lösen.

CruiseControl kann so konfiguriert werden, dass es basierend auf einer Subversion Commit, zeitgesteuert oder bei Bedarf erstellt wird. Darüber hinaus kann es auch alle Gerätetests ausführen und Personen warnen, wenn etwas schief läuft. Es ist insgesamt ein ziemlich tolles Paket.

0

Wir verwenden auch einen Subversion-Commit-Hook von out svn repo, der den Unit-Test-Build bei jedem Commit aktiviert. Wir verketten die verschiedenen Builds, sodass der Integrationstest und die Webtests ausgeführt werden, wenn die Komponententests grün erstellt werden. Darüber hinaus möchten wir den Release-Build am Ende all dieser Dinge ketten, aber unsere Integrationstests sind dafür nicht stabil genug (flockige Backend-Umgebungen mit schlechten SLAs in der Entwicklung - ich hasse es!). Im Moment starten wir die Release-Builds manuell. Von einer Qualitätsperspektive aus könnten wir direkt von allen grünen Lichtern zu Akzeptanztest-Servern gehen, aber das bedeutet, dass Sie wahrscheinlich abwechselnde Bilder im Abnahmetest laufen lassen wollen, da das Build-System ziemlich viel Ausfallzeit erzeugen kann, wenn es jedes Mal neu eingibt erfolgreiches commit ist den ganzen Weg gegangen. (In unserem Projekt wären wir meistens von 10 bis 14 Uhr unten, da es zu dieser Zeit einen kontinuierlichen Strom von Commits gibt;)

+0

Aber wie führen Sie den Build tatsächlich aus? Befehlszeile? CC.Net? – Deane

+0

Nachdem wir alle Open-Source-Varianten ausprobiert hatten, landeten wir bei Atlassians Bamboo. Das klügste Geld, das wir je ausgegeben haben; Sie können eine Menge Zeit damit verbringen, zu versuchen, dass ein Build ordnungsgemäß funktioniert. – krosenvold

0

Wir verwenden Cruise Control für die kontinuierliche Integration auf dem Integration Server. Unser Geschwindigkeitsregelungsskript führt die folgenden Schritte aus:

  • Downloadet den neuesten Code von SVN auf dem cc.net-Server
  • Führt MSBUILD Datei den neuesten Code für die Erstellung heruntergeladen
  • das Release-Build in einem separaten Ordner kopieren
  • Wir einen separaten Ordner für „Release“ halten baut, so das gleiche Skript verpflichtet auch die neueste Version im SVN „Release“ Zweig
  • Führen Sie die Testfälle [gebaut nUnit mit]
  • senden Sie eine E-Mail den Baustatus & Testausführung enthält, führt

die oben genannten Befehle Alle sind auf unserem CC.net-Server konfiguriert und für 1.00 Uhr Ausführung geplant. Um die Wartung zu vereinfachen, haben wir unseren CC.net-Server auf unserem Integration Server selbst implementiert. das hilft uns auch, unsere Testfälle automatisch auszuführen und die Ergebnisse zu versenden, wenn es sich um eine Webanwendung handelt. Jeder Code-Bruch wird in einer E-Mail an die konfigurierten Teilnehmer gesendet, und die entsprechenden Aktionen werden am nächsten Tag ausgeführt.

Sobald auf dem Integration Server alles in Ordnung ist, "aktualisieren" wir einfach den Zweig "Release" auf dem Produktionsserver.

können Sie weitere Informationen über cc.net here

, wenn Sie Hilfe benötigen, mit den Skripten finden, ich sicherlich Ihnen helfen können.