Quelle: dotnetpro
Build- und Release-Pipeline mit Azure DevOps, Teil 2 13.01.2020, 00:00 Uhr

Der Azure-Lieferdienst++

Der erste Teil dieser Serie klärte die Grundlagen der Konfiguration einer rudimentären Pipeline. In diesem Teil werden komplexe mehrstufige Pipelines betrachtet.
Einfache Pipelines, die nur ein Artefakt erzeugen, wie im ersten Teil dieser Serie [1] beschrieben, kommen in der Praxis eher selten vor. Oft haben Pipelines viele verschiedene Schritte, um sehr unterschiedliche Qualitätsziele für das jeweilige Softwaresystem zu etablieren. Dazu gehört in der ­Regel auch eine Vielzahl an automatischen und manuellen Tests, so zum Beispiel Unit-Tests, Integrationstests und Coded-UI-Tests. Hierbei entsteht allerdings die Herausforderung, dass vor allem Integrations- und Coded-UI-Tests von den Rahmenbedingungen des ausführenden Systems abhängig sind. Beispielsweise verhalten sich verschiedene Versionen eines Browsers unterschiedlich, wodurch es unumgänglich ist, Tests auch auf diesen unterschiedlichen Browsern durchzuführen. Erlauben die Browser dabei keine Parallel­installation in der gleichen Betriebssysteminstanz oder sollen die Tests parallelisiert werden, so ist es nötig, die Tests in unterschiedlichen Umgebungen auszuführen.
Für eine solche parallele Ausführung sind mehrere Agents auf verschiedenen Servern notwendig. Ein Agent übernimmt hierbei das Erzeugen der Artefakte und das Ausführen der Unit-Tests. Letztere sollten ja voneinander und vom umgebenden System entkoppelt sowie schnell ausführbar sein. Die Inte­grations- und Coded-UI-Tests werden wiederum auf die anderen Agents verteilt und damit parallel auf unterschiedlichen Systemen ausgeführt. Die Server der Test-Agents müssen entsprechend den zu testenden Umgebungen konfiguriert sein.

dotnetpro

Sie wollen zukünftig auch von den Vorteilen eines plus-Abos profitieren? Werden Sie jetzt dotnetpro-plus-Kunde
  • 2 Monate Gratis testen
  • Über 4.000 qualifizierte Fachartikel
  • Auf jedem Gerät verfügbar