Die Probleme von Staging
- Pre-Live ist nicht identisch mit der Produktion
- Es entsteht eine Release-Warteschlange
- Releases werden zu groß
- Es gibt zu wenig Ownership für Änderungen
- Man lässt zu, dass der Prozess Verantwortung ersetzt
Wie Squeaky shippt
- Nur Dinge mergen, die livefähig sind: Änderungen werden in der lokalen Entwicklungsumgebung gründlich getestet
- Eine Flat-Branching-Strategie verwenden: Wenn ein Feature bereit zum Mergen ist, wird es gerebased und getestet. Bei Problemen wird nach vorn korrigiert
- Für Features mit hohem Risiko immer Feature Flags verwenden
- Manuelle Deployments: Nach Änderungen wird kontinuierlich überwacht. Monitoring/Logging/Alarme werden durchgängig eingesetzt. Blue/Green-Deployment
Fazit
- Wenn man für echtes CI/CD auf eine Staging-Umgebung verzichtet, kann man eine andere Denkweise für das Shipping von Software entwickeln
- Wenn es keinen Puffer gibt, bevor Änderungen live gehen, muss man sicher sein, dass die Änderungen für die Produktion geeignet sind
- Man muss für jede eigene Änderung Ownership übernehmen und sorgfältig arbeiten
- Infrastrukturkosten und Komplexität sinken, und der Entwicklungslebenszyklus kann vereinfacht und beschleunigt werden
3 Kommentare
Wenn ich an das Gefühl der Sicherheit denke, das ich beim Aufbau einer Staging-Umgebung innerhalb einer Organisation empfunden habe, kann ich das nicht so gut nachvollziehen.
Trotzdem kann ich den Nachteil nachvollziehen, dass Deployments aufgeschoben werden oder sich viele Änderungen ansammeln.
Ich denke jedoch, dass schon allein die Existenz einer Staging-Umgebung sinnvoll ist, weil man dadurch prüfen kann, ob man auch in andere Umgebungen deployen kann und ob die grundlegende Eigenschaft von Software erfüllt ist, dass sie sich replizieren lässt.
Nun ja, ich weiß nicht, ob man sich bei Menschen mit unvollständigem „Ownership“ / unvollständiger „Sorgfalt“ darauf verlassen sollte. Sollten wir als Computerprogrammierer uns nicht zumindest von Computern helfen lassen, die exakt das tun, was man ihnen vorgibt?
Und wenn man das Konzept erweitert,
Staging = für die finale Freigabe (zur letzten Prüfung, ob es am Ende wirklich der Spezifikation entspricht, über die wir gesprochen hatten, oder ob es mit Produktivdaten dann doch unschöner aussieht usw.)
Dev = für Diskussionen über Personen wie Entwickler und über Features (für Demos)
so verwenden wir es derzeit.
Hm … ich denke, bei solchen Fragen hängt es davon ab, welche Art von Service man entwickelt.
Selbst wenn man noch so viel testet, können Probleme auftreten, und man muss abwägen, ob die Nutzer das akzeptieren können.
Bei Software wie Facebook, bei der man sich bei Fehlfunktionen eher denkt: Na ja, passiert eben, ist so ein Vorgehen möglich,
aber bei mission-kritischer Infrastruktur oder kostenpflichtigen Diensten sollte man wohl alles daransetzen, dass keine Probleme entstehen.