Was dabei passiert
- Abhängigkeiten holen: die Pakete, die in
package.json,requirements.txtodergo.modstehen. - Übersetzen: TypeScript zu JavaScript, Sass zu CSS, Go zu einer ausführbaren Datei.
- Zusammenpacken: alles Nötige in ein Abbild, alles Unnötige weglassen.
Wichtig ist der letzte Punkt: Ein Abbild, das den ganzen Quelltext, Testdaten und den Paketspeicher enthält, ist schnell zehnmal so groß wie nötig – und jedes Deployment dauert entsprechend länger.
Reproduzierbar bauen
Derselbe Quelltext soll morgen dasselbe Ergebnis liefern wie heute. Dafür braucht es eine
Sperrdatei (package-lock.json, poetry.lock, go.sum), die die genauen
Versionen festhält. Ohne sie holt der Build heute eine andere Fassung einer Bibliothek als gestern – und
der Fehler, den niemand erklären kann, ist fertig.
Bauzeit verkürzen
- Zwischenspeicher nutzen: Abhängigkeiten ändern sich selten. Werden sie in einem eigenen Schritt installiert, wird dieser Schritt beim nächsten Mal übersprungen.
- Mehrstufig bauen: Im ersten Abschnitt bauen, im zweiten nur das Ergebnis übernehmen. Compiler und Entwicklungswerkzeuge bleiben draußen.
- Unnötiges ausschließen: Tests, Beispieldaten und Dokumentation gehören nicht ins Abbild.
Bei Branchway wird der Zwischenspeicher je Team gehalten: Der zweite Build desselben Projekts ist deutlich schneller als der erste, weil unveränderte Schichten wiederverwendet werden.
Häufige Fragen
Warum dauert mein erster Build so lange?
Weil noch nichts im Zwischenspeicher liegt und alle Abhängigkeiten geholt werden müssen. Ab dem zweiten Mal geht es schneller, solange sich die Abhängigkeiten nicht ändern.
Kann ich lokal genauso bauen wie auf dem Server?
Mit einem eigenen Dockerfile ja – dann ist der Build überall derselbe. Das ist der Hauptgrund, eines zu schreiben.