| 

.NET C# Java Javascript Exception

10
Hallo zusammen,

ich habe mich in den letzten Tagen intensiv mit CI beschäftigt, kann jetzt dem Server umgehen (TeamCity). Wobei ich mir jetzt aber unsicher bin, ist die Zuordnung der Projekte und eine gute Lösung.

Wir haben hier eine Bibliothek, welche die Funktionen und das Modell für alle davon abgeleitet Projekte enthält. Darüber hinaus gibt es dann eine Bibliothek, welche pro Projekt angelegt ist und projektspezifische Funktionen enthält und das Projekt selbst.

Wenn nun das Modell geändert wird, soll natürlich alles kompiliert werden.

Bisher ist die CI so eingerichtet, daß die jeweilige Solution immer ALLE Teile als Projekt eingefügt hat und beim Build alle Teilprojekte vom Server ausgecheckt werden vor dem Kompilieren.

Die Idee war, anstelle der ganzen Teilprojekte nur jeweils die kompilierte DLL zu verwenden. Der Server könnte diese auch automatisch ermitteln und laden. Dann habe ich aber eventuell ein Problem bei der Verteilung.

Gibt es irgendwo ein HowTo oder Best Practice für eine gute Umsetzung der CI mit .NET? Oder wie habt ihr das so gelöst?

LG,

Sven
News:
27.04.2012
TiMeBaNDiT76 294 2 7
4 Antworten
4
Wir haben bei uns ein eigenes NuGet Repository angelegt.

Nachdem eine Bibliothek gebaut wurde, werden die Binaries im Repository zur Verfügung gestellt. Jedes Projekt kann sich die neuen Binaries dann über NuGet ziehen. Dieser Teil ist bei uns bisher noch nicht automatisiert (ist auch nicht so gewollt).

