Das quelloffene Continuous-Integration-System Concourse ist am 29. März 2016 in Version 1.0 erschienen. Die offiziellen Release Notes zu Concourse 1.0 nennen eine stabilere Release-Politik, eine eigenständige Binärdatei und mehrere Änderungen an Build- und Testabläufen.
Concourse beschreibt Build-Prozesse als Pipelines, die Ressourcen abrufen, Aufgaben ausführen und Ergebnisse weiterreichen. Für Spiele- und Softwareteams ist dieser Ansatz vor allem bei automatisierten Builds, Tests und der Verarbeitung großer Projektdateien interessant.
Eigenständige Binärdatei und neue Steps
Mit Version 1.0 ersetzte Concourse die ältere Job-Konfiguration durch Steps. Zusätzlich stand das System erstmals als eigenständige Binärdatei zur Verfügung. Die Installation ließ sich dadurch von einer vollständigen Entwicklungsumgebung trennen, was den Betrieb auf Build-Servern vereinfachte.
Die Release Notes nennen außerdem Caching für Ressourcen und eine effizientere Weitergabe von Artefakten zwischen den einzelnen Schritten eines Build-Plans. Das reduziert wiederholte Abrufe und hält Abhängigkeiten zwischen Aufgaben sichtbar. Gerade bei Projekten mit großen Binärdateien und häufigen Testläufen ist diese Trennung relevant.
Pipelines und eigene Ressourcentypen
Eine Concourse-Installation konnte mehrere Pipelines dynamisch verwalten. GitHub-Authentifizierung kam als weitere Funktion hinzu. Eigene Ressourcentypen ließen sich direkt in einer Pipeline definieren, ohne die Worker erneut konfigurieren zu müssen.
Die Version 1.0 bündelte damit Werkzeuge für reproduzierbare Build- und Testketten. In der damaligen Werkzeuglandschaft verfolgte auch GitLab 8.6 den Ausbau integrierter Continuous Integration. Für technische Teams lag der Nutzen beider Ansätze in der engeren Verbindung von Quellcode, automatisierten Prüfungen und erzeugten Artefakten.