06 / 07Deployen
Geprüfte Änderungen. Reproduzierbare Umgebungen. Kontrollierte Deployments und Wiederherstellungspfade.
Deployen ist der Weg, den eine Änderung vom Entwickler bis in Ihr Produktivsystem nimmt. Wir halten diesen Weg in Git, geprüft und reproduzierbar.
- Prüfen
- Bauen
- Deployen
- Beobachten
Leistungsübersicht
Wann Sie es brauchen
- Änderungen werden direkt im Produktivsystem gemacht, und niemand kann sagen, was sich letzte Woche geändert hat.
- Eine Korrektur funktioniert im Test und scheitert im Produktivsystem, weil sich die beiden Umgebungen unterscheiden.
- Eine einzige Person weiß, wie deployt wird.
- Nach einem schlechten Release gibt es keinen vereinbarten Weg zurück.
- Ein neuer CTO oder ein Prüfer fragt, wer eine Änderung freigegeben hat, und es gibt keinen Nachweis.
Plattform
Deployen.
Ein neuer Bericht, eine reparierte Integration, ein Versionsupgrade: Jede Änderung muss im Produktivsystem ankommen, ohne zu stören, was bereits funktioniert.
Ein Git-Repository hält den Sollzustand des Systems: den Code, die Konfiguration und die Beschreibung der Umgebungen. Jede Änderung wird dort geprüft, und die Umgebungen werden daraus aufgebaut.
Das Ergebnis ist eine Umgebung, die sich reproduzieren lässt, und keine, an die sich jemand erinnern muss.
Was wir tun
- GitOps: Git als Quelle des Sollzustands, mit Änderungen, die vor dem Mergen geprüft werden.
- Reproduzierbare Umgebungen für Entwicklung, Staging und Produktivbetrieb.
- CI/CD für Build und Deployment.
- Kontrollierte Deployments, mit einem Wiederherstellungspfad.
- Container, und Kubernetes, wo es passt.
- Observability, damit die Wirkung eines Releases sichtbar ist.
Wie es zusammenhängt
Wann eine Änderung live geht, ist eine Geschäftsentscheidung. Ein Release mitten im Monatsabschluss oder in der versandstärksten Woche ist ein Risiko, das niemand braucht. Über den Zeitpunkt entscheiden deshalb die Menschen, die diese Bereiche verantworten. Die Bereiche stehen auf der Seite Odoo.
Änderungen auf der Anwendungsebene nehmen diesen Weg. Eine Anpassung kommt aus Bauen & anpassen, eine Integration aus Verbinden, ein Workflow aus Automatisieren, eine neue Version aus Migrieren & upgraden.
Auf der Plattformebene werden die Umgebungen, in die eine Änderung deployt wird, in Betreiben betrieben. Ein System, in dem Änderungen seit Langem von Hand im Produktivsystem gemacht werden, ist ein Fall für Retten.
Wann Sie es brauchen
- Änderungen werden direkt im Produktivsystem gemacht, und niemand kann sagen, was sich letzte Woche geändert hat.
- Eine Korrektur funktioniert im Test und scheitert im Produktivsystem, weil sich die beiden Umgebungen unterscheiden.
- Eine einzige Person weiß, wie deployt wird.
- Nach einem schlechten Release gibt es keinen vereinbarten Weg zurück.
- Ein neuer CTO oder ein Prüfer fragt, wer eine Änderung freigegeben hat, und es gibt keinen Nachweis.
Sagen Sie uns, wie eine Änderung heute in Ihr Produktivsystem gelangt.