Guter Workflow für die Softwareentwicklung mit Scrum und kontinuierlicher Integration

Ich untersuche einen Ansatz, um besser zu verstehen, wie der kontinuierliche Integrationsworkflow mit der Scrum-Methode besser in ein Softwareentwicklungsunternehmen passt.

Ich denke so etwas:

Wäre das ein schöner Workflow?

Sie sind auf dem Weg dorthin, aber ich würde Ihr Diagramm etwas erweitern:

Grundsätzlich (wenn Ihre Versionskontrolle es zulässt, dh wenn Sie auf hg / git sind) möchten Sie, dass jedes Entwickler / Entwickler-Paar seinen eigenen "persönlichen" Zweig hat, der eine einzelne User Story enthält, an der sie arbeiten. Wenn sie die Funktion abgeschlossen haben, müssen sie in einen zentralen Zweig, den "Release" -Zweig, verschieben. Jetzt möchten Sie, dass der Entwickler einen neuen Zweig erhält, damit er als Nächstes daran arbeiten kann. Der ursprüngliche Feature-Zweig sollte unverändert bleiben, damit alle Änderungen, die daran vorgenommen werden müssen, isoliert vorgenommen werden können (dies ist nicht immer zutreffend, aber ein guter Ausgangspunkt). Bevor ein Entwickler wieder an einem alten Feature-Zweig arbeitet, sollten Sie den neuesten Release-Zweig einbinden, um seltsame Zusammenführungsprobleme zu vermeiden.

Zu diesem Zeitpunkt haben wir einen möglichen Release-Kandidaten in Form des "Release" -Zweigs und sind bereit, unseren CI-Prozess auszuführen (in diesem Zweig können Sie dies natürlich in jedem Entwicklerzweig tun, aber dies ist der Fall ziemlich selten in größeren Entwicklerteams, die den CI-Server überladen). Dies kann ein konstanter Prozess sein (dies ist idealerweise der Fall, das CI sollte immer dann ausgeführt werden, wenn der Zweig "Release" geändert wird), oder es kann sich um einen nächtlichen Prozess handeln.

Zu diesem Zeitpunkt möchten Sie einen Build ausführen und ein funktionsfähiges Build-Artefakt vom CI-Server erhalten (dh etwas, das Sie möglicherweise bereitstellen könnten). Sie können diesen Schritt überspringen, wenn Sie eine dynamische Sprache verwenden! Sobald Sie fertig sind, möchten Sie Ihre Komponententests ausführen, da sie die Grundlage aller automatisierten Tests im System bilden. Es ist wahrscheinlich, dass sie schnell sind (was gut ist, da der gesamte Sinn von CI darin besteht, die Rückkopplungsschleife zwischen Entwicklung und Test zu verkürzen), und es ist unwahrscheinlich, dass sie eine Bereitstellung benötigen. Wenn sie erfolgreich sind, möchten Sie Ihre Anwendung (falls möglich) automatisch auf einem Testserver bereitstellen und alle verfügbaren Integrationstests ausführen. Die Integrationstests können automatisierte UI-Tests, BDD-Tests oder Standardintegrationstests unter Verwendung eines Unit-Testing-Frameworks (dh "Unit") sein.

Zu diesem Zeitpunkt sollten Sie einen ziemlich umfassenden Hinweis darauf haben, ob der Build durchführbar ist. Der letzte Schritt, den ich normalerweise mit einem "Release" -Zweig einrichte, besteht darin, den Release-Kandidaten automatisch auf einem Testserver bereitzustellen, damit Ihre QA-Abteilung manuelle Rauchprüfungen durchführen kann (dies erfolgt häufig nachts anstatt per Check-in, um sicherzustellen, dass der Test durchgeführt wird) um einen Testzyklus nicht durcheinander zu bringen). Dies gibt nur einen kurzen Überblick darüber, ob der Build wirklich für eine Live-Veröffentlichung geeignet ist, da es ziemlich leicht ist, Dinge zu übersehen, wenn Ihr Testpaket nicht umfassend genug ist, und selbst bei einer Testabdeckung von 100% ist es leicht, etwas zu übersehen, das Sie können Es wird nicht automatisch getestet (z. B. ein falsch ausgerichtetes Bild oder ein Rechtschreibfehler).

Dies ist in der Tat eine Kombination aus kontinuierlicher Integration und kontinuierlicher Bereitstellung. Da der Schwerpunkt in Agile jedoch auf schlanker Codierung und automatisiertem Testen als erstklassigem Prozess liegt, möchten Sie einen möglichst umfassenden Ansatz erreichen.

