Ein Upgrade von Drupal 6 Drupal 7: Praktiken der besten Programmierer?

StackOverflow https://stackoverflow.com/questions/1750972

Frage

Obwohl ich Drupal verwende seit der D4-Serie, ich nur angefangen professionell für sie mit D6 entwickeln, so - trotz ich verschiedenen Website-Upgrades habe - ich war nie von der Aufgabe, konfrontiert, die in dem Hafen meines eigener Code auf eine neue Version.

Ich weiß, die Drupal-Community mit vielen technischen Support über veränderte API und architektonische Veränderungen kommt (siehe die Totholz Modul für D5-D6 oder sogar diese Stubs von D6-D7 wie-zu für Module und Themen ).

Doch was ich suche mit meiner Frage ist in der Linie des Strategie Denkens , oder in anderen Worten, Ich suche Eingänge und Ratschläge, wie Plan / Arbeitsgeräte / Bewertung des Prozesses meinen eigenen Code portieren , im Lichte dessen, was Kollege Entwickler von früheren Erfahrungen gelernt. Einige Beispiele:

  1. würden Sie Ratschläge zu portieren meine Module so schnell zu beginnen, wie ich Zeit, es zu tun haben, und eine gleichzeitige D7 für einige Zeit zu halten (so I „bereit“ für den D-Tag bin) oder würden Sie Ratschläge eher warten Sie auf den Tag, an dem der Port tatsächlich sein wird, unmittelbar bevor und dann ein Upgrade der Module bis D7 und legen Sie die D6-Version?
  2. Nur haben einige meiner Module volle Testabdeckung. Möchten Sie eine Beratung, um eine vollständige Testabdeckung für die D6 Version so alle Tests haben arbeiten, um die D7-Port zu prüfen, oder würden Sie Rat meine Testregie schreiben Zeit bei der Portierung, die D7-Version zu testen?
  3. Haben Sie feststellen, dass ein Early Adopter zu sein, gibt Ihnen einen Vorteil in Bezug auf den neuen Features und eine bessere API oder haben Sie eher feststellen, dass bequemer ist die Umwandlung so zu verzögern, wie die größere Menge an leicht verfügbaren contrib Module zu nutzen?
  4. Haben setzen Sie sich Qualitätsstandards / Bewertungskriterien oder haben Sie gerade die Bar auf „wenn es funktioniert, ich bin glücklich“? Warum? Wenn Sie bestimmte Standards oder Ziele gesetzt, was haben sie, wo / was sie sein? Wie haben sie Ihnen helfen?
  5. Gibt es häufige Fehler, dass Sie in der Vergangenheit erlebt, und dass Sie denken, sind für den D6-D7 Portierung?
  6. ist ein guter Moment Portierung einige Umgestaltung zu tun, oder es wird nur alles komplizierter machen zusammen zu setzen?
  7. ...

Diese Fragen keine erschöpfende Liste, aber ich hoffe, sie geben eine Vorstellung davon, welche Art von Informationen die ich suche. Ich würde eher sagen: was auch immer Sie denken, relevant ist und ich nicht oben aufgeführte Liste ein „Plus“ bekommt! :)

Wenn ich mich nicht habe es geschafft, deutlich genug zum Ausdruck bringen, schreiben Sie bitte einen Kommentar mit der Info denken Sie, dass ich in der Frage hinzufügen sollte. Vielen Dank im Voraus für Ihre Zeit!

PS: Ja, ich weiß ... D7 noch nicht aus, und es wird Monate dauern, bevor wichtige contrib Module aufgerüstet werden ... aber es ist nie zu früh Denken zu beginnen! :)

War es hilfreich?

Lösung

