Arbeite unter Versionskontrolle (git)

Ich muss mit einigen anderen Leuten zusammenarbeiten, um eine Website mit Joomla zu entwickeln. Wir werden unsere persönliche Vorlage erstellen und einige Erweiterungen oder Plugins installieren und möglicherweise ändern. Wir werden in verschiedenen Städten arbeiten und hauptsächlich über das Internet interagieren. Wir werden lokal mit einem zentralen Repository arbeiten, in dem unsere Werke gespeichert werden.

Wir überlegen, was die beste Strategie ist, um unseren Workflow unter Versionskontrolle zu halten. Wir denken darüber nach, Git zu verwenden, aber dann stellen sich einige Fragen:

1. Sollten wir den gesamten Joomla-Ordner verfolgen?
2. Wie wäre es, die Änderung in der Datenbank zu verfolgen?

Ich kann darauf antworten, wie wir bei der Virya Group arbeiten - unser CTO Marco Dings hat diese in einer Reihe von Artikeln niedergeschrieben: http://magazine.joomla.org/issues/issue-apr-2014/item/1842-practical -Entwicklung-3-Projekt .

Wir verwenden Atlassian-Produkte - Jira, Stash, Confluence usw.

Wir richten unsere Arbeitsumgebung als vhost für jedes Projekt ein - wir arbeiten daran, Skripte zu erstellen, damit es schneller geht. Jeder Entwickler hat also seinen eigenen lokalen "Spielplatz", und wir richten dev.clientsite.com, staging.clientsite.com und dann seine Live-Site clientsite.com ein.

Innerhalb des vhost haben wir ein Verzeichnis - vcs - und das Webstammverzeichnis - www.

Wir verwenden PHPStorm, installieren Joomla im Verzeichnis www und ordnen dies mithilfe von Remote-Hosts dem entsprechenden Webstamm auf dev / staging / live zu.

Für den Client wird im Projekt ein Repository eingerichtet. In dieses Repository werden alle Änderungen eingefügt, die sich gegenüber Vanilla Joomla ändern , sowie alle Erweiterungen, die in irgendeiner Weise, Form oder Form geändert werden, einschließlich Vorlagen.

Diese werden symbolisch vom VCS-Verzeichnis zurück in das WWW-Verzeichnis verknüpft. Die Dateien werden also im VCS-Repository "live" angezeigt, sie werden jedoch im WWW-Ordner als verknüpfte Dateien angezeigt.

Wir verwenden WENIGER mit unserer Vorlagenbasis und folgen einer BEM-Struktur, die wir in einem separaten Repository haben. Dies wird für jedes Projekt geklont und als neue Vorlage sym-verknüpft. Alle kundenspezifischen Anpassungen gelten dann nur für dieses Projekt. Wir können jedoch zukünftige Änderungen an allen unseren Projekten problemlos zusammenführen.

Einige Leute werden die Versionskontrolle der gesamten Site durchführen, es hängt wirklich davon ab, was Sie erreichen möchten. Wir sind daran interessiert, was sich ändert, und wir haben die alleinige Kontrolle darüber. Wir erstellen eine customer-custom.css-Datei, die der Kunde ändern kann, aber alles andere ist tabu.

Wir untersuchen die Versionskontrolle der Datenbank. Wir haben mit einigen Optionen herumgespielt, aber noch nichts gefunden, das alle Kriterien erfüllt.

Wir verwenden eine Reihe von Skripten, um alle oben genannten Funktionen zu automatisieren, die wir im Laufe der Zeit entwickeln und optimieren.

Ich hoffe das hilft!

Wir haben einen ähnlichen Workflow wie oben von RCheesly beschrieben verwendet. Ich würde die Atlassian-Produktsuite für das Projektmanagement wärmstens empfehlen. Auf diese Weise können wir Commit-Nachrichten an JIRA-Tickets binden, um einen Prüfpfad in Bitbucket zu hinterlassen. Wir erstellen immer einen Feature-Zweig, dh Feature / Joomla-Update / JIRA-Ticket-Nr., Führen Arbeiten an diesem Zweig durch und testen ihn, bevor wir ihn wieder zum Master zusammenführen und bereitstellen.

Wenn eine neue Funktion nicht betriebsbereit ist, können wir sie in einem separaten Staging-Zweig zusammenführen und für die Vorschau für die Clients bereitstellen. Auf diese Weise können wir vom Master aus saubere Zweige für alle Funktionen erstellen, die in der Zwischenzeit live geschaltet werden müssen. Der Schlüssel, um diese Arbeit zu machen, besteht darin, sicherzustellen, dass sich das Team niemals direkt an den Master oder die Staging-Zweige verpflichtet und alle Arbeiten, die noch nicht fertig sind, in einem eigenen Zweig im Bitbucket-Repository verbleiben.

Wir behalten die gesamte Installation in der Versionskontrolle bei, ignorieren nur Image-Ordner und node_modules. Der Grund dafür liegt in unserem Bereitstellungsprozess. Wir verwenden einen Hook auf unseren aws-Produktions- / Staging-Servern, der den Hauptzweig empfängt und alle Dateiänderungen bereitstellt. Auf diese Weise können wir Updates lokal durchführen, testen und dann bereitstellen.

Unsere lokale Umgebung verwendet Docker und Laradock , was ich sehr empfehlen würde. Obwohl es auf Laravel ausgerichtet ist, bietet es eine großartige Umgebung für jede PHP-basierte Site und ermöglicht es Ihnen, Ihre Produktionsumgebung nachzuahmen, damit Sie sicher aktualisieren können.

Die größte Herausforderung bei dieser Methode war die Datenbank! Zunächst führten wir Aktualisierungen lokal durch, drückten und führten dann dieselben Aktualisierungen auf unseren Servern durch, um sicherzustellen, dass Erweiterungs- / Kernmigrationen in allen Umgebungen durchgeführt wurden. Das ist alles andere als ideal.

Wir haben begonnen, ein CLI-Tool zu verwenden, um diese Aktualisierungen durchzuführen. CLI Helper macht den Prozess etwas zuverlässiger und beschleunigt ihn erheblich. Das ist besser, aber nicht perfekt! Ich würde gerne von jedem hören, der eine bessere Datenbanklösung gefunden hat!