Dieser Artikel ist eine Fortsetzung einer Reihe von Artikeln, die hier früher veröffentlicht wurden und den Phasen gewidmet sind:
- Anforderungserklärung
- Design
- Implementierungen. Serviceschicht
Es wird beschrieben, wie wir den Entwicklungsprozess organisiert haben, indem wir Entwickler aus der Magento-Community seit Beginn des Projekts Mitte letzten Sommers einbezogen haben und mit denen wir uns der
allgemeinen Verfügbarkeitsveröffentlichung näherten, die letzte Woche veröffentlicht wurde.
Entwicklungsprozess
Alle Arbeiten an dem Projekt wurden mit Programmierern aus der Magento-Community durchgeführt, die sich freiwillig der Entwicklung anschlossen,
Aufgaben aus dem für sie interessanten Rückstand des Projekts übernahmen und dabei Pull Requests auf GitHub stellten.
Infolgedessen gab es mehr als 80 solcher Leute, die mindestens einen Anforderungspool erstellt haben, und insgesamt haben sie mehr als 800 Anforderungspools erstellt.
Die Entwicklung wurde sowohl von Angesicht zu Angesicht bei Hackathon-Veranstaltungen durchgeführt, die in der Magento-Welt allgemein als „Beitragstag“ bezeichnet werden, als auch verteilt, wenn die Jungs zu einem geeigneten Zeitpunkt aus der Ferne an dem Projekt arbeiteten, um Demos des Projekts zu eröffnen, um Ergebnisse zu zeigen und Fragen zu stellen.
Bei Veranstaltungen im Format „Contribution Day“, bei denen Programmierer sehr einfach in das Projekt eintreten und das Problem mit den Systemarchitekten besprechen und das Verfahren durchlaufen können, wurde die Codeüberprüfung sehr beliebt, da Community-Programmierer schnell lernen und Empfehlungen und Tipps erhalten. von Kerningenieuren, die mit dem System arbeiten, sowie Kenntnisse darüber, wie typische Probleme mithilfe der vom Framework bereitgestellten Mechanismen gelöst werden können; Nehmen Sie gleichzeitig nützliche Verbesserungen am System selbst vor. Wie die Win-Win-Praxis eines solchen Modells gezeigt hat, gilt dies für alle Teilnehmer des Prozesses, einschließlich Agenturen, die Programmierer, die an dem Projekt teilnehmen, als Mitwirkende beschäftigen, da diese Agenturen das von ihren Mitarbeitern gewonnene Wissen als Wettbewerbsvorteil für ihre zukünftigen Projekte nutzen können.
Zum Beispiel hatte Strix, der aktiv an Code Contribution für das MSI-Projekt beteiligt war, zwei Wochen vor der offiziellen Veröffentlichung bereits ein Projekt gestartet, das auf Magento 2.3 + MSI Beta basiert und auf
seinem Blog veröffentlicht wurde .
Und wenn es 2017 15 solcher Ereignisse gab, dann gab es 2018 mehr als 40.
Bei den zahlreichsten Veranstaltungen versammelten sich mehr als 100 Mitwirkende an einem Ort, wie beispielsweise der jüngste Beitragstag in Kiew vor der # MageConf18-Konferenz oder der Magento Live EU-Beitragstag in Barcelona:
Für eine schnelle Kommunikation mit Entwicklern haben wir einen separaten Slack-Kanal für die Kommunikation zugewiesen, der jetzt aus mehr als 350 Entwicklern besteht.
Slack ersetzte alle Instant Messenger und stellte Tools zur Verfügung, mit denen wir schnell Feedback von der Community mit Produkt- und technischen Lösungen erhalten konnten, die wir gerade implementieren wollten. Wir haben dies mit Hilfe von Standardwerkzeugen für Fragebögen in Ruhe getan.
Die Hauptdokumentationsquelle für das Projekt war lange Zeit das
Projekt-Wiki , das alle technischen Entwürfe, Benutzerdokumentationen, Kommunikationsarchive in Slack sowie Beschreibungen der bei Grooming- und Stand-up-Rallyes getroffenen Entscheidungen enthält.
Jeden Freitag demonstrieren Mitwirkende, die einen Pool von Anfragen für das Projekt gestellt haben, sowie diejenigen, die Fragen / Vorschläge zur Verbesserung haben, ihre Ergebnisse auf einer offenen Demo-Rallye, zu der sich jeder über Zoom verbinden kann:
Und alle, die keine Zeit für die Rallye hatten, können sich die Aufzeichnung ansehen, da jede solche Rallye auf
YouTube aufgezeichnet und angelegt wird. Dies ist beispielsweise eine Aufzeichnung der letzten Demo, in der Riccardo Tempesta-Mitarbeiter den Algorithmus zur Quellenauswahl für die optimale Auswahl von Lagern für die Lieferung anhand der Abstände zwischen der Lieferadresse und den Adressen von Lagern mit Waren demonstriert
Das Schwierigste in einem solchen Modell der Softwareentwicklung, in dem es keine ständig engagierten Mitarbeiter im Projekt gibt, ist die Planung der Zeit für die Verfügbarkeit von Armaturen und die Bestimmung der
Scrum-Geschwindigkeit und -Kapazität der Hauptmetriken für die Beurteilung, wann eine bestimmte Anpassung geliefert werden kann. Tatsächlich verbringt der Mitwirkende, der innerhalb einer Woche 20 bis 30 Stunden in das Projekt investiert hat, möglicherweise nicht einmal eine Stunde in der nächsten Woche, da es bei seiner Hauptaufgabe zu einer Blockade kommt, die Frau / das Mädchen eifersüchtig wird oder angesichts anderer Umstände, weil eine Person dies kann banal aufhören interessant zu sein. Entwickler von Drittanbietern haben keine Verpflichtungen gegenüber dem Projekt. Sie nehmen zum Spaß und für neues Wissen teil. Und das müssen wir ihnen geben, ohne etwas dafür zu verlangen!
Brennen Sie ein Diagramm der mit ZenHub erstellten Milestone 2-Implementierung herunter .In der Theorie des Projektmanagements versuchen sie normalerweise, einen der beiden Indikatoren Fixed Scope oder Fixed Delivery Time in Gegenwart der Bedingung Fixed Resources zu fixieren.
Bei einem Modell, an dem nur Entwickler aus der Community teilnehmen, verfügen wir nicht über feste Ressourcen, und alle Versuche, die Lieferzeit zu korrigieren, waren sehr schwierig.
Aus diesem Grund haben wir uns letztendlich entschieden, den
FDD- Prozess
(Feature-Driven Development) zu wählen und zu verfolgen. Formal genug Zeit für die Iteration (Meilenstein) für 2-3 Monate festlegen. Das Backlog dieses Meilensteins zu bilden und erneut die Community für die Priorisierung von Aufgaben in diesem Backlog zu gewinnen, ist ein weiteres Merkmal dieses Entwicklungsmodells, da wir das Produkt-Backlog nicht im Alleingang bilden und Prioritäten setzen. Mitwirkende, insbesondere wenn sie Unternehmen vertreten, legen häufig ihre eigene Priorität für bestimmte Aufgaben fest, die von ihren aktuellen oder zukünftigen Projekten vorgegeben wird. Solche Mitwirkenden sind daran interessiert, dem Projektrepository in erster Linie das zu liefern, was für sie interessant ist. Als Teil des Meilensteins arbeiten wir gleichzeitig an Storys und können sie veröffentlichen, sobald wir fertig sind oder sobald die Endzeit der Iteration erreicht ist. Wenn einige Storys im Rahmen der Iteration nicht abgeschlossen wurden, fahren sie mit dem nächsten Meilenstein fort.
Und vor allem - wir haben das Veröffentlichungsdatum des Hauptprodukts - Magento 2 - entfernt und können jetzt unabhängig davon veröffentlicht werden! Warum haben wir das
Composer- Metapaket herausgegriffen, das sich auf alle Inventarmodule bezieht, und der Link zum Metapaket selbst aus dem Hauptrepository (genauer gesagt aus dem Metapaket des Hauptrepositorys) sieht folgendermaßen aus:
"magento/inventory-composer-metapackage": "^1.0.3"
d.h. Das
Zeichen ^ gibt die Paketversion an.
Ebenso werden Links zu allen Versionen von Projektmodulen innerhalb des Pakets durch das Symbol ^ gekennzeichnet:
{ "name": "magento/inventory-composer-metapackage", "version": "1.0.3", "description": "Metapackage with Magento Inventory modules for simple installation", "type": "metapackage", "require": { "magento/inventory-composer-installer": "^1.0.3", "magento/module-inventory": "^1.0.3", "magento/module-inventory-admin-ui": "^1.0.3", "magento/module-inventory-api": "^1.0.3", "magento/module-inventory-bundle-product": "^1.0.3", "magento/module-inventory-bundle-product-admin-ui": "^1.0.3", "magento/module-inventory-cache": "^1.0.3", "magento/module-inventory-configurable-product": "^1.0.3", "magento/module-inventory-catalog-api": "^1.0.3", "magento/module-inventory-catalog": "^1.0.3", "magento/module-inventory-catalog-admin-ui": "^1.0.3", "magento/module-inventory-catalog-search": "^1.0.3", "magento/module-inventory-configurable-product-admin-ui": "^1.0.3", "magento/module-inventory-configurable-product-indexer": "^1.0.3", "magento/module-inventory-configuration": "^1.0.3", "magento/module-inventory-configuration-api": "^1.0.3", "magento/module-inventory-grouped-product": "^1.0.3", "magento/module-inventory-grouped-product-admin-ui": "^1.0.3", "magento/module-inventory-grouped-product-indexer": "^1.0.3", "magento/module-inventory-import-export": "^1.0.3", "magento/module-inventory-indexer": "^1.0.3", "magento/module-inventory-multi-dimensional-indexer-api": "^1.0.3", "magento/module-inventory-low-quantity-notification": "^1.0.3", "magento/module-inventory-low-quantity-notification-api": "^1.0.3", "magento/module-inventory-low-quantity-notification-admin-ui": "^1.0.3", "magento/module-inventory-product-alert": "^1.0.3", "magento/module-inventory-reservations": "^1.0.3", "magento/module-inventory-reservations-api": "^1.0.3", "magento/module-inventory-sales": "^1.0.3", "magento/module-inventory-sales-admin-ui": "^1.0.3", "magento/module-inventory-sales-api": "^1.0.3", "magento/module-inventory-sales-frontend-ui": "^1.0.3", "magento/module-inventory-shipping": "^1.0.3", "magento/module-inventory-shipping-admin-ui": "^1.0.3", "magento/module-inventory-source-deduction-api": "^1.0.3", "magento/module-inventory-source-selection-api": "^1.0.3", "magento/module-inventory-source-selection": "^1.0.3" } }
Der Operator ^ ist für maximale Kompatibilität beim Schreiben von Code vorhanden, sodass wir interne MSI-Releases durchführen können, bis wir
rückwärts inkompatible Änderungen am Projekt "
> = 1.0.3 <2.0.0 " vornehmen.
Dies bietet zum einen eine ausreichende Flexibilität für Projekte wie MSI, die üblicherweise als Magento Core Bundle Extensions (CBE) bezeichnet werden. Solche Projekte befinden sich in separaten GitHub-Repositories, haben eine eigene Chronologie der Veröffentlichungen und sind so isoliert wie möglich von anderen ähnlichen Projekten und vom Magento 2-Hauptprodukt. In Bezug auf die Isolation ist es prozedural wie das
Befolgen des Conway-Gesetzes . Weltweit entspricht dieser Entwicklungsansatz für neue Services und Projekte in Magento 2 dem vom Magento Architectural Council vorgestellten
Service Isolation- Konzept. Aber mit größerer Flexibilität geht eine größere Verantwortung einher (
mit einer großen Macht geht eine große Verantwortung einher ), weil In diesem Fall sollten solche Projekte strikt der semantischen Versionierung (
SemVer ) folgen, um rückwärts inkompatible Änderungen zu verhindern und Benutzern ein einfaches Upgrade zu ermöglichen.
Der Rückstand des Projekts selbst sowie alle Iterationen (einschließlich der abgeschlossenen) sind auf der Seite
MSI Roadmap verfügbar.
Dies ist beispielsweise der Rückstand Meilenstein 3, an dem wir gerade mit der Arbeit beginnen:
Abschließend möchte ich mich noch einmal bei
allen Mitwirkenden bedanken, die sich dem Projekt angeschlossen und dazu beigetragen haben, es in die GA-Release-Phase zu bringen. Ohne Sie wäre es uns nicht gelungen!
