Mise à niveau de Drupal 6 vers Drupal 7: Les pratiques de meilleur programmeur?

Question

Bien que j'utilise Drupal depuis la série D4, je ne commencé à développer professionnellement pour avec D6, donc - malgré que je l'ai fait diverses améliorations du site - On ne m'a jamais fait face à la tâche de ayant au port mon propre code à une nouvelle version.

Je sais que la communauté Drupal viendra avec beaucoup de soutien technique sur les API de changement et les changements d'architecture (voir module Deadwood pour D5-D6 ou même ces bouts de D6-D7 how-to modules href="http://drupal.org/update/theme/6/7" rel="noreferrer"> et thèmes ).

Mais ce que je cherche ma question est plus dans la ligne de pensée de stratégie , ou en d'autres termes, Je suis à la recherche d'intrants et de conseils sur la façon de planifier / mettre en œuvre / examiner le processus de portage de mon propre code , à la lumière de ce que les développeurs collègue appris par expérience. Quelques exemples:

1. vous conseille de commencer à Port mes modules dès que j'ai le temps pour le faire, et de maintenir une D7 simultanée pendant un certain temps (donc je suis « prêt » pour le jour J) ou vous conseille de plutôt attendre le jour où le port sera en fait imminent et puis mettre à niveau les modules à D7 et déposez la version D6?
2. Seuls quelques-uns de mes modules ont une couverture de test complet. Vous conseille de compléter la couverture de test pour la version D6 afin d'avoir tous les tests de travail pour vérifier le port D7, ou vous conseille d'écrire mon test au moment de diriger le portage, pour tester la version D7?
3. Avez-vous trouvé qu'être un adopteur précoce vous donne un avantage en termes de nouvelles fonctionnalités et de meilleures d'API ou vous ne l'avez trouvé plutôt est plus commode de retarder la conversion de manière à tirer parti de la plus grande quantité de modules contrib facilement disponibles?
4. Avez-vous défini pour vous-même des normes de qualité / critères d'évaluation ou que vous avez défini juste la barre « si ça marche, je suis heureux »? Pourquoi? Si vous définissez certaines normes ou objectifs, qu'est-ce qu'ils où / quoi seront-ils? Comment ont-ils vous aider?
5. Y at-il des pièges communs que vous avez vécu dans le passé et que vous jugez applicable au processus de transfert D6-D7?
6. est le portage un bon moment pour faire un peu de refactoring ou il va tout simplement faire tout plus complexe à remettre ensemble?
7. ...

Ces questions ne sont pas une liste exhaustive, mais j'espère qu'ils donnent une idée de ce genre d'information que je cherche. Je dirais plutôt: tout ce que vous jugez pertinent et je ne l'ai pas la liste ci-dessus obtient un « plus »! :)

Si je ne suis pas parvenu à me exprimer assez clairement, s'il vous plaît poster un commentaire avec les informations que vous pensez que je devrais ajouter à la question. Nous vous remercions d'avance pour votre temps!

PS: Oui, je sais ... D7 est pas encore sorti et il faudra des mois avant que les modules contrib importants seront mis à jour ... mais il est jamais trop tôt pour commencer à penser! :)

Answer 1

Les bonnes questions, donc nous allons voir:

1. (quand commencer le portage) Cela dépend certainement de la complexité des modules au port. S'il y a vraiment plus complexes / grandes, il pourrait être utile de commencer tôt afin de trouver les endroits difficiles sans être sous pression. Pour les plus petits / standard, je vais essayer de trouver un créneau horaire plus tard où je peux le port beaucoup d'entre eux dans une rangée afin d'obtenir les choses de routine mémorisées rapidement (et bénéficier de la documentation probablement améliorée).

2. (couverture de test) Normalement, je dirais que d'avoir une bonne couverture de test avant de commencer refactoring / portage serait certainement souhaitable. Mais étant donné que Drupal 7 introduit un changement majeur en ce qui concerne le cadre de tests en le déplaçant à cœur, je pense la nécessité de réécrire une quantité importante de tests de toute façon. Donc, s'il n'y a pas besoin de maintenir les versions Drupal 6 après la migration, j'économise le temps / la difficulté et le but d'accroître la couverture après le portage.

