Wie wir bei Elastic Pull-Anfragen bearbeiten
Alle Abläufe bei Elastic werden gemeinschaftlich erledigt.
Unsere Spezialisten arbeiten rund um die Uhr (im wörtlichen Sinne, wie es in verteilten Unternehmen üblich ist) daran, neue Produkte und Funktionen zu entwickeln. Sie bewältigen einen riesigen Arbeitsaufwand mit großer Aufmerksamkeit für Details. Wir werden jedoch nie perfekt sein, egal wie vorsichtig wir sind, und wie alle Open-Source-Projekte von unserer Größenordnung benötigen wir nach wie vor die Hilfe der Community, um uns zu verbessern.
In unserer Reihe Solving the Small but Important Issues with Fix-It Fridays (Lösungen für kleine aber wichtige Probleme am Freitag) haben wir angesprochen, dass die Beiträge aus unserer Community der treibende Faktor für unseren anhaltenden Erfolg bei der Produktentwicklung ist. Dank unseres Status als Open-Source-Projekt haben wir den Vorteil, dass eine riesige Entwickler-Community nach Bugs sucht und eifrig auf eine Chance wartet, diese auszumerzen.
Falls Sie neu in der Community sind und Ihre erste Pull-Anfrage (Pull Request, PR) stellen möchten, oder falls Sie allgemeine Fragen zum Verfahren haben, sind Sie hier am richtigen Ort! In diesem Beitrag besprechen wir die Funktionsweise von Pull-Anfragen für Elastic sowie unsere Vorgehensweise für eingehende Anfragen und zeigen einige gängige Fehler, die dazu führen können, dass Ihr Beitrag nicht implementiert wird.
Wie stelle ich also eine Pull-Anfrage?
Bevor Sie eine PR stellen, müssen Sie einen Fork in einem GITHUB-Repository erstellen und Ihre Codeänderungen vornehmen. Dies erfolgt normalerweise in Ihrem eigenen GitHub-Konto, das eine Kopie des Quellrepositorys für Sie anlegt. Jedes unserer Projekte befinde sich in einem eigenen GitHub-Repository. Sie finden eine vollständige Liste unserer Repositorys auf der Elastic-Organisationsseite auf GitHub.
Sobald Sie einen Fork für ein Repository erstellt und den Code geändert haben, werden Sie gefragt, ob Sie einen PR stellen möchten, um die vorgeschlagenen Änderungen in den Master-Branch des Produktrepositorys zu übernehmen. Ein mögliches Beispiel ist das unten gezeigte Elasticsearch-Repository. Zur Vereinfachung verwenden wir in diesem Artikel Beispiele aus dem Elasticsearch-Repository.
Wenn Sie auf „New Pull request“ (Neue Pull-Anfrage) klicken, werden Sie zu unserer Vorlage für Pull-Anfragen weitergeleitet.
Dort erhalten Sie Hilfestellungen, um Ihre PR durch die erste Überprüfung zu bringen. Lesen Sie diese Hinweise also aufmerksam, da sich Kriterien und Dokumentation von Produkt zu Produkt unterscheiden. Diese Vorlage unterstützt Sie dabei, Ihre PR durch die erste Überprüfung zu bringen.
Achten Sie bei Ihrer PR darauf, die folgenden gängigen Fehler zu vermeiden:
- Übermitteln von Duplikaten: Suchen Sie zunächst nach offenen PRs, die eine Korrektur für den Bug enthalten, den Sie mit Ihrem Code beheben möchten. Duplikate werden normalerweise abgelehnt.
- Keine Tests enthalten: Eine PR mit Codeänderungen sollte einen Test enthalten, der das Verhalten des neuen Codes veranschaulicht. Im Idealfall sollte dieser Test das Problem reproduzieren, das mit der PR behoben wird. Auf diese Weise schlägt der Test ohne den Code fehl und ist mit dem Code erfolgreich.
- Nur Master-Branch: Achten Sie darauf, alle PRs mit Codeänderungen für den Master-Branch im jeweiligen Verzeichnis zu stellen.
Füllen Sie alle Anforderungen in der Vorlage aus und klicken Sie anschließend auf „Create Pull Requests“ (Pull-Anfragen stellen). Daraufhin sind wir am Zug.
Auswahl und Beschriftung
Wir überprüfen zunächst, ob die PR alle Anforderungen für eine korrekte Anfrage (siehe oben) erfüllt. Falls ja, erhält die PR eine Markierung, um zur weiteren Analyse in den richtigen Händen zu landen. Mögliche Markierungen sind >bug, >feature usw. Sobald die Pull-Anfrage eine Markierung hat, wird sie zur Verarbeitung an das zuständige Unterteam weitergeleitet. Ab diesem Zeitpunkt ist das für den jeweiligen Bereich zuständige Team für die Verarbeitung der Anfrage verantwortlich.
Erste Schritte
Sobald eine PR markiert wurde, kümmert sich ein Entwickler darum. Wir versuchen, uns schnellstmöglich beim Autoren zu melden und bitten Sie um Geduld beim Stellen Ihrer PR. Die korrekte Verarbeitung der Anfrage kann aufgrund der Anzahl und der Komplexität der rund um die Uhr eingehenden Anfragen einige Zeit in Anspruch nehmen.
Übermitteln von Dokumentationsänderungen
Hinweis: Wir erhalten zahlreiche PRs mit Änderungen oder Vorschlägen für Änderungen an unserer Dokumentation. Dieser Prozess ist wesentlich geradliniger als bei Codeänderungen. Klicken Sie auf der jeweiligen Elastic-Dokumentationsseite auf „Edit“ (Bearbeiten), nehmen Sie die Änderungen vor und stellen Sie die Anfrage. In diesem Fall brauchen Sie keinen Fork des Projekts und keine Tests. Diese PRs erhalten von uns die Markierung „>doc“ und werden schnellstmöglich verarbeitet.
Oft gibt es noch mehr zu tun
PRs müssen oft angepasst werden, bevor sie übernommen werden können. An diesem Punkt wird aus der PR ein gemeinschaftlicher Bereich, in dem Diskussionen stattfinden, Änderungen vorgeschlagen und weitere Commits vorgenommen werden.
Während der Überprüfung testen wir die PR, und die Ergebnisse sind in GitHub einsehbar. Manchmal schlägt der Test fehl, wenn die Änderungen in der PR übernommen werden, selbst wenn die übermittelten Tests erfolgreich waren. In diesem Fall ist noch längst nicht alles verloren. Wir helfen den Autoren, ihren vorgeschlagenen Code zu korrigieren, sodass dieser alle Tests besteht.
In dieser Phase achten wir außerdem auf den Codestil sowie auf Code- und Namenskonventionen. Wenn Sie eine Pull-Anfrage an uns stellen, sollten Sie davon ausgehen, dass Ihr Code mindestens einer Überprüfungsrunde unterzogen wird. Kein Code ist perfekt (nein, auch nicht unser Code!) und beim Einsenden bereit für den Merge, daher sollten Sie ein gewisses Maß an Zusammenarbeit erwarten.
Wie lange dauert es, bis meine PR übernommen wird?
Die Verarbeitungsdauer von PRs unterliegt starken Schwankungen. Eine einzelne Codezeile wird möglicherweise schnell verarbeitet, aber komplexe Codeänderungen müssen mehrere Überprüfungsrunden durchlaufen. Falls Sie da Gefühl haben, dass Ihre PR schon zu lange nicht beachtet wurde, können Sie uns gerne als Erinnerung einen Ping für das Ticket senden.
Übernahme des Codes
Wenn alles so weit ist, fügen die Überprüfer einen Kommentar mit ihrer Genehmigung hinzu, etwa ein LGTM-Kommentar (Looks good to me, meiner Ansicht nach in Ordnung) oder eine ähnliche Anmerkung. Nachdem die PR akzeptiert wurde, führt ein Elastic-Entwickler die Pull-Anfrage mit dem Master-Branch zusammen und verteilt die Änderung bei Bedarf an die Entwicklungs-Branches.
So funktioniert also unser Verfahren, kurz gesagt. Natürlich sind nicht alle Pull-Anfragen gleich. Das Verfahren kann sehr einfach oder auch sehr komplex sein. Wenn Sie unser Verfahren näher kennenlernen möchten, krempeln Sie also die Ärmel hoch und stürzen Sie sich kopfüber in den Code.
Sind Sie bereit, Ihre erste PR zu stellen? Sehen Sie sich die Elastic-Repositorys auf GitHub an, machen Sie sich mit den Richtlinien vertraut und legen Sie los. Falls Sie weitere Fragen zu diesem Verfahren haben, besuchen Sie unsere Diskussionsforen und erstellen Sie ein Thema. Wir helfen Ihnen gerne.