Gute Fragen, also mal sehen:

  1. (wenn starten Portierung)
    Dies hängt sicherlich von der Komplexität der Module zu portieren. Wenn es wirklich komplex / großes ist, könnte es nützlich sein, früh zu beginnen, um schwierige Stellen zu finden, während nicht unter Druck ist. Für kleiner / Standard diejenigen, würde ich versuchen, einen größeren Zeitschlitz zu finden später, wo ich kann Port viele von ihnen in einer Reihe, um die Routine Sachen schnell zu bekommen (und profitierte von der wahrscheinlich verbesserten Dokumentation) gespeichert.

  2. (Testabdeckung)
    Normalerweise würde ich sagen, dass eine gute Testabdeckung, die vor dem Refactoring Start / Portierung sicherlich ratsam wäre. Aber da Drupal-7 führen eine große Veränderung in Bezug auf den Test-Framework, indem es Kern bewegt, würde ich erwarten, dass der Bedarf ohnehin eine erhebliche Menge an Tests neu zu schreiben. Also, wenn es nicht notwendig ist, die Drupal-6-Versionen nach der Migration zu halten, würde ich die Zeit / Mühe sparen und für eine erhöhte Abdeckung nach dem Portierung Ziel hat.

  3. (Early Adopter gegen abwart)
    Mit Drupal seit der Version 4.7 haben wir immer mindestens wartete die erste offizielle Veröffentlichung einer neuen Hauptversion, bevor auch nur zu denken über die Portierung. Mit Drupal 6, warteten wir auf die Ansichten Modul vor unserem ersten Standort Portierung und wir haben noch einige kleinere Projekte auf Drupal-5, wie sie nur gut arbeiten und es wäre schwierig, die zusätzliche Rechnung für unsere Kunden so lange zu rechtfertigen gibt es nach wie vor Wartung / Sicherheitsupdates für sie. Es an einem Tag nur so viel Zeit, und es gibt immer diese Rückstau von Bugs zu beheben, Funktionen hinzuzufügen, etc., so dass ohne Einsatz spielt mit unfertiger Technologie, während es mehr unmittelbar bevor die Dinge zu tun, würde sofort profitieren unsere Kunden. Nun wäre dies sicherlich anders sein, wenn wir eine halten müssen oder mehr ‚offizielle‘ beigetragen Module, wie eine frühe Port bietet wäre eine gute Sache sein.
    Ich bin ein bisschen in der Klemme hier - ein Early Adopter ist sicherlich der Gemeinschaft zugute kommt, wie jemand, der Fehler finden, bevor sie repariert, aber auf der anderen Seite, macht es wenig Geschäftssinn zu kämpfen Stunde um Stunde mit Bugs andere könnten gefunden / behoben haben, wenn Sie würde nur ein bisschen länger gewartet. Solange ich für ein Leben, dies zu tun, muß ich meine Ressourcen sehen, die Gemeinschaft versuchen, ein akzeptables Gleichgewicht zu finden zwischen dem Dienst und profitiert davon: - /

  4. (Qualitätsstandards)
    „Wenn es funktioniert, ich bin glücklich“ gerade nicht schneiden, da ich nicht glücklich sein will für einen Augenblick nur, sondern auch morgen. Also einer meiner Qualitätsstandards ist, dass ich (etwas) sicher sein müssen, dass ich ‚grokked‘ neue Konzepte gut genug, um nicht nur macht die Dinge Arbeit, aber machen sie arbeiten, wie sie sollten. Nun ist dies schwer genauer zu definieren, da es offensichtlich unmöglich ist, zu wissen, ob man ‚es wurde‘ vor ‚bekommt es‘, so dass es zu einem Bauchgefühl / Unterscheidung läuft darauf hinaus, ‚ja, es irgendwie funktioniert‘ vs. ‚yup , das sieht richtig‘, und man muss akzeptieren, dass er ziemlich regelmäßig falsch sein darüber.
    Das sei gesagt, einen bestimmten Punkt, den ich der Suche nach ist ‚intervenieren so früh wie möglich‘. Als Anfänger habe ich oft gezwickt Sachen ‚nach der Tat‘ während der Thematisierung der Bühne, während es viel einfacher gewesen wäre, die ‚fix‘ früher in der Verarbeitungskette mittels eines Hakens oder der anderen anzuwenden. So jetzt, wenn ich bin zu ‚justieren‘ etwas in das Thema Schicht, nehme ich bewusst eine kleine Auszeit zu überprüfen, ob dies nicht mehr sauber gemacht werden / compatible in einen Haken früher. Da erwarte ich Optionen Drupal-7, um noch mehr Einhaken, das ist etwas, was ich mehr Aufmerksamkeit zahlen, da sie in der Regel Konflikte reduziert und plötzlich ‚Sachen zu brechen‘, wenn neue Module hinzugefügt wird.

  5. (häufige Fehler)
    Nun - in erster Linie zu früh Portierung, herauszufinden, danach / in zwischen diesem ein oder mehrere Module benötigt wurden für die neue Version überhaupt nicht oder nur in dev / alpha / frühes Beta-Stadium. Also würde ich sicherstellen, dass zuerst eine vollständig Liste der aktuell verfügbaren / benötigte Module zu erstellen, dessen Zustand der Auflistung der Portierung, zusammen mit einer schnellen Überprüfung ihrer Ausgabe Warteschlangen.
    Abgesehen davon, habe ich bisher immer sehr zufrieden mit den neuen Versionen und die Verbesserungen, und ich freue mich für Drupal-7 wieder.

  6. (Refactoring während der Portierung)
    Man könnte die Portierung sagen ist ein ziemlich großes Refactoring in mir selbst, so gibt es keine Notwendigkeit, von der Umstrukturierung nicht Portierungs verwandte Themen der Komplexität hinzuzufügen. Auf der anderen Seite, wenn Sie bereits zerkleinern sowieso Ihre Module in Stücke müssen, warum nutzen Sie die Gelegenheit nicht eine Generalüberholung zu machen? Ich würde versuchen, eine Linie auf Komplexität basierte ziehen - für große / komplexe Module, würde ich den Port so gerade wie möglich tun, und Refactoring mehr später, wenn nötig. Für kleinere Module, sollte es nicht wirklich wichtig, da die Wahrscheinlichkeit, subtile Bugs einzuführen sollte eher gering sein.

  7. (andere Sachen)
    ... Notwendigkeit, darüber nachzudenken ...

Ok, andere Sachen:

  • Resource benötigt - einige der Drupal-7 Themen gegeben, es sieht aus wie sie wahrscheinlich gehen sind, so sollte dies vor der Portierung kleinere Standorte bewertet werden, die auf einem gemeinsamen / restricted Hosting-Account sitzen

  • Die neuesten Versionen zuerst - Dies ist ziemlich offensichtlich und immer in dem Upgrade-Führer betont, aber dennoch erwähnenswert: Upgrade-Kern und alle Module, um ihre neueste aktuelle Version zuerst bevor sie ein wichtiges Upgrade zu tun, da der Upgrade-Code ist sehr wahrscheinlich auf den neuesten Tabelle / Datenstrukturen ab, korrekt zu arbeiten. In Anbetracht Drupals ‚Stück für Stück‘, ein Schritt zu einer Zeit Update-Strategie, wäre es sehr schwer seinen Upgrade-Code zu implementieren, die andere vor dem Upgrade Staaten und entsprechend gehandelt erkennen würde.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top