Wie verwalte ich die gemeinsame Entwicklung auf einer Drupal-Site?

Ich arbeite mit einem anderen Entwickler auf einer Drupal-Site. Wir haben uns bemüht, einen guten Weg zu finden, um an verschiedenen Teilen der Site gleichzeitig zu arbeiten, ohne uns gegenseitig in die Quere zu kommen. Wir haben versucht, an derselben Entwicklungsinstanz der Site zu arbeiten, aber wir treten uns oft auf die Zehen oder bringen die Site mit einem schlechten Code zum Absturz, sodass die andere nicht mehr weiterarbeiten kann, bis sie behoben ist. Wir sind also umgezogen, um Entwicklungsinstanzen zu trennen. Aber jetzt ist es ein großes Problem, unsere Arbeit in einer einzigen Instanz der Site zusammenzuführen. Grundsätzlich wird alles auf einer freigegebenen Kopie wiederholt.

Das größte Problem, das wir jetzt haben, ist, wie wir Datenbankänderungen zusammenführen und wie wir die Datenbank in unser Versionsverwaltungssystem aufnehmen. Die Dateien sind einfach, verfolgen Sie sie alle (wir verwenden git) und führen Sie unsere Arbeit zusammen, um Konflikte bei Bedarf zu lösen. Mit der Datenbank funktioniert das aber nicht wirklich. Wir können einen SQL-Dump erstellen und diesen in unser Git-Repository aufnehmen, aber wir können die Datenbanken nicht wirklich zusammenführen. Das Features-Modul hilft ein wenig, sodass wir einen Teil unserer Datenbankarbeit in Code exportieren können, der dann versioniert und zusammengeführt werden kann. Allerdings unterstützt nicht einmal alles in der Nähe Features. So...

• Welche Schritte können wir unternehmen, um unsere Datenbankänderungen einfach zusammenzuführen?

• Wie sollten wir die Datenbank versionieren (ist es eine gute Möglichkeit, eine Dump-Datei in git abzulegen)?

• Gibt es Module, die bei einigen dieser Probleme helfen?

• Oder haben wir es nicht geschafft, an derselben Kopie der Site zu arbeiten? (bitte so nein)

Bearbeiten: In den Kommentaren haben wir besprochen, welche Dinge mit Features nicht exportiert werden können, und eine davon war Taxonomies. Es gibt noch eine andere Frage, die sich damit befasst .

Es ist eine Workflow-Änderung, aber Sie sollten sich daran gewöhnen, an einem neuen Speicherauszug der Live-DB zu arbeiten. Es gibt drei Möglichkeiten, Änderungen in die DB zu übernehmen.

1. Eigenschaften. Dies funktioniert nicht für alles, sondern für viele Dinge, die Sie benötigen.
2. Haken aktualisieren. Wenn Features nicht funktionieren, können Sie Dinge in einen Update-Hook eines Moduls, das Sie besitzen, fest einprogrammieren.
3. Manuelle Änderungen. Sparsam verwenden. Einige Dinge kommen für Features oder Update-Hooks nicht von selbst und sind nur viel einfacher manuell zu erledigen. Dies ist ein letzter Ausweg, aber manchmal ist es der einzige piratische Weg.

Falls Sie können. Holen Sie sich mehrmals täglich einen neuen Speicherauszug und testen Sie Ihren Build. Sie sollten weniger Integrationsprobleme haben.

