devops24x7

Leistungen

CI auf autoskalierenden Runnern: GitLab CI oder GitHub Actions, x86 und ARM

Wann Sie das brauchen

Builds warten stundenlang in der Warteschlange, statische Runner sind von Hand konfiguriert und laufen voll, der Artefaktspeicher läuft über und die Kosten der CI sind undurchsichtig. Oder Sie wechseln von einer CI zur anderen und wollen es von Anfang an richtig machen.

Was Sie bekommen

Runner-Flotten auf AWS, skaliert nach Warteschlange, x86 und ARM getrennt, Spot wo Builds es vertragen, als Code beschrieben und per GitOps ausgerollt. Build-Cache und Artefakte im Objektspeicher mit Aufbewahrungsregeln. Für GitHub Actions: OIDC zu AWS statt statischer Schlüssel. Ein einheitlicher Deploy-Flow über Repositories hinweg. Für selbst gehostetes GitLab: eine Upgrade-Prozedur für den Server mit Prüfung der Hintergrundmigrationen, Aufbewahrung der CI-Historie, Image-Aufbewahrungsregeln in ECR. Ein Migrationsplan mit einer Testwoche an echten Jobs und stufenweiser Abschaltung der alten Runner.

Typische Dauer

Flotten und Migration des ersten Projekts: 3–5 Wochen. Vollständige Abschaltung der alten Runner je nach Zahl der Projekte, meist 6–10 Wochen. Schätzung nach einem ersten Gespräch.

Zugehörige Arbeiten

Arbeitsbeispiele 2 und 6.

Kontakt