Automatisierte Builds mit VSTS, Teil 2
15.01.2018, 00:00 Uhr
Kontinuierlich releasen
Wie Sie eine Release-Pipeline mit integrierten Tests, Genehmigungsstufen sowie Rollback- und Bugfix-Optionen aufbauen.
Nach dem Build einer Software hört die Verantwortung des Entwicklers bekanntlich nicht auf. Die neu gebaute Software möchte gerne auf einer Reihe von Systemen installiert werden, in Entwicklungs-, Test- und Produktiv-Umgebung. Auch für diesen Prozess bietet der Team Foundation Server (TFS) Unterstützung an.
Im ersten Teil dieser Serie über Continuous Deployment mit dem TFS [1] stand das neue Build-System im Vordergrund. Die Fallstudie war wie folgt strukturiert: Aus einem Repository, das zwei APIs enthält, die sich eine gemeinsame Infrastruktur teilen, sind zwei Build-Definitionen entstanden. Jede Definition reagiert auf Änderungen eines APIs und löst in diesem Fall einen Build der betroffenen Komponenten aus. Auf diese Weise entstehen aus einem Repository je nach den getätigten Änderungen unterschiedliche Build-Artefakte. Somit wurde im Build-System getrennt, was vielleicht schon in zwei getrennte Repositories gehört hätte. Aufgrund der gemeinsamen Infrastruktur erschien es jedoch zunächst auch pragmatisch, alles zusammenzuhalten.
Jetzt 1 Monat kostenlos testen!
Sie wollen zukünftig auch von den Vorteilen eines plus-Abos profitieren? Werden Sie jetzt dotnetpro-plus-Kunde.
- + Digitales Kundenkonto,
- + Zugriff auf das digitale Heft,
- + Zugang zum digitalen Heftarchiv,
- + Auf Wunsch: Weekly Newsletter,
- + Sämtliche Codebeispiele im digitalen Heftarchiv verfügbar