Ich muss eine Site zur Versionskontrolle bringen und die kontinuierliche Integrationsumgebung einrichten

Ich bin ein Unternehmer mit einem Drupal 6x-Projekt, das klein genug begonnen hat, um keine Versionskontrolle (pro Entwickler) zu benötigen, aber jetzt bin ich überzeugt, dass es keinen Weg ohne dieses Projekt gibt. Es gibt eine umfangreiche Dokumentation zu JIRA mit gut geschriebenen User Stories, die alles abdecken. Ich habe ein wenig darüber nachgelesen, wie das gemacht werden kann und habe mir folgenden Plan ausgedacht:

1. Trennen Sie den Site-Code mithilfe von Modulen von der Datenbank
   1. Kontext
   2. Eigenschaften
   3. Starker Arm
   4. Profiler
2. Fügen Sie den Code in ein SVN-Repository ein und erstellen Sie eine Staging-Site
3. Erstellen Sie einen Spiegel des Staging-Servers auf dem EC2-Produktionsserver
4. Erstellen Sie Selentests und führen Sie sie mit Saucelabs in der Cloud aus
5. Erstellen Sie mit Elastic Bamboo einen Build-Workflow in JIRA Studio, um automatische Updates auszuführen
6. Aktualisieren und installieren Sie Profile mit Drush Make
7. Aktualisierungen auf dem Produktionsserver ausführen (ich bin nicht sicher, wie)

Zunächst habe ich eine Liste von ca. 50 "Features" erstellt, von denen jedes seine Komponenten (Ansichten, Inhaltstypen, Module usw.) enthält. Dies wird zweifellos eine Herausforderung sein, da die Site etwa ein Dutzend benutzerdefinierte Module und Webdienste enthält, ganz zu schweigen von weiteren Dutzend Instanzen des Inhaltstyps "Anwendung", die benutzerdefinierten Code enthalten (von denen ich die meisten gerne in aktualisierbare Ansichten oder Module konvertiert hätte). . Das Gute ist, dass der Standort noch nicht in Produktion ist, sodass das Risiko immer noch begrenzt ist.

Hat jemand Erfahrung damit? Welche Fallstricke und Einschränkungen kann ich erwarten? Ich würde mich sehr über Vorschläge zur Verbesserung / Korrektur des oben genannten Plans oder über Erkenntnisse oder Ratschläge freuen, die Ihre Experten für mich haben könnten.

Ok, ich werde es versuchen :) Ich werde Ihre Frage nicht vollständig beantworten können, aber vielleicht haben Sie ein paar interessante Hinweise. Beachten Sie, dass meine Nummerierung nicht direkt Ihrer entspricht :)

1. Wie ich bereits im Kommentar erwähnt habe, ist kein Projekt für die Versionskontrolle zu klein. Ich persönlich empfehle Git. Gründe dafür sind die unglaubliche Geschwindigkeit (die Wartezeit in Git wird in Millisekunden und nicht in Sekunden gemessen) und die enorme Menge an Funktionen. Es kann ein bisschen schwierig sein, es herauszufinden, da es komische Namen und Argumente gibt, aber die folgende Dokumentation erklärt viele von ihnen wirklich gut: http://www.eecs.harvard.edu/~cduan/technical/git/ . Ein weiterer Grund ist, dass es jetzt von drupal.org verwendet wird. Wenn Sie also wissen, dass git hilfreich ist, wenn Sie einen Beitrag leisten möchten (Bereitstellen von Patches, Testen von Patches, Freigeben von Modulen usw.).

2. Das heißt, wenn Sie SVN aus irgendeinem Grund verwenden möchten (wie die Integration in Dienste, die Sie verwenden möchten), dann entscheiden Sie sich dafür. SVN funktioniert auch vernünftig und ist viel besser als keine Quellcodeverwaltung. (Es sei denn, Sie fragen Linus Torvalds ..). Außerdem gibt es häufig Möglichkeiten, von einem VCS zu einem anderen zu migrieren, wenn Sie Ihre Meinung ändern. SVN -> Git funktioniert zum Beispiel gut.

3. Drittens nähern Sie sich diesem Schritt für Schritt. Versuche nicht alles auf einmal zu machen. Geben Sie Ihnen (und Ihren Entwicklern) die Zeit, sich mit den neuen Tools vertraut zu machen.

4. Der Wechsel von Drupal 6 zu Drupal 7 ist keine Kleinigkeit. Besonders mit viel benutzerdefiniertem Code. Beachten Sie nur, dass es Unmengen von API-Änderungen und neuen Konzepten gibt (wie das Entity / Field-System), und dass viele der zur Verfügung gestellten Module noch nicht vollständig fertig sind.

5. Deployment Management ist eine der Schwachstellen von Drupal, die sich auch in Drupal 7 nicht wesentlich geändert hat. Wir sind uns des Problems bewusst und die Leute arbeiten hart daran, dieses Problem für Drupal 8 zu lösen: http://groups.drupal.org / build-systems-change-management / cmi . Features etc. helfen, aber es ist kein Wundermittel. Nicht alles kann als Feature exportiert werden.

6. Es gibt auch einige Drupal-spezifische Optionen zum Bereitstellen von Staging- / Produktionsstandorten. Pantheon (noch in der Beta) und Acquia Dev Cloud sind möglicherweise einen Besuch wert.

7. Kontinuierliche Integration, automatisiertes Testen ist wichtig und sehr nützlich , erfordert aber auch Zeit zum Einrichten, Schreiben der Tests und so weiter. Zeit, die Sie möglicherweise zu diesem Zeitpunkt nicht haben. Vor allem automatisierte Tests sind jedoch ein Bereich, in dem es einfach ist, inkrementelle Verbesserungen vorzunehmen. Sobald Sie eine Umgebung eingerichtet haben, in der sie ausgeführt werden können, können Sie nach Bedarf immer mehr Tests schreiben.

Also, hier ist meine Empfehlung für die aktualisierte Frage im Kommentar:

Beenden Sie das Programm und geben Sie es frei, aber verwenden Sie jetzt ein VCS (Versionskontrollsystem) für Drupal 6. Erstellen Sie eine Staging-Umgebung für Ihre Site. Sehen Sie sich an, welche (beitragten) Module Sie verwenden, und prüfen Sie, ob zu diesem Zeitpunkt ein Port für Drupal 7 möglich ist. Unterschätzen Sie nicht die Zeit, die benötigt wird. Beginnen Sie auch damit, den Test- / Bereitstellungsprozess zu verbessern. Beginnen Sie mit dem, von dem Sie glauben, dass es Ihnen die meisten Vorteile / Kosten bringt.

Sie können auch spezifischere Anschlussfragen erstellen oder sich die bereits vorhandenen ansehen. Wie Sie sehen, kann es sehr viel Zeit in Anspruch nehmen, auch nur ein paar Hinweise auf eine solche Frage zu geben.