Laden...

Azure DevOps - Buildpipeline: nur das Projekt mit Änderung in einer Solution bauen und releasen

Erstellt von corax02 vor 3 Jahren Letzter Beitrag vor 3 Jahren 734 Views
C
corax02 Themenstarter:in
14 Beiträge seit 2008
vor 3 Jahren
Azure DevOps - Buildpipeline: nur das Projekt mit Änderung in einer Solution bauen und releasen

Hallo,
ich hab die Aufgabe bekommen, auf unseren lokalen Azure DevOps Server Build- sowie Release Pipelines einzurichten. Generell funktionieren die Pipelines für ein Großteil der Projekte. An einem Projekt scheitere ich aber gerade und benötige mal einen Schubs in die richtige Richtung.

Gegeben ist eine Solution, welche mehrere Projektmappen enthält. Dabei soll jede Projektmappe für sich selber gebaut werden. (Diesen Part habe ich schon, und funktioniertiert soweit).
An dieser Struktur kann ich so auch nichts ändern, wodurch ich aber nun dennoch scheitere:

Es soll nur das Projekt gebaut und released werden, für das auch Änderungen hoch geladen wurden. Aktuell habe ich den Effekt, dass alle Projekte gebaut und released werden, auch wenn nur in einem Projekt Änderungen vorgenommen werden. Ich bin nun mit meinem Latein am Ende und hoffe auf eine zündende Idee, wie ich meine Build- und Release Pipeline aufbauen muss, dass es so funktioniert.
Meine Idee, jedes Projekt in ein separates Branch zu packen, wurde abgelehnt.

Profis haben die Titanic gebaut, Amateure die Arche

16.806 Beiträge seit 2008
vor 3 Jahren

Meine Idee, jedes Projekt in ein separates Branch zu packen, wurde abgelehnt.

Das ist auch keine gute Idee und wurde zurecht abgelehnt.
Dafür sind Branches nicht gedacht.

Letzten Endes ist es aus MSBuild-Sicht nicht möglich nur gewisse Teile einer Solution zu bauen; wenn dann muss man sich ganz von dem Solution-Ansatz verabschieden und dann selektiert bauen.

Prinzipiell ist die Grundidee, dass der gesamte Inhalt eines Repositories gebaut und released wird.
Wenn man davon abweicht, dann sollte das gute Gründe haben. Oft ist ein Splitten einer Solution die bessere Wahl als das selektierte Bauen der Inhalte.

Die letzten Monate kamen ja die sogenannten Mono-Repositories in den Hype: das ist letzten Endes nichts anderes als ein selektiertes bauen.
Creating Monorepo Pipelines in Azure DevOps

Mono Repos haben aber gewisse Nachteile; es gibt hier auch den Spruch "friends dont let friends use mono repos" - könnte aber das sein, was Du willst.
Ob das am Ende aber eine gute Idee ist; das müsst ihr selbst evaluieren - ich bin auch kein Freund davon und seh mehr Nachteile als Vorteile; vor allem was die Aspekte Traceability und Organisation betrifft.

C
corax02 Themenstarter:in
14 Beiträge seit 2008
vor 3 Jahren

vielen Dank für die schnelle Antwort. Ich schau mir mal den Link an und geb ne Rückmeldung..

-edit-

Wie versprochen, meine Rückmeldung:
In der Tat entspricht der Inhalt des Links ziemlich genau dem, was ich benötige. Ich muss da nur noch ein wenig basteln, da diese Anleitung sich auf das Azure Git bezieht und wir hier ein hausinternes GitLab nutzen. Da werden die YAML Dateien in den Projekten nicht erkannt.

Profis haben die Titanic gebaut, Amateure die Arche