Der von mir beschriebene Prozess ist ein idealer Fall. Es gibt viele Gründe, warum Sie Teile davon aufgeben könnten (z. B. sind Entwicklerzweige in SVN einfach nicht möglich), aber Sie möchten so viel wie möglich davon anstreben .

Wie der Scrum-Sprint-Zyklus dazu passt, möchten Sie im Idealfall, dass Ihre Releases so oft wie möglich stattfinden und erst am Ende des Sprints veröffentlicht werden, damit Sie schnell eine Rückmeldung darüber erhalten, ob ein Feature (und das gesamte Build) vorhanden ist ) Ist eine Produktionsverlagerung sinnvoll? Dies ist eine wichtige Technik, um die Rückkopplungsschleife zu Ihrem Product Owner zu verkürzen.

Konzeptionell ja. Ein Diagramm erfasst jedoch nicht viele wichtige Punkte wie:

1. Unit-Test
2. inkrementelle Commits
3. Staging wird zu oft bereitgestellt, die Produktion normalerweise nicht.

Möglicherweise möchten Sie ein breiteres System für das Diagramm zeichnen. Ich würde die folgenden Elemente hinzufügen:

Zeigen Sie Ihre Eingaben an das System, die an die Entwickler weitergeleitet werden. Nennen Sie sie Anforderungen, Fehlerbehebungen, Geschichten oder was auch immer. Derzeit geht Ihr Workflow jedoch davon aus, dass der Betrachter weiß, wie diese Eingaben eingefügt werden.

Zeigen Sie die Kontrollpunkte entlang des Workflows an. Wer / was entscheidet, wann ein Wechsel in trunk / main / release-branch / etc ... erlaubt ist? Welche Codebäume / Projekte werden in der GUS erstellt? Gibt es einen Kontrollpunkt, um festzustellen, ob der Build beschädigt wurde? Wer wird aus der GUS in die Inszenierung / Produktion entlassen?

In Bezug auf die Kontrollpunkte wird ermittelt, wie Ihre Verzweigungsmethode aussieht und wie sie in diesen Workflow passt.

Gibt es ein Testteam? Wann werden sie beteiligt oder benachrichtigt? Werden in der GUS automatisierte Tests durchgeführt? Wie werden Brüche in das System zurückgeführt?

Überlegen Sie, wie Sie diesen Workflow einem herkömmlichen Flussdiagramm mit Entscheidungspunkten und Eingaben zuordnen möchten. Haben Sie alle wichtigen Berührungspunkte erfasst, die zur angemessenen Beschreibung Ihres Workflows erforderlich sind?

Ihre ursprüngliche Frage ist der Versuch, einen Vergleich anzustellen, aber ich bin mir nicht sicher, welche Aspekte Sie vergleichen möchten. Die kontinuierliche Integration hat wie andere SDLC-Modelle Entscheidungspunkte, die sich jedoch möglicherweise an anderen Stellen im Prozess befinden.

Ich verwende den Begriff "Entwicklungsautomatisierung", um alle automatisierten Erstellungs-, Dokumentationserstellungs-, Test-, Leistungsmessungs- und Bereitstellungsaktivitäten zu erfassen.

Ein "Development Automation Server" hat daher einen ähnlichen, aber etwas breiteren Aufgabenbereich als ein Continuous Integration Server.

Ich bevorzuge die Verwendung von Entwicklungsautomatisierungsskripten, die von Post-Commit-Hooks gesteuert werden und die Automatisierung sowohl von privaten Zweigen als auch des zentralen Entwicklungsstamms ermöglichen, ohne dass eine zusätzliche Konfiguration auf dem CI-Server erforderlich ist. (Dies schließt die Verwendung der meisten Standard-CI-Server-GUIs aus, die mir bekannt sind.)

Das Post-Commit-Skript bestimmt anhand des Inhalts der Verzweigung selbst, welche Automatisierungsaktivitäten ausgeführt werden sollen. Entweder durch Lesen einer Konfigurationsdatei nach dem Festschreiben an einem festen Speicherort im Zweig oder durch Erkennen eines bestimmten Wortes (ich verwende / auto /) als Komponente des Pfads zum Zweig im Repository (mit Svn).

(Dies ist mit Svn einfacher einzurichten als mit Hg).

