Deployment aus Git
Verbinde ein Repository und lass klickops das Image bauen. Dann wird aus einem Push ein Deployment.
Auf dieser Seite
Was das ist
klickops fängt beim Container-Image an. Ein verbundenes Repository ergänzt den Schritt davor: klickops klont deinen Code, baut ein Image, schiebt es in seine eigene Registry und rollt es aus. Aus einem Push auf den gewählten Branch wird eine neue laufende Version.
Ein CI-System ist das nicht. Es gibt keine Pipelines, keine Stages, keine Build-Matrix und keinen Ort, an dem deine Tests laufen. Brauchst du das, behalt dein CI und lass es ein Image schieben. klickops rollt dieses genauso gern aus.
Wann du das brauchst
- Du hast ein Repository und kein Image und willst keinen Build-Workflow pflegen.
- Ein Push auf
mainsoll ohne Handgriff in der Produktion landen. - Du willst pro Pull Request eine Umgebung zum Anschauen, bevor du mergst.
Braucht dein Build Secrets, eigene Toolchains oder eine Testsuite, die zuerst grün sein muss, gehört das in dein CI. Bau dort, schieb das Image, und zeig klickops darauf.
Ein Repository verbinden
- Geh in der Organisation auf Repos und verbinde deinen Anbieter. GitHub läuft über eine App-Installation, klickops sieht also nie ein Passwort.
- Wähl das Repository und seinen Default-Branch.
- klickops schaut sich den Code an und schlägt vor, wie er gebaut wird. Übernimm den Vorschlag oder überschreib ihn.
Ab dann steht das Repository jedem Projekt der Organisation zur Verfügung. Eine zweite App aus demselben Code braucht keine zweite Verbindung.
Wie gebaut wird
| Builder | Wann er greift | Was er braucht |
|---|---|---|
| Buildpacks | Standard. Kein Dockerfile im Repository. | Nichts. Die Sprache wird erkannt und ein Produktions-Image entsteht. |
| Dockerfile | Ein Dockerfile liegt da, oder du wählst es. | Dein Dockerfile. klickops baut es so, wie es dasteht. |
Builds laufen im Cluster, isoliert und ohne Root. Das Ergebnis landet in der Registry, die klickops betreibt. Dein Image verlässt die Plattform also nicht, ausser du hast eine eigene Registry eingerichtet.
Einen Build verfolgen
Die Seite Builds eines Projekts listet jeden Build mit Status und vollem Log. Ein fehlgeschlagener Build lässt die laufende Version in Ruhe. Genau das ist die nützliche Eigenschaft: Ein kaputter Commit reisst die Produktion nicht mit.
Einstellungen im Überblick
| Einstellung | Standard | Was sie bewirkt |
|---|---|---|
| Branch | der Default des Repositories | Von welchem Branch ein Push ausrollt. |
| Subpath | Wurzel des Repositories | Baut aus einem Unterverzeichnis, für ein Monorepo. |
| Builder | buildpacks | Wie das Image entsteht. |
| Previews | aus | Baut und rollt pro Pull Request eine Umgebung aus und räumt sie beim Schliessen ab. |
Grenzen und Fallstricke
- Ein Push rollt den gewählten Branch aus und sonst nichts. Arbeit auf anderen Branches baut nichts, solange Previews aus sind.
- Der erste Build ist der langsame. Spätere Builds nutzen Layer wieder und sind deutlich schneller.
- Build-Logs hängen am Build. Ist ein Build aus der Liste verschwunden, ist sein Log mit weg.
- Previews kosten, was sie laufen lassen. Jeder offene Pull Request ist eine laufende Umgebung. Ein Repository mit zwanzig davon sind zwanzig Umgebungen.