Mehrere Builds in einem Release kombinieren

Question

Wir verwenden VSTS für unsere CI/CD-Umgebung. In unserem Projekt haben wir mehrere Teile, wie Datenbank und Frontend1, die einen separaten Ordner in unserem Repository:

src/ 
    Database 
    Frontend1 
    ... 

ich einen separaten Build für jede der Komponenten unseres Projekts erstellt haben, die ausgelöst werden, wenn es ändert in den entsprechenden Unterordner geschoben. Ich möchte, dass diese Trennung die Version jeder Komponente einfach kontrolliert und überprüft.

Database --> Build Database 
Frontend1 --> Build Frontend1 

Mit dieser Konfiguration gibt es zwei, wenn ich für Database und Frontend1 mit einem einzigen Commit in Änderungen überprüfen ausgelöst Builds.

Zusätzlich habe ich eine einzelne Version mit beiden verknüpften Artefakten konfiguriert. Die Freigabe wird auch für jeden Build ausgelöst.

Das Problem ist jetzt, dass, wenn ich eine Änderung für die Database und Frontend1 einchecke, beide Builds ausgelöst werden und nach jedem Build gibt es auch eine Freigabe ausgelöst. Das heißt, ich habe zwei Versionen für denselben Commit. Ich möchte achive dass es nur eine Version ist, die vereint baut:

Database --> Build Database | 
           | --> Release Database and Frontend1 
Frontend1 --> Builds Frontend1 | 

Gibt es eine Möglichkeit, eine solche Konfiguration zu achive?

Answer 1

Endlich habe ich eine Lösung für mein Problem gefunden. Ich habe eine VSTS Aufgabe geschaffen, die ein Etikett mit dem aktuellen Build hinzufügen, wenn es kein anderer Build-Lauf ist/Warteschlange:

[CmdletBinding()] 
param(
    [string] $teamfoundationCollectionUri = $env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI, 
    [string] $teamfoundationProject= $env:SYSTEM_TEAMPROJECT, 
    [string] $accessToken = "Bearer $env:SYSTEM_ACCESSTOKEN", 
    [int]  $currentBuildId = $Env:BUILD_BUILDID, 
    [string] $tag 
) 

if(!$tag) 
{ 
    $tag = Get-VstsInput -Name "tag" 
} 

$buildInformationUrl = "$teamfoundationCollectionUri$teamfoundationProject/_apis/build/builds/$currentBuildId" 

Write-Host "Loading build information: " $buildInformationUrl 
$buildInformationResponse = Invoke-RestMethod -uri $buildInformationUrl -Headers @{Authorization = "$accessToken"} 

$buildSourceVersion = $buildInformationResponse.sourceVersion 

$openBuildsUrl = "$teamfoundationCollectionUri$teamfoundationProject/_apis/build/builds?statusFilter=inProgress,notStarted" 

Write-Host "Requesting open builds: " $openBuildsUrl 
$builds = Invoke-RestMethod -uri $openBuildsUrl -Headers @{Authorization = "$accessToken"} 


$otherBuildForCommitIsRunning = $false 
ForEach($currentBuild in $builds.value) 
{ 
    if($currentBuild.id -eq $currentBuildId) { 

     Write-Host "Build with Id " $currentBuild.id " skipped" 
     continue; 
    } 

    if($currentBuild.sourceVersion -eq $buildSourceVersion) { 
     Write-Host "Found other open build: " $currentBuild.id 

     $otherBuildForCommitIsRunning = $true 
    } 
} 

if($otherBuildForCommitIsRunning -eq $false) { 
    Write-Host "Tagging build with "$tag 
    Write-Host "##vso[build.addbuildtag]$tag" 
} 

Zusätzlich habe ich einen Tag Bedingung für die Freigabe Trigger hinzugefügt:

Answer 2

Gegenwärtig können Sie nicht wirklich erreichen, was Sie tun möchten. Eine Version kann so konfiguriert werden, dass mehrere Artefaktquellen (in diesem Fall Builds) ausgelöst werden. Eine Freigabe wird jedoch immer dann ausgelöst, wenn eines dieser Artefakte aktualisiert wird. Wenn Sie eine Änderung haben, die zwei Builds auslöst, erhalten Sie zwei Releases.

Sie können jedoch Artefaktbedingungen für eine bestimmte Umgebung verwenden, um nur eine Bereitstellung dieser Umgebung auszulösen.

So würden Sie Ihre Release-Definition in zwei Umgebungen brechen:

 |-Dev-Database -> QA-Database -> etc 
Start-|    
     |-Dev-FrontEnd -> QA-FrontEnd -> etc 

Der Artefakt Zustand würde sicherstellen, dass Sie nur eine Freigabe der Datenbank für Datenbankänderungen erhalten, und eine Freigabe des vorderen Endes für Front Änderungen beenden

Ich möchte, dass es einen "Batch" -Modus gibt, wo es schlau genug ist, mehrere Builds für dasselbe Commit zu sehen und darauf zu warten, dass alle fertig sind, aber so etwas gibt es leider nicht.