Verantwortlichkeiten von Build Script und Build Server

Ich benötige einige Erläuterungen zu den Verantwortlichkeiten des Build-Skripts und des Build-Servers.

Ich habe mehrere Artikel im Internet über kontinuierliche Integration und Builds gelesen. Einschließlich

Und ich hatte ein Gespräch mit meinem Berater über den Erstellungsprozess unserer Software. Weil er sehr erfahren ist, vertraue ich seinen Aussagen, aber ich war verwirrt.

Nach meinem Verständnis sollte nach meiner Recherche (und bitte korrigieren Sie mich hier, da es das ist, wonach ich frage) das Ideal lauten:

Jedes Projekt hat sein Build-Skript
Dieses Skript erstellt das Projekt
Dieses Skript stellt sicher, dass die Abhängigkeiten zuvor erstellt wurden

Da es sich bei Abhängigkeiten um andere Projekte handeln kann, entsteht mit einem eigenen Build-Skript eine baumartige Hierarchie. Möglicherweise gibt es ein Top-Build-Skript, das alle Projekte und Anwendungen erstellt.

Die Verantwortlichkeiten des Build-Servers sind jedoch:

Überprüfen Sie das Repository
Löse den Build aus
Triggertests und andere QS-Tools
stelle das Artefakt zur Verfügung

Dies kann manuell, nachts oder bei jeder Änderung des Repositorys ausgelöst werden

Die Ziele meines Beraters sind, wie ich sie verstehe, dass ein Build-Skript zu unflexibel und nicht wartbar ist (abgesehen von der Tatsache, dass es sehr lange dauern würde, ein Skript für unsere alte Codebasis zu erstellen). Außerdem sollte der Build-Server die Abhängigkeiten beibehalten, um beispielsweise ältere Abhängigkeiten zu verwenden, wenn das Erstellen neuer Abhängigkeiten fehlschlägt. Und insbesondere, Antweil es das konkrete Thema war, nicht in der Lage ist, alle Arten von Technologien zu erstellen, die in der Codebasis verwendet werden, und nicht in der Lage ist, die Abhängigkeiten aufrechtzuerhalten.

Können Sie bitte die Ziele erläutern und die Zuständigkeiten klären?

version-control continuous-integration builds

— Angelo.Hannes
quelle

Soweit dies eine gute Frage ist und beantwortet wird (ich werde es später tun, wenn ich Zeit habe, und sie wurde noch nicht beantwortet): Sie sollten wirklich zurückgehen und sich von Ihrem Berater Klarheit verschaffen. Verwirrt zu sein, nachdem Sie mit jemandem gesprochen haben, der Ihre Leistung bewertet, ist ein Rezept für eine Katastrophe und ein Hinweis darauf, dass er nicht angemessen mit Ihnen kommuniziert (oder Sie nicht aktiv zuhören, aber dies scheint nicht der Fall zu sein) Hier).

— Steven Evers

@ Angelo.Hannes Ich denke du hast alle wichtigen Punkte getroffen. Können Sie genauer erklären, worüber Sie verwirrt sind?

— M. Dudley

@SteveEvers Nun, wie ich gerade einige Einführungen zu diesem Thema gelesen habe, wollte ich zuerst mein Wissen darüber erweitern. Ich werde dieses Thema dann sicher wieder aufgreifen. Deshalb würde ich mich sehr über eine Antwort von Ihnen freuen.

— Angelo.Hannes

@ M.Dudley Wie gesagt, ich bin mir nicht sicher, welche Aufgaben wohin gehen. Und ob ein Build-Skript für die gesamte Software der richtige Weg ist.

— Angelo.Hannes

Diese Dinge sind orthogonal:

Das Build-Skript ist der Mechanismus, der beim Aufrufen des frisch ausgecheckten Quellbaums eine vollständige Erstellung der erforderlichen Ziele und Abhängigkeiten liefert. Wenn Sie ein Makefile oder einen geeigneten Aufruf von MSBuild, Ant, Maven oder Scons haben, kann dies einfach "Alles schaffen" sein. Wenn Sie über eine komplexe Hierarchie von Abhängigkeiten oder verwandten Projekten verfügen, ist Ihr "Build-Skript" möglicherweise eine Datei der obersten Ebene, die jede einzelne Datei nacheinander aufruft und den Erfolg überprüft, während Sie fortfahren.

Das Erstellungsskript ist nur ein Skript von möglicherweise vielen - Auschecken, Erstellen, Testen, Packen - aber Sie können einen All-in-One-Mechanismus verwenden, der von Befehlszeilenparametern gesteuert wird - dies hängt von Ihrer Umgebung ab.

Der Build- Server bzw. Continuous Integration Server ist der Automatisierungsmechanismus, der für das Planen / Auslösen, Überwachen und Melden der Prüfung -> Build -> Test -> Paket -> Phase -> Bereitstellen der Pipeline verantwortlich ist. Sie könnten cron / Task Scheduler verwenden, wenn Sie nichts Feineres zur Hand hätten, aber es gibt jetzt viele hervorragende Tools wie Jenkins, Cruise Control, TeamCity usw.

Es ist wichtig, dass Sie einen Build aufrufen können, ohne den CI-Server zu verwenden, falls dieser ausgelastet / offline / nicht erreichbar / anderweitig nicht verfügbar ist. Daher muss die Logik zum Abrufen des Builds / Tests / der ausgeführten Aktionen außerhalb des CI-Servers liegen CI-System, kann aber von ihm aufgerufen werden, parametrisiert nach Zweig / Build-Typ / Version / Architektur usw.

— JBRWilkinson
quelle