3. (adopteur précoce par rapport à attendre et voir) En utilisant Drupal depuis la version 4.7, nous avons toujours attendu au moins la première version officielle d'une nouvelle version majeure avant même de penser sur le portage. Avec Drupal 6, nous avons attendu pour le module de vues avant le portage de notre premier site, et nous avons encore quelques petits projets sur Drupal-5, car ils travaillent très bien et il serait difficile de justifier le projet de loi supplémentaire pour nos clients aussi longtemps que il y a encore des correctifs de maintenance / de sécurité pour elle. Il y a tellement de temps dans une journée et il y a toujours cet arriéré de bugs à corriger, ajouter des fonctionnalités, etc., donc pas l'utilisation de jouer avec la technologie inachevée alors qu'il ya des choses plus imminents à faire qui profiterait immédiatement à nos clients. Maintenant, ce serait certainement différent si nous devrions maintenir un ou plusieurs modules ont contribué « officiels », en offrant un port tôt serait une bonne chose.
   Je suis un peu dans une impasse ici - être un adopteur précoce profite certainement de la communauté, comme quelqu'un doit trouver que les bugs avant de pouvoir se fixe, mais d'autre part, il a peu de sens des affaires pour combattre heure après heure avec des bugs d'autres auraient pu trouver / fixe si vous souhaitez simplement attendre encore un peu. Tant que je dois faire pour vivre, je dois regarder mes ressources, en essayant de trouver un équilibre acceptable entre le service de la communauté et qui en bénéficient: - /

4. (normes de qualité) « Si ça marche, je suis heureux » juste ne coupe pas, car je ne veux pas être heureux momentanément seulement, mais aussi demain. Donc, l'un de mes normes de qualité est que je dois être (un peu) certain que je « grokked » de nouveaux concepts assez bien pour ne pas fait que les choses fonctionnent, mais les faire travailler comme ils le devraient. Maintenant, cela est difficile à définir plus précisément, car il est évidemment impossible de savoir si l'on « a obtenu ce » avant « l'obtenir », il se résume à un sentiment / distinction intestinale de « oui, cela fonctionne un peu » contre « yup , qui regarde à droite », et on doit accepter qu'il sera tout à fait régulièrement tort à ce sujet.
   Cela dit, un point particulier, je suis à la recherche est pour « intervenir le plus tôt possible ». En tant que débutant, je étoffe souvent retouché « après le fait » au cours de la phase de thématisation, alors qu'il aurait été beaucoup plus facile d'appliquer la « solution » plus haut dans la chaîne de traitement au moyen d'un crochet ou l'autre. Donc, en ce moment, chaque fois que je suis sur le point de «régler quelque chose dans la couche de thème, je prends volontairement un peu de temps pour vérifier si cela ne peut se faire plus proprement / compatible au sein d'un crochet plus tôt. Comme je l'attends Drupal 7 pour ajouter encore plus d'options d'accrochage, c'est quelque chose que je vais porter une attention particulière à, car elle réduit généralement les conflits et soudain « rupture de choses » lors de l'ajout de nouveaux modules.

5. (pièges) Eh bien - portage surtout au début, savoir après / entre ce qu'un ou plusieurs modules nécessaires n'étaient pas disponibles pour la nouvelle version du tout, ou seulement dans dev / alpha / bêta début de l'état. Donc, je ferais que de compiler un complet liste des modules utilisés / nécessaires en premier lieu, l'inscription de leur état de portage, ainsi que d'une inspection rapide de leurs files d'attente d'émission.
   En plus de cela, je l'ai jusqu'à présent toujours été très satisfait des nouvelles versions et leurs améliorations, et je suis impatient de Drupal 7 à nouveau.

6. (refactoring lors du portage) On pourrait dire que le portage est un refactoring assez grand en lui-même, donc il n'y a pas besoin d'ajouter à la complexité de la restructuration des choses liées non portage. D'autre part, si vous avez déjà vos modules déchiqueter en morceaux, pourquoi ne pas profiter de l'occasion pour en faire une refonte majeure? Je vais essayer de tracer une ligne basée sur la complexité - pour les modules / grands complexes, je ferais le port aussi droit que possible, et Refactor plus tard, le cas échéant. Pour les petits modules, il ne devrait pas vraiment d'importance, comme la probabilité d'introduire des bugs subtils devrait être assez faible.

7. (autres choses) ... besoin d'y penser ...

---

Ok, d'autres choses:

• a besoin de ressources - étant donné certains des fils Drupal 7, on dirait qu'ils sont susceptibles de monter, ce qui devrait être évalué avant le portage des sites plus petits qui sont assis sur un compte d'hébergement partagé / restreint

• Dernières versions d'abord - Celui-ci est assez évidente et toujours souligné dans les guides de mise à niveau, mais néanmoins utile de mentionner: la mise à niveau de base et tous les modules à leur dernière version actuelle avant de faire une mise à jour majeure, car le code de mise à niveau est très probablement dépendre des dernières table / structures de données pour fonctionner correctement. Compte tenu du coup par coup », une étape à une stratégie de mise à jour de temps Drupals, il serait très difficile à mettre en œuvre le code de mise à niveau qui permettrait de détecter différents états de pré-mise à niveau et a agi en conséquence.