Ich bin mir nicht sicher, ob diese Frage ein Duplikat ist, konnte aber nichts dergleichen finden, obwohl es ein häufiges Problem zu sein scheint. Wenn es sich also um ein Duplikat handelt, entschuldigen Sie mich für meine Ineffizienz bei der Suche nach Schlüsselwörtern außerhalb meines Wissens.
Ich bin Softwareentwickler in einem kleinen Team und versuche, meinem Projektmanager dabei zu helfen, unseren Bereitstellungsprozess zu überprüfen, um ihn zu verbessern.
Unser Produkt besteht aus mehreren Komponenten mit unterschiedlichen Aktualisierungszyklen, die schwer zu verwalten sind und bei denen Funktionen oft versteckte Nebeneffekte in anderen Teilen des Codes haben. Nachdem Funktionen entwickelt wurden, bleiben sie unberührt, bis sie entweder von unserer QA in vollständigen Regressionstests, die eine Woche oder länger dauern können, oder von unserem Kunden selbst getestet werden. Bis ein Feature einsatzbereit ist, können Monate vergehen. Wir können viele Funktionen gleichzeitig in verschiedenen Entwicklungs- oder Testphasen „in der Warteschleife“ haben, und die größten Funktionen können sogar Jahre der Verfeinerung warten, bevor sie bereitgestellt werden.
Wenn Funktionen eingesetzt werden, werden sie natürlich zusammengeführt, und die Mischung kann oft ... explosiv sein. Dies führt zu Fehlern in der Produktionsumgebung des Kunden, was wiederum Zweifel an der Qualität des Codes weckt und zu "mehr Testzeit" führt, was tatsächlich mehr Wartezeit und mehr Funktionen bedeutet, die als nächstes bereitgestellt werden müssen ...
Continuous Deployment scheint nicht machbar zu sein, da unsere Kundin (aus gutem Grund) Deployments überwachen möchte und ihre Deployment-Zeiten lang sind. Wie können wir das Risiko von Interferenzen und Nebeneffekten durch mehrere Zusammenführungen reduzieren? Ich denke, das ist ein zu grundlegendes Thema, um nicht vorher angesprochen worden zu sein.
Wenn ich Sie richtig verstehe, haben Sie nur ein Team und der einzige/Hauptgrund, warum Sie so arbeiten, ist, dass die Qualitätssicherung so lange dauert und Sie nicht „Däumchen drehen“ wollen, während Sie auf ihr Feedback warten.
Wenn dies der Fall ist, besteht Ihre erste Priorität darin, stark in die Automatisierung so vieler Ihrer Tests wie möglich zu investieren. Sie werden wochenlanges manuelles Testen vielleicht nicht los. Manche Unternehmen gehen da ziemlich anal vor (Hust GMP Husten). Aber Ihr Problem ist nicht, dass es dieses einwöchige Voodoo-Ritual in Ihrer Deployment-Pipeline gibt. Ihr Problem ist, dass Sie derzeit den größten Teil Ihres Fehlerfeedbacks davon erhalten.
Besonders wenn nur ein Team an einem Produkt arbeitet, möchten Sie eine kontinuierliche Integration. Sie möchten so schnell wie möglich von Ihren Problemen erfahren. Und das bedeutet automatisierte Tests. Sie möchten ein Feature ausstanzen, es polieren, bis alles funktioniert, und es dann vergessen können.
Das bedeutet, dass Sie automatisierte Tests für die Fehler schreiben müssen, die Ihre Tester finden. Was Sie jetzt umbringt, ist das Warten auf diese "Explosionen" 2 Monate später, wenn zwei Features zusammengeführt werden. Wenn Sie die Möglichkeit hätten, diese beiden Zutaten zu mischen, sobald beide fertig sind und sofortige Ergebnisse erzielen, könnten Sie auch sofort mit der Fixierung beginnen.
Selbst wenn Sie mehrere Teams haben, sollten Sie, wenn Sie in der Lage sind, Ihre Funktion mit der neuesten vollständig getesteten Version zusammenzuführen und "vorab zu testen", weit weniger Situationen erleben, in denen Sie eine Funktion erneut aufrufen müssen, nachdem der "echte Test" abgeschlossen ist.
Sobald Sie Funktionen ausmerzen können, die im Wesentlichen eisern sind, spielt es keine Rolle mehr, ob die QA eine weitere Woche braucht, um Ihre neue Version zu segnen oder nicht.
Ich sehe zwei Auswege, die helfen können. Angenommen, Sie haben 4 Funktionen (A, B, C, D) geplant und die ETA für sie ist:
Jedes Feature wird in einem eigenen Zweig entwickelt. Jeder Zweig beginnt beim Master. Der Produktionsserver hat den Code Ihres Master-Zweigs.
I. Planen Sie Builds im Voraus
Ihr Kunde beschließt, dass er die Funktionen A und C in der nächsten Version haben möchte. Sobald C fertig ist, führen Sie also am 25. Mai A und C zusammen und stellen sie auf dem Build-Server bereit, und QA testet den Build. Nachdem der Build vom Kunden getestet, behoben und überprüft wurde, geht er live. A und C befinden sich jetzt im Master-Zweig. Der Produktionsserver hat denselben Code wie der Build-Server. Sie werden also keine Überraschungen erleben.
II. Planen Sie die Builds anhand dessen, was fertig ist
Sobald jedes Feature fertiggestellt ist, wird es auf einem eigenen Feature-Server getestet. A ist getestet und bereit, live zu gehen. B ist getestet, benötigt einige Bugfixes oder geht ins Reich der Warteschleife. C ist getestet und bereit. D ist in Bearbeitung. Der Kunde entscheidet, ob es ihm recht ist, A und C live zu pushen, oder ob er auf D warten möchte. Wenn er damit einverstanden ist, A und C bereitzustellen, führen Sie sie auch zusammen und stellen sie auf einem Vorabversionsserver bereit, auf dem die QA Rauchtests oder Prüfungen durchführt die grundlegende Funktionalität und der Kunde überprüft das Release. Und dann geht es live, auch ohne Überraschungen durch Merges.
Das zweite Schema ist flexibler, da Sie die QA und den Veröffentlichungszeitplan nicht blockieren.
Nachdem Funktionen entwickelt wurden, bleiben sie unberührt, bis sie getestet werden
vollständige Regressionstests, die eine Woche oder länger dauern können
Die größten Funktionen können sogar Jahre der Verfeinerung warten, bevor sie bereitgestellt werden
Bis ein Feature einsatzbereit ist, können Monate vergehen.
Es scheint, dass es über das Bereitstellungsmanagement hinaus viele technische und prozessuale Ineffizienzen gibt. Obwohl die Analyse und Verbesserung des Bereitstellungsprozesses einige Vorteile bringen kann, kann es wertvoller sein, andere Defizite zu beheben. Schauen Sie sich Lean Software Verschwendung an (TIM WOOD).
Continuous Deployment * muss nicht in einer Produktionsumgebung erfolgen. Normalerweise werden häufige Merge-, Continuous-Integration-(CI)- und Continuous-Deployment-(CD-)Prozesse verwendet, um Code in eine Nicht-Produktionsumgebung zu übertragen, damit automatisierte Tests durchgeführt werden können. Es wird Zeit brauchen, um die technischen Verfahren und die Infrastruktur zu verbessern, und dabei wird es weniger Abfall, verbesserte Qualität und mehr Vertrauen geben, um es in der Produktion für den Kunden einzusetzen.
Wie können wir das Risiko von Interferenzen und Nebeneffekten durch mehrere Zusammenführungen reduzieren?
Fusionen erzeugen keine Konflikte, sie offenbaren sie nur. Durch häufigeres Zusammenführen wird die Komplikation dieser Konflikte verringert, sodass sie leichter angegangen werden können.
* Bereitstellung, die hier als Lieferung von Software an einen beliebigen Endpunkt verwendet wird.
Gummiente
phagio
Gummiente