Man könnte natürlich auch eine Abhängigkeit definieren und danach die Projekte die diese Bibliothek benutzen neu bauen. Im Buildprozess müsste dann immer das NuGet Paket aktualisiert werden.
27.04.2012
PinBack 687 1 8
Ist es schwierig ein NuGet Repository einzurichten? Gibt es eine Anleitung irgendwo? Dann könnte ich mich dort mal einlesen und schauen, ob es für uns nützlich wäre.
TiMeBaNDiT76 27.04.2012
Ein NuGet Repository ist eigentlich nur ein Verzeichnis. Hier werden die NuGet packages hinkopiert. Ein Package wird mit dem Befehl NuGet Pack (http://docs.nuget.org/docs/reference/command-line-reference) erzeugt. Dazu braucht man nach eine Spezifikation (*.nuspec). Hier werden die Dateien und Abhängigkeiten definiert. Unter VS gibt man dann unter Optionen -> Package Manager -> Package Source das NuGet Repository Verzeichnis an.
PinBack 27.04.2012
Hallo PinBack,

das mit dem NuGet Repository war eine Super Idee. Teamcity unterstützt das sogar nativ. Allerdings werden alle Packages als Prerelease angezeigt. Das bekomme ich sicher noch in den Griff.
TiMeBaNDiT76 04.05.2012
1
Die Idee von PinBack find ich gut (+1 dafür). Das ist wesentlich leichtgewichtiger als ein dickes Artifact-Repository mit z.B. Maven oder Artifactory o.Ä. aufzusetzen. Wir haben das (Maven bzw. Artifactory Repository) mal in Erwägung gezogen, aber die Lernkurve sah auf den ersten und zweiten Blick nicht sehr flach aus...
Das grundsätzliche Problem ist ja, dass Du Deine Binaries der CI auch versioniert zur Verfügung stellen musst, um die Testaussage (bzgl. der binär bereitgestellten Lib) nicht zu invalidieren und die Nachvollziehbarkeit zu erhalten.
Was Dein TeamCity kann, weiß ich nicht (weil: kenn ich nicht), ich arbeite mit Jenkins. Für mich klingt das aber nach einer der ersten Fragen, die ich mir selbst einmal gestellt habe. Dabei habe ich erfahren dürfen, dass der nächste Schritt nach Continous Integration Continous Delivery ist. Das was Du ansprichst, kann man als initiale Frage in diese Richtung aufgreifen. In dieser Hinsicht bin ich selbst noch am Lernen und kann deshalb keine weitere Aussagen treffen.
Ich würde deshalb in Deiner Situation ganz pragmatisch den Weg des geringsten Widerstands einschlagen und PinBacks Vorschlag mit einem eigene NuGet Repository ist allemal einen Versuch wert.
27.04.2012
ffordermaier 8,4k 3 9
0
Die Idee mit dem NuGet war spitze. Jetzt stelle sich für mich die nächste Frage. Wie baue ich mein Build Chain richtig auf?

Was sollen denn eigentlich die Ziele sein? Ich habe eine Basisbibliothek mit allen Grundfunktionen (ORM, Spezielle Controls, Sonderfunktionen, etc) und dann Programme die darauf aufbauen.

Betrachtet man einmal die Basis, wäre doch folgendes erstrebenswert:

- Compile des Sourcecodes
- Prüfen auf Basis der Coding Styleguide
- Prüfen auf Duplikate und potentielle Qualitätsprobleme
- Tests durchführen
- ggf. auf verschiedenen Platformen
- Release erstellen
- Deploy

Sollten diese Schritte in einem Buildstep stehen, oder aufeinander aufbauen?
Was soll passieren, wenn ein Schritt fehlschlägt?

Betrachte ich nun die abhängige Software ,müßte es dann wie folgt aussehen:
- Nach erfolreicher Releaseerstellung und Deploy
- Neue Basisbibliothek ziehen
- Prüfen auf Basis der Coding Styleguide
- Prüfen auf Duplikate und potentielle Qualitätsprobleme
- Tests durchführen
- ggf. auf verschiedenen Platformen

ggf.
- Release erstellen
- Deploy

Wie habt ihr das so gelöst?

LG,

BaNDiT
04.05.2012
TiMeBaNDiT76 294 2 7
0
Schön das NuGet für dich funktioniert.

Die Schritte sind bei uns weitgehend wie du sie oben aufgeführt hast.

Bei uns wird der Buildvorgang bei Verletzung der Coding Styles und natürlich bei den UnitTests abgebrochen. Wir haben noch einen Schritt Codecoverage. Hier wird der Buildvorgang allerdings nicht abgebrochen.

Für die Software die ausgeliefert wird, werden zusätzlich noch Klick Tests mit TestComplete gemacht und eine Dokumentation erzeugt (eigene MsBuild-Tasks mit AsciiDoc).
Die Dokumentation muss dabei natürlich vor der Setuperstellung gemacht werden, da hier auch die eingebaute Onlinehilfe bzw. Pdf Dokumente erzeugt werden. Diese Dokumente werden mit dem Setup ausgeliefert.

Die Klick Test werden bei uns in eigenen Buildkonfigurationen gemacht und werden über die Dependencies angestoßen. Dort werden sich dann die benötigten Artifacts besorgt und auf einer VMWare getestet. Dieser Prozess ist allerdings recht aufwendig und wird über eigene MsBuild-Tasks gesteuert.

Wie die vielleicht schon gemerkt hast, kann man sich mit dem Thema recht lange aufhalten.
04.05.2012
PinBack 687 1 8
Da Du TestComplete erwähnst, wäre ich Dir sehr dankbar, wenn Du bzgl. der Fähigkeiten des verteilten Testens dieses Tools Deine Erfahrungen bei einer meiner Fragen teilen könntest.
http://codekicker.de/fragen/Verteiltes-Testen-Make-or-Buy

Besten Dank dafür.
ffordermaier 04.05.2012
Sind die einzelnen Build Schritte bei euch separat oder alles in einem?
TiMeBaNDiT76 04.05.2012
Wir benutzen für fast alles MsBuild-Targets. Dabei werden die einzelnen Targets meist in verschiedenen Build Steps aufgerufen.
Zum Beispiel:
- Build
- Test mit Codeanalyse
- Duplicate Finder
- Deploy
PinBack 04.05.2012

Stelle deine .net-Frage jetzt!
TOP TECHNOLOGIES CONSULTING GmbH