Parallele Phasen in Release-Pipelines in Azure DevOps .
Parallele Phasen in einer Release-Pipeline werden jetzt gleichzeitig verarbeitet und in der Anwenderoberfläche der Pipeline DevOps in Echtzeit angezeigt. Mit Vorbereitstellungsbedingungen und Release-Gates für das Basissystem können Sie Change-Anforderungen erstellen, die Details aus parallelen Phasen enthalten.
Unterstützung paralleler Phasen des Basissystems für Azure DevOps
Organisationen verwenden parallele Phasen, um Releaseprozesse für Aufgaben, die parallel ausgeführt werden können, zu automatisieren und zu beschleunigen. Beispielsweise sind in eine Release-Pipeline mehrere Tools für Tests und Softwarequalität integriert, und die Aufgaben sind für die parallele Ausführung konfiguriert. Wenn nicht jeder Auftrag nacheinander ausgeführt wird, wird die Ausführung der Release-Pipeline erheblich beschleunigt.
ServiceNow DevOps unterstützt die Verarbeitung paralleler Phasen in Release-Pipelines und zeigt die Phasen in einer parallelen Ansicht in der Pipeline-UI von DevOps an. Tatsächlich repliziert die UI der Pipeline DevOps die GUI Azure DevOps in Echtzeit.
pipeline {
agent any
stages {
stage('Build') {
steps {
echo 'Building...'
// Your build steps here
}
}
stage('Test') {
parallel {
stage('Unit Tests') {
steps {
echo 'Running unit tests...'
// Your unit test steps here
}
}
stage('Integration Tests') {
steps {
echo 'Running integration tests...'
// Your integration test steps here
}
}
stage('Additional Tests') {
steps {
script {
parallel(
'Nested Stage 1': {
echo 'Running nested parallel stage 1...'
// Your nested parallel stage 1 steps here
},
'Nested Stage 2': {
echo 'Running nested parallel stage 2...'
// Your nested parallel stage 2 steps here
}
)
}
}
}
}
}
stage('Deploy') {
steps {
echo 'Deploying...'
snDevOpsChange changeRequestDetails: '{ "attributes": {"chg_model": "e55d0bfec343101035ae3f52c1d3ae49","standard_change_template"="563504cc47410200e90d87e8dee490e2"},"autoCloseChange": false}',changeStepTimeOut: 18000, pollingInterval: 60
// Your deploy steps here
}
}
}
}
ServiceNow® DevOps Release-Gate in Bedingungen vor der Bereitstellung, um Change-Anforderungen zu erstellen
- Commits
- Arbeitselemente
- Testzusammenfassungen
- Softwarequalitätszusammenfassung
- Artefaktversionen
Nachdem die Pipelineausführung die Verarbeitung der parallelen Phasen vor der Produktionsbereitstellungsphase abgeschlossen hat, wird automatisch eine Change-Anforderung erstellt und der Phase „In Produktion bereitstellen“ in der Ansicht Pipeline Ausführungen zugeordnet. Die Produktionsphase schließt die Verarbeitung ab, sobald die Change-Anforderung genehmigt wurde.
Klicken Sie in der Ansicht Pipeline-Ausführung der entsprechenden Pipeline auf den zugehörigen Link Pipeline-UI, um den Echtzeitstatus der Pipeline anzuzeigen, wie er in Azure DevOpsangezeigt wird. Die zugehörigen Artefaktdetails, die aus der Build-Pipeline bezogen werden, sowie Testergebnisse und Zusammenfassungsergebnisse zur Softwarequalität werden in der Pipeline-UI angezeigt.
Erstellungsreihenfolge für parallele Aufträge ändern
Auftragsinformationen von Azure werden zu folgenden Zeiten in ServiceNow empfangen:
- Nach Abschluss einer Phase.
- Wenn der Schritt „register-change“ ausgeführt wird.
Azure stellt Auftragsinformationen sequenziell basierend auf der Zeit der Auftragswarteschlange bereit, auch wenn Aufträge potenziell parallel ausgeführt werden. Wenn der Schritt „Registrieren – Ändern“ ausgeführt wird, während ein paralleler Auftrag in der Warteschlange noch nicht abgeschlossen ist, geht das System daher davon aus, dass der parallele Auftrag eine vorgelagerte Aufgabe ist, sodass der Change-Erstellungsprozess auf seinen Abschluss wartet. Benachrichtigungen über den Abschluss der Phase werden jedoch erst empfangen, wenn alle Aufträge, einschließlich des Auftrags „Registrierungsänderung“, abgeschlossen sind.
Dies führt zu einem Blockierungsszenario, in dem der Change-Prozess in ServiceNow auf den Abschluss des parallelen Auftrags wartet, während der parallele Auftrag auf die Benachrichtigung über den Abschluss der Phase wartet, die wiederum auf den Abschluss des Registrierungs-Change-Auftrags wartet.
Aufgrund dieses Stillstands ist der Azure-Pipeline-Auftrag zum Zeitpunkt der Erstellung des Change bereits fehlgeschlagen, was in der Ereignis-API zum Fehler 500 führt. Durch erneutes Ausführen des Auftrags wird das Problem behoben, da die zuvor in der Warteschlange befindlichen parallelen Aufträge als abgeschlossen markiert werden.
Überlegungen zum Upgrade
- Die Spalte „Vorgelagerte Ausführung “ in der Tabelle „Aufgabenausführungen“ wird bei Neuinstallationen nicht angezeigt. Alle Anpassungen, die Sie vor dem Upgrade mithilfe der Spalte Vorgelagerte Ausführung vorgenommen haben, sind nicht betroffen.
- Wenn Phasen parallel ausgeführt werden, darf eine Change-Anforderung nicht der erste Auftrag in einer Phase sein.
- Nach dem Upgrade verarbeiten Pipelineausführungen neuer Releases parallele Phasen gleichzeitig und zeigen parallele Phasen und zugehörige Details in der Pipeline-UI an. Azure DevOps -Release-Pipelines, die bereits vor dem Upgrade ausgeführt und in ServiceNow DevOps gespeichert wurden, bleiben davon betroffen und zeigen weiterhin parallele Phasen (die bereits ausgeführt und beibehalten wurden) in ServiceNow DevOps seriell an.
- Wenn das Releasegate ServiceNow DevOps vor der Bereitstellung in mehr als einer Startphase in einer Releasepipeline mit mehreren Startphasen aktiviert ist, kann dies zu Ausführungen in mehreren Pipelines führen.