Ich habe eine ähnliche Frage beantwortet und werde sie leicht anpassen, um Ihre Frage hier zu beantworten. Mein Hauptvorschlag ist, dass Sie einen Entwicklungs- / Staging-Server haben, auf dem Codeänderungen häufig (z. B. alle 5 Minuten) mithilfe eines Continuous-Integrationssystems ausgecheckt werden. Auf Ihrem lokalen Computer arbeiten Sie also jeweils nur an einer Funktionsanforderung / einem Fehlerbericht. Dabei müssen Sie sicherstellen, dass Sie diese Aufgabe klar von anderen abgrenzen, an denen möglicherweise Personen arbeiten, und Ihren Teamkollegen mitteilen, dass Sie daran arbeiten (redmine oder andere Bug-Tracking ist großartig für diese). Anschließend werden Änderungen regelmäßig festgeschrieben und ebenso wie Ihre Teamkollegen auf den Entwickler- / Staging-Server heruntergeladen. Idealerweise haben Sie Komponententests in Ihr kontinuierliches Integrationssystem integriert (empfehlen Sie luntbuild oder QuickBuild übrigens, aber Hudson funktioniert auch). Das CI-System oder die Tests können Konflikte, die Sie möglicherweise verursacht haben, automatisch erkennen, sobald Sie Ihren Code einchecken. Wenn Sie Änderungen an Inhalten (ohne Code) vornehmen müssen, tun Sie dies auf dem Entwicklungs- / Staging-Server.

In Bezug auf den Datenbankteil habe ich hier im Grunde genommen zwei Denkschulen übernommen (eine dritte Denkschule, die Datenbankunterschiede macht, werde ich nicht diskutieren, da die Komplexität ziemlich hoch ist).

1) Stellen Sie das Produkt bereit, indem Sie die Produktionsdatenbank löschen und einen mysqldump der Entwicklungsdatenbank importieren. Optional können Sie zuvor ein reguläres Suchen / Ersetzen für alle fest codierten absoluten Links ausführen, die auf die dev-URL im SQL-Dump verweisen. Führen Sie nach dem Import der dev db in prod automatisch SQL-Anweisungen aus (normalerweise über ein Skript), um anschließend alle Einstellungen zu ändern, die für prod anders sind als für dev (z. B. haben Sie in der Variablentabelle möglicherweise einige Verbindungseinstellungen für die Verbindung mit externen Systemen, die Sie benötigen Wechseln Sie zu "point at prod external systems" (anstatt zu "dev version").

2) Verwenden Sie das von budda erwähnte Funktionsmodul für Administratoreinstellungen und das Modul "Knotenexport" für den Export / Import von Inhalten in Kombination mit dem Modul "Alle löschen". Der Workflow ist also:

Verwenden Sie node_export und Features, um Knoten / Features in Dateien zu exportieren. Optional (und hoffentlich) Versionskontrolle. Laden von Dateien auf das Prod-System. Verwenden Sie die Drush- oder Admin-Schnittstelle, um Features zu laden Verwenden Sie drush ne-import oder die Administrationsoberfläche, um die Knoten aus der exportierten Knotendatei zu importieren. Ein Hinweis, ich würde dringend empfehlen, einen Standard-Workflow zu übernehmen, bei dem der Inhalt nur in eine Richtung geht. Entweder Dev -> Prod oder Prod -> Dev (ich bevorzuge diesen).

Ich habe dies getan und mache dies auf einigen großen Systemen mit ziemlich guten Ergebnissen, aber es wird immer viele Möglichkeiten geben, diesen Apfel in Scheiben zu schneiden, je nachdem, welche Methode für Sie am besten geeignet ist.

Obwohl dies eine alte Frage mit einer akzeptierten Antwort ist, glaube ich, dass noch Platz für eine andere ist.

Lassen Sie mich zunächst sagen, dass Features meiner Meinung nach nicht das richtige Werkzeug für diese Aufgabe sind, und dass wir einen alternativen Satz von Werkzeugen vorschlagen werden.

Voraussetzung für die Zusammenarbeit im Team ist ein Staging-Server zum Testen von Entwicklungsversionen des Projekts, der von Ihrem Produktionsserver getrennt ist. Der gesamte Entwicklungscode wird auf dem Staging-Server getestet und nur dann auf den Produktionsserver übertragen, wenn er stabil und bereit für die Bereitstellung ist. Die Entwickler arbeiten jedoch nicht direkt am Staging-Server. Jeder Entwickler arbeitet an seinem eigenen Arbeitsplatz und koordiniert seine Arbeit mit dem Rest des Teams mithilfe einer Versionskontrolle und einer Quellcodeverwaltung (SCM).

Das SCM-System ermöglicht es Teammitgliedern, parallel an verschiedenen Zweigen des Codes zu arbeiten, ohne sich gegenseitig zu stören. Zu Testzwecken wird auf dem Staging-Server nur der Master- Zweig bereitgestellt.

Um die Datenbank zwischen Produktion, Staging und Workstations zu spiegeln, gibt es ein Modul mit dem Namen Sichern und Migrieren , das verwendet werden kann, wenn Sie sich auf einem gemeinsam genutzten Hosting befinden und keine eigene Datenbank verwalten. Wenn Sie Ihren eigenen Datenbankserver verwalten, dies das einzige Projekt auf diesem Server ist und Sie mysql verwenden , sind die folgenden Befehle hilfreich:

Zu entleeren:

mysqldump --all-databases --opt -u root -p > DUMP.sql

Etwas wiederherstellen:

mysql -u root -p < DUMP.sql

Wenn Ihre Datenbank nicht die einzige auf diesem Server ist, erstellenmysqldump Sie ein Skript für eine Version von (oder eine entsprechende Version, wenn Sie MySQL nicht verwenden ), die nur Ihre Datenbanken speichert.

Richten Sie eine Richtlinie so ein, dass es sich bei der Datenbank auf dem Produktionsserver um den Master handelt. Der Staging-Server und die Arbeitsstationen sollten eine Kopie der Produktionsdatenbank sein, nicht umgekehrt.

Beachten Sie, dass Drupal 7 alle Administratoreinstellungen in der Datenbank beibehält. Das bedeutet, dass durch das Spiegeln der Datenbank zwischen Produktionsstandort, Staging-Standort und Arbeitsstationen die Administratoreinstellungen ohne Features migriert werden .

Zum Teilen des Codes:

Die Standardmethode für die gemeinsame Nutzung von Code durch die Mitglieder eines Entwicklungsteams ist die Verwendung des SCM-Systems. Drupal wird standardmäßig mit einem solchen System namens git verwaltet .

Git ermöglicht die Verwendung von lokalen oder Remote-Repositories. Wenn sich die Teammitglieder im selben physischen Bereich befinden, können Sie ein lokales Repository auf Ihrem Staging-Server einrichten. Wenn sie geografisch verteilt sind, können Sie ein Remote-Repository einrichten. Wenn Sie nichts dagegen haben, dass andere Benutzer über Lesezugriff auf Ihren Code in der Entwicklung verfügen , können Sie eine Sandbox bei Drupal.org als Remote-Repository verwenden. Sie können auch einen Projektbereich auf GitHub verwenden . GitHub ist nicht nur ein Repository, sondern enthält auch einige Tools für die Zusammenarbeit und ermöglicht sowohl öffentliche als auch private Repositorys.

Grundsätzlich ermöglicht ein SCM-System den Teammitgliedern, Quellcode und Dokumentation aus dem von den Teammitgliedern gemeinsam genutzten Repository abzurufen und nach der Bearbeitung wieder einzuschieben. Der SCM protokolliert Änderungen und schlägt bei Konflikten (dh wenn jemand versucht, einen Code zu übertragen, der nicht die Änderungen enthält, die von einem anderen Teammitglied übernommen wurden) eine Lösung für diesen Konflikt vor.

In der Regel kommt es bei einer herzlichen Kommunikation über die Aufgabenteilung zwischen den Teammitgliedern nicht zu Konflikten. Mit dem SCM-System werden Konflikte jedoch auch dann beherrschbar, wenn Fehler gemacht werden oder die Kommunikation fehlschlägt.

Es gibt viele Tutorials zum Einstieg in und zur Verwendung von git (GIYF). Zwei, die ich empfehlen werde, sind: die Git-SCM- Website und Pro Git von Scott Chacon.