Ausgabe eines in einem anderen enthaltenen Builds

Question

Was ist der richtige Weg, um eine Ausgabe eines Builds als Binärin in einem anderen Build aufzunehmen?

Nehmen wir an, ich habe eine Lösung namens CompanyName.domain (meine Domänenschicht). Ich habe es als Build eingerichtet und es baut jeden Abend auf.

Jetzt möchte ich eine Lösung namens sonproject.web hinzufügen. Und ich möchte das Binärding aus FirmaName.domin in einen Binärordner auf Peer -Niveau mit meiner Lösung einbeziehen. Dann wird das Projekt einigeProjects.web auf Binärdateien CompanyName.domain.dll funktionieren.

Was sind Best Practices dafür? Ich kenne jemanden, der sagte, dass er versucht hat, dies mit Verzweigungen zu tun. Ich bin ein totaler "Quellangesteuerung" Neuling. Aber etwas daran klingt falsch.

Answer 1

Genau wie Daryl verwenden wir einen "Binärdateien" -Fordner, aus dem wir Binärdateien verweisen. Unsere "Bibliotheken" bauen nur die Ergebnisse in den Standort von Binärdateien. Wenn wir also die Bibliotheken aktualisieren möchten, überprüfen wir einfach die Binärdateien, erstellen und überprüfen sie erneut.

Auf diese Weise können wir alle unsere internen Bibliotheken (sowie alle von uns verwendeten Bibliotheken von Drittanbietern) von einem einzelnen standardisierten Ort teilen, und alle unsere Bibliotheken können vorgefertigt sein, und speichern unsere Entwickler, wenn sie sie nicht tatsächlich ändern, in der libs.

Achten Sie darauf, dass Sie nur die Veröffentlichung von Builds Ihrer Bibliotheken referenzieren (die einzige Ausnahme, die wir dazu haben, dass wir eine Bibliothek mit Debugging -Helfern haben, die nur in Debug -Builds zusammengestellt sind, und wir müssen auf die Debug -Version von IT verweisen, sonst ist alle unser Debuggen. aus dem Programm auch in Debug -Builds zusammengestellt!)

Ein letzter Hinweis: Verzweigungen vermeiden, es sei denn, es gibt keine vernünftige Alternative.

Answer 2

Mein Unternehmen erstellt dies, indem er einen "Referenz -Ordner" erstellt, um alle .DLL -Dateien zu halten, die zum Erstellen extern referenzierter Baugruppen erforderlich sind, da der Bin -Ordner nicht unter der Quellensteuerung gespeichert wird.

Answer 3

Wir benutzen das TFS -Abhängigkeits -Replikator, die Dateien nach einem Projekt zu jedem Projekt in TFS kopieren können. Es hat keine wirklich großartige Dokumentation, aber es scheint das zu tun, was es nach dem Einrichten des Einrichtens soll.

Der Blog -Beitrag Implementierung der Abhängigkeitsreplikation mit dem TFS -Team Build empfiehlt, ein Verzweigungsszenario einzurichten, um die Verfolgung zu unterstützen, welche Projekte die Abhängigkeiten verwenden, was auch für mich sinnvoll ist.

Answer 4

Mein Prozess ähnelt dem der anderen Poster.

Angenommen, ich habe zwei Projekte, nennen Sie sie CoreProject und AppProject. CoreProject wird geteilt. AppProject verfügt über einen Ordner namens SharedBinaries. Hier zeigen alle Versammlungsreferenzen.

Mein TFSBuild -Skript für CoreProject ist so konfiguriert, dass sie Folgendes ausführen:

-Bekomme das neuste

-Build Drop to Drop Zone (so etwas wie Server Dropzone coreProjectBuildnameAnnumber)

-Drop wird in einen Ordner in der Drop -Zone kopiert (so etwas wie Server Dropzone letztes coreProject)

Das TFSBuild -Skript für AppProject ist so konfiguriert, dass sie Folgendes ausführen:

-Bekomme das neuste

-Überprüfen Sie Dateien im Ordner SharedBinaries

-Copy -Dateien von Server Dropzone letztes coreProject

-Bauen

-Drop zu Drop Zone (so etwas wie Server Dropzone AppProjectBuildnameAnnumber)

-Wenn der Build erfolgreich ist, wird der Build in eine Ordner -Drop -Zone (so etwas wie Server Dropzone letztes AppProject) kopiert und die Dateien in SharedBinaries werden eingecheckt in

-Wenn der Build fehlschlägt, haben die in SharedBinaries kopierten Dateien das Auschecken rückgängig gemacht.

Ich habe festgestellt, dass dies wirklich gut funktioniert. AppProject baut immer mit den aktuellsten Bits von CoreProject auf, sodass wir sofort wissen, ob sich eine Bruchänderung gibt. Durch die Untersuchung von Teilen in TFS kann ich eine bestimmte Version erhalten und den Code mit denselben DLLs von CoreProject ausführen, die zu diesem Zeitpunkt verwendet wurden. Außerdem muss ich nur noch das Neueste bekommen und meine lokale Maschine baut auch mit den neuesten Bits auf.