Durch diesen Ansatz kann das Entwicklungsteam die Organisation seines Workflows flexibler gestalten, sodass CI die Entwicklung in Zweigstellen mit minimalem Verwaltungsaufwand (nahe Null) unterstützen kann.

Es gibt eine gute Reihe von Beiträgen zur kontinuierlichen Integration auf asp.net , die Sie vielleicht nützlich finden. Sie decken einiges ab und enthalten Workflows, die mit dem übereinstimmen , was Sie erwartet haben .

In Ihrem Diagramm wird die vom CI-Server geleistete Arbeit (Komponententests, Codeabdeckung und andere Metriken, Integrationstests oder nächtliche Builds) nicht erwähnt, aber ich gehe davon aus, dass dies alles in der Phase "Continuous Integration Server" behandelt wird. Ich bin mir nicht sicher, warum die CI-Box zurück in das zentrale Repository verschoben wird. Natürlich muss der Code abgerufen werden, aber warum sollte er ihn jemals zurücksenden müssen?

CI ist eine dieser Methoden, die von verschiedenen Disziplinen empfohlen werden. Es ist nicht nur für Scrum (oder XP) geeignet, aber ich würde sogar sagen, dass die Vorteile jedem Flow zur Verfügung stehen, auch wenn er nicht agil ist, wie z. B. Wasserfall (vielleicht nass-agil?). . Für mich sind die Hauptvorteile die enge Rückkopplungsschleife. Sie wissen ziemlich schnell, ob der soeben festgelegte Code mit dem Rest der Codebasis zusammenarbeitet. Wenn Sie in Sprints arbeiten und Ihre täglichen Stand-ups haben, ist es auf jeden Fall ein Plus und hilft, die Leute zu fokussieren, wenn Sie sich auf den Status oder die Kennzahlen der letzten Nächte beziehen können, die auf dem CI-Server erstellt wurden. Wenn Ihr Product Owner den Status des Builds sehen kann - ein großer Monitor in einem gemeinsam genutzten Bereich, der den Status Ihrer Build-Projekte anzeigt - dann haben Sie diese Feedback-Schleife wirklich gestrafft. Wenn Ihr Entwicklerteam häufig (mehr als einmal am Tag und im Idealfall mehr als einmal pro Stunde) eine Verpflichtung eingeht, ist die Wahrscheinlichkeit, dass Sie auf ein Integrationsproblem stoßen, dessen Lösung lange dauert, geringer Sie können alle Maßnahmen ergreifen, die Sie benötigen, zum Beispiel alle, die aufhören, sich mit dem kaputten Build zu befassen. In der Praxis werden Sie wahrscheinlich nicht auf viele fehlgeschlagene Builds stoßen, die mehr als ein paar Minuten benötigen, um herauszufinden, ob Sie häufig integrieren.

Abhängig von Ihren Ressourcen / Ihrem Netzwerk möchten Sie möglicherweise verschiedene Endserver hinzufügen. Wir haben einen CI-Build, der durch ein Commit für das Repo ausgelöst wird und davon ausgeht, dass alle Tests erstellt und bestanden werden. Anschließend wird er auf dem Entwicklungsserver bereitgestellt, damit Entwickler sicherstellen können, dass er gut funktioniert. ). Nicht jedes Commit ist jedoch ein stabiler Build. Um einen Build für den Staging-Server auszulösen, müssen Sie die Revision kennzeichnen (wir verwenden mercurial), die erstellt und bereitgestellt werden soll. Auch dies geschieht automatisch und wird durch einfaches Commit mit einem bestimmten Server ausgelöst Etikett. Zur Produktion zu gehen ist ein manueller Prozess; Sie können es so einfach wie das Erzwingen eines Builds belassen. Der Trick besteht darin, zu wissen, welche Revision / welchen Build Sie verwenden möchten. Wenn Sie die Revision jedoch entsprechend kennzeichnen, kann der CI-Server die richtige Version auschecken und alle erforderlichen Schritte ausführen. Sie könnten MS Deploy verwenden, um die Änderungen mit den Produktionsservern zu synchronisieren oder um sie zu packen und die Zip-Datei an einem Ort abzulegen, an dem ein Administrator sie manuell bereitstellen kann. Dies hängt davon ab, wie gut Sie damit umgehen können.

