Stanford führt eine Instanz der OpenEdX-Codebasis aus, die ein Team von Ingenieuren aktiv entwickelt. Wir unterhalten unseren eigenen Fork bei github.com/Stanford-Online/edx-platform und wir versuchen, unseren Fork in der Nähe des edX-Masters zu halten, indem wir monatlich aus dem Haupt-Repository der edX-Plattform von edX (github.com/edx/edx-platform). Wir ziehen es vor, Code über Pull-Requests (PRs) an das Haupt-Repository von edX zu senden, aber manchmal ist das nicht möglich, da wir regelmäßig benutzerdefinierte Stanford-spezifische Funktionen erstellen. Durch Iteration haben wir einen klar definierten Freigabeprozess eingeführt, der Arbeitsabläufe sowohl für die Zusammenführung aus dem edX-Hauptrepository als auch für die Trennung unserer eigenen unterstützt führen zu Ast. Da wir eine Website mit einer großen Anzahl von Benutzern betreiben, denken wir, dass die Stabilität der Veröffentlichungen von größter Bedeutung ist. Das bedeutet, dass wir uns sehr bemühen, schlechten Code aus dem Programm herauszuhalten Release Branche, und der Freigabeprozess erleichtert dies.
Da wir PRs sowohl an edX als auch an uns selbst übermitteln, müssen wir von unseren Entwicklungsumgebungen aus Zugriff auf die Repositories von edX haben, daher führen die meisten Entwickler in Stanford Git-Umgebungen mit mindestens zwei Fernbedienungen (oder manchmal mehr mit persönlichen Fernbedienungen und denen von Kollegen): Herkunft, das Stanford-Code-Repository; und flussaufwärts, das edX-Code-Repository, aus dem wir den Master-Zweig auschecken können, um PRs für edX zu erstellen. Auch das nutzen wir flussaufwärts Remote, um Codeänderungen von edX während unseres Freigabeprozesses zusammenzuführen.
Hier sah ich die Notwendigkeit für ein Diagramm, das den Freigabeprozess erklärt. Ich bin ein visueller Mensch, und etwas zu zeichnen ist, wie ich Dinge verstehe. Hier ist mein Diagramm, um unseren Entwicklungs- und Release-Workflow zu beschreiben:
Dies ist besonders nützlich, da unsere Entwickler abwechselnd für Releases in unserem rotierenden „Release Master“-System verantwortlich sind. Das Diagramm hält unseren Release-Zyklus zwischen den Releases konsistent und minimiert Fehler.
Hier ist ein Veröffentlichungsplan, der das Diagramm als Richtlinie verwendet:
1. Zuerst erstellen wir eine rc Verzweigung von unserem Master-Zweig, wobei jede Entwicklung übernommen wird, in die gemergt wurde führen zu seit der letzten Veröffentlichung.
1a. Wenn wir die zusammenführen wollen flussaufwärts Release in die verzweigen rc Filiale, das machen wir hier.
An diesem Punkt haben wir einen Release Candidate, den wir testen und, sobald wir sicher sind, dass er nichts kaputt macht, dann auf unseren Produktionsmaschinen installieren können.
2. Jetzt führen wir den Zweig zusammen rc in die Filiale Release (Dies sollte ein einfacher Schnellvorlauf sein; wenn dies nicht der Fall ist, hatte die vorherige Version ein Problem!).
3. Nun die Release Zweig (und die zusammengeführte flussaufwärts code) kann wieder in die zusammengeführt werden führen zu Verzweigung, um beide Zweige miteinander synchron zu halten.
Beachten Sie, dass Feature-Zweige aus erstellt werden führen zu und wieder zusammengeführt, um im regulären Release-Zyklus veröffentlicht zu werden. Hotfixes hingegen werden abgezweigt Release, wieder zusammengeführt Release, sofort in die Produktion verschoben und dann wieder zusammengeführt führen zu Synchronität zu wahren. Beachte das auch Release Änderungen und flussaufwärts Zusammenführungen schaffen es nicht in führen zu es sei denn, sie gelten nach dem Testen als sicher, was isoliert führen zu auch vor Bugs.
Und das ist es! Wir verwenden dieses Verzweigungsmodell für jedes gegabelte Repository, das wir pflegen, wodurch alles konsistent und vorhersehbar bleibt.