Neben dem Hochfahren einer Version sollten Sie auch überlegen, wie Sie mit Fehlern umgehen und eine Version herunterfahren können. Es wird hoffentlich nicht passieren, aber möglicherweise werden Änderungen an Ihren Servern vorgenommen, die bedeuten, dass die Funktionen von UAT in der Produktion nicht funktionieren. Sie geben Ihre genehmigte Version frei und es schlägt fehl. Sie können immer den Ansatz wählen, den Sie identifizieren Fehler, Code hinzufügen, festschreiben, testen, in der Produktion bereitstellen, um diesen Fehler zu beheben ... oder Sie können weitere Tests durchführen, um Ihre automatisierte Veröffentlichung in die Produktion zu überführen. Wenn diese fehlschlägt, wird automatisch ein Rollback durchgeführt.

CruiseControl.Net verwendet XML zum Konfigurieren der Builds, TeamCity verwendet Assistenten. Wenn Sie Spezialisten in Ihrem Team vermeiden möchten, sollten Sie die Komplexität der XML-Konfigurationen berücksichtigen.

Zunächst eine Einschränkung: Scrum ist eine ziemlich strenge Methode. Ich habe für ein paar Organisationen gearbeitet, die versucht haben, Scrum oder Scrum-ähnliche Ansätze zu verwenden, aber keiner von ihnen hat wirklich die volle Disziplin in seiner Gesamtheit genutzt. Nach meinen Erfahrungen bin ich ein Agile-Enthusiast, aber ein (widerstrebender) Scrum-Skeptiker.

Nach meinem Verständnis haben Scrum und andere Agile-Methoden zwei Hauptziele:

• Der erste besteht darin, einen expliziten Mechanismus für das Risikomanagement und die fortlaufende Erkennung von Risiken bereitzustellen.
• Die zweite besteht darin, einen strukturierten Mechanismus für die Stakeholder-Kommunikation, die Anforderungsermittlung und das Anforderungsmanagement bereitzustellen.

Das erste (Risikomanagement-) Ziel wird durch iterative Entwicklung erreicht. Fehler zu machen und schnell Lektionen zu lernen, so dass das Team das Verständnis und die intellektuelle Fähigkeit aufbauen kann, Risiken zu reduzieren und zu einer risikoreduzierten Lösung mit einer risikoarmen "strengen" Lösung zu gelangen, die sich bereits in der Tasche befindet.

Entwicklungsautomatisierung, einschließlich kontinuierlicher Integration, ist der wichtigste Faktor für den Erfolg dieses Ansatzes. Risk Discovery & Lesson-Learning muss schnell, reibungslos und frei von störenden sozialen Faktoren sein. (Die Leute lernen VIEL schneller, wenn es sich um eine Maschine handelt, die ihnen sagt, dass sie falsch liegen, und nicht um einen anderen Menschen. Egos behindern nur das Lernen.)

Wie Sie wahrscheinlich sehen können, bin ich auch ein Fan von testgetriebener Entwicklung. :-)

Das zweite Ziel hat weniger mit Entwicklungsautomatisierung als vielmehr mit Human Factors zu tun. Es ist schwieriger zu implementieren, da es ein Buy-in vom Front-End des Geschäfts erfordert, bei dem es unwahrscheinlich ist, dass die Notwendigkeit der Formalität erkannt wird.

Hier kann die Entwicklungsautomatisierung eine Rolle spielen, indem automatisch generierte Dokumentationen und Fortschrittsberichte verwendet werden, um Stakeholder außerhalb des Entwicklungsteams kontinuierlich über den Fortschritt auf dem Laufenden zu halten, und Informationsquellen, die den Build-Status anzeigen und Testsuiten bestehen / nicht bestehen, können verwendet werden, um den Fortschritt zu kommunizieren Unterstützung (hoffentlich) bei der Übernahme des Scrum-Kommunikationsprozesses bei der Funktionsentwicklung.

Also, zusammenfassend:

Das Diagramm, das Sie zur Veranschaulichung Ihrer Frage verwendet haben, erfasst nur einen Teil des Prozesses. Wenn Sie sich mit Agile / Scrum und CI befassen möchten, ist es meiner Meinung nach wichtig, die umfassenderen sozialen und menschlichen Faktoren des Prozesses zu berücksichtigen.

Ich muss zum Schluss die gleiche Trommel schlagen, die ich immer tue. Wenn Sie versuchen, einen agilen Prozess in einem realen Projekt zu implementieren, ist der Grad der implementierten Automatisierung der beste Prädiktor für Ihre Erfolgschancen. Es reduziert die Reibung, erhöht die Geschwindigkeit und ebnet den Weg zum Erfolg.