Passer de Drupal 6 à Drupal 7: Les meilleures pratiques des programmeurs?
bien que j'utilise drupal depuis la série D4, Je n'ai commencé à développer professionnellement pour cela qu'avec D6, donc - malgré les différentes mises à niveau du site - je n'ai jamais été confronté à la tâche de avoir à porter mon propre code vers une nouvelle version.
je sais que la communauté Drupal va venir avec beaucoup de soutien technique sur les API modifiées et les changements d'architecture (voir le module deadwood<!-Pour D5-D6 ou même ces talons de D6-D7 pour les modules et les thèmes).
Cependant, ce que je cherche avec ma question est plus dans la ligne de stratégie de la pensée, ou en d'autres termes, je suis à la recherche des entrées et des conseils sur la façon de planifier, mettre en oeuvre et revoir le processus de portage de mon propre code, à la lumière de ce collègue développeurs ont appris par l'expérience antérieure. Quelques exemple:
- auriez-vous des conseils pour commencer pour porter mes modules dès que j'ai le temps de le faire, et pour maintenir un D7 concurrent pendant un certain temps (donc je suis "préparé" pour le Jour J) ou vous conseillez d'attendre plutôt le jour où le port sera effectivement imminente et ensuite mettre à jour les modules en D7 et abandonner la version D6?
- seulement certains de mes modules ont une couverture complète des tests. Auriez-vous l'obligeance de compléter la couverture des tests pour la version D6 afin que tous les tests fonctionnent pour vérifier le portage D7, ou auriez-vous l'obligeance de: conseil pour écrire mon test sur le portage du temps, pour tester la version D7?
- avez-vous trouvé que le fait d'être un adoptant précoce vous donne un avantage en termes de nouvelles fonctionnalités et de meilleures API ou avez-vous plutôt trouvé qu'il est plus pratique de retarder la conversion afin de tirer parti de la plus grande quantité de modules contrib facilement disponibles?
- vous êtes-vous fixé des normes de qualité / des critères d'évaluation ou avez-vous simplement fixé la barre à "si ça marche, je suis heureux"? Pourquoi? Si vous définissez certaines normes ou certains objectifs, où et quels seront-ils? Comment ont-ils vous aider?
- y a-t-il des pièges courants que vous avez rencontrés dans le passé et qui, selon vous, s'appliquent au processus de portage du D6-D7?
- est-ce que Porter est un bon moment pour faire du remaniement ou cela va juste rendre tout plus complexe à remettre en place?
- ...
ces questions ne sont pas une liste exhaustive, mais j'espère qu'elles donnent une idée de quel genre d'information, je suis à la recherche d'. Je préfère dire: tout ce que vous pensez est pertinent et je n'ai pas énuméré ci-dessus obtient un "plus"! :)
si je n'ai pas réussi à m'exprimer assez clairement, veuillez poster un commentaire avec l'information que vous pensez que je devrais ajouter dans la question. Je vous remercie d'avance pour votre temps!
PS: Oui je sais... D7 n'est pas encore disponible et il faudra des mois avant que d'importants modules contrib soient mis à niveau... mais il n'est jamais trop tôt pour commencer à penser! :)
1 réponses
les Bonnes questions, voyons donc:
(quand commencer le portage)
Cela dépend certainement de la complexité des modules de port. S'il y en a vraiment complexes/grandes, il peut être utile de commencer tôt afin de trouver les points délicats tout en n'étant pas sous pression. Pour les petits / standard, j'essaierais de trouver un plus grand créneau horaire plus tard où je peux porter beaucoup d'entre eux dans une rangée afin d'obtenir les trucs de routine mémorisé rapidement (et tirer profit de la documentation probablement améliorée).(couverture de test)
Normalement, je dirais qu'avoir une bonne couverture de test avant de commencer le remaniement/portage serait certainement souhaitable. Mais étant donné que Drupal-7 introduit un changement majeur concernant le cadre de test en le déplaçant vers le noyau, Je m'attendrais à la nécessité de réécrire une quantité significative de tests de toute façon. Donc, s'il n'y a pas besoin de maintenir les versions Drupal-6 après migration, je gagnerais du temps et je viserais à augmenter la couverture après le portage.(adopteur précoce vs 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 au portage. Avec Drupal 6, Nous avons attendu le module views avant de transférer notre premier site, et nous avons encore quelques petits projets sur Drupal-5, car ils fonctionnent juste bien et il serait difficile de justifier la facture supplémentaire pour nos clients tant qu'il y a encore des correctifs de maintenance/sécurité pour elle. Il y a tellement de temps dans une journée et il y a toujours cet arriéré de bogues à corriger, de fonctionnalités à ajouter, etc. donc pas la peine de jouer avec une technologie inachevée alors qu'il y a des choses plus imminentes à faire qui profiteraient immédiatement à nos clients. Maintenant, ce serait certainement différent si nous devions maintenir un ou plusieurs modules "officiels" fournis, comme offrant une port serait une bonne chose.
Je suis un peu dans le pétrin ici - être un adopteur précoce profite certainement à la communauté, car quelqu'un doit trouver que les bogues avant qu'ils ne puissent être corrigés, mais d'un autre côté, il est peu sensé pour les affaires de se battre heure après heure avec des bogues que d'autres pourraient avoir trouvé/corrigé si vous aviez juste attendu un peu plus longtemps. Aussi longtemps que je dois le faire pour gagner ma vie, j'ai besoin de surveiller mes ressources, en essayant de trouver un équilibre acceptable entre servir la communauté et bénéficier :-/(normes de qualité)
"Si cela fonctionne, je suis heureux" ne suffit pas, car je ne veux pas être heureux momentanément seulement, mais demain. Ainsi, l'une de mes normes de qualité est que je dois être (quelque peu) certain que j'ai "grokked" de nouveaux concepts assez bien pour non seulement fait les choses fonctionnent, mais les faire fonctionner comme ils devraient. Maintenant, ce est difficile à définir, plus précisément, comme il est évidemment impossible de savoir si un "voilà" avant de "l'obtenir", de sorte qu'il se résume à un sentiment gut/distinction de "oui, il fonctionne en quelque sorte" vs. "yup, qui semble juste", et on doit accepter qu'il sera assez régulièrement tort à ce sujet.
Cela dit, je suis particulièrement attentif à un point, à savoir "intervenir le plus tôt possible". En tant que débutant, j'ai souvent modifié des choses "après le fait" au cours de la phase de thématisation, alors qu'il aurait été beaucoup plus facile d'appliquer la "correction" plus tôt dans la chaîne de traitement au moyen d'un crochet ou de la autre. Donc maintenant, chaque fois que je suis sur le point d '"ajuster" quelque chose dans la couche de thème, je prends délibérément un petit moment pour vérifier si cela ne peut pas être fait plus proprement/compatible dans un crochet plus tôt. Comme je m'attends à ce que Drupal-7 ajoute encore plus d'options d'accrochage, c'est quelque chose à quoi je prêterai une attention supplémentaire, car il réduit généralement les conflits et la 'rupture de substance' soudaine lors de l'ajout de nouveaux modules.(pièges)
Bien principalement portage au début, par la suite/entre un ou plusieurs modules nécessaires n'étaient pas disponibles pour la nouvelle version à tous, ou seulement dans dev/alpha/beta début de l'état. Donc, j'avais assurez-vous de compiler un complet liste des modules utilisés/nécessaires en premier, énumérant leur état de portage, ainsi qu'une inspection rapide de leurs files d'attente.
En plus de cela, je l'ai toujours été jusqu'à présent!--5-->très satisfait des nouvelles versions et de leurs améliorations, et j'attends avec impatience Drupal-7 encore.(refactoring lors de portage)
On pourrait dire que le portage est un remaniement assez important en soi, de sorte qu'il n'est pas nécessaire d'ajouter à la complexité en restructurant les choses non liées au portage. D'un autre côté, si vous avez déjà à déchiqueter vos modules en morceaux, pourquoi ne pas en profiter pour en faire une révision majeure? J'essaierais de tracer une ligne basée sur la complexité - pour les grands / complexes modules, je ferais le port comme droite que possible, et refactoriser plus tard, si besoin. Pour les modules plus petits, cela ne devrait pas vraiment avoir d'importance, car la probabilité d'introduire des bogues subtils devrait être plutôt faible.(d'autres trucs)
... besoin d'y penser ...
Ok, d'autres choses:
besoins en ressources-étant donné certains des fils Drupal-7, Il semble qu'ils vont probablement monter, donc ceci devrait être évalué avant de transférer de plus petits sites qui se trouvent sur un compte d'hébergement partagé/restreint.
les dernières versions d'abord - celle-ci est assez évidente et toujours soulignée dans les guides de mise à niveau, mais mérite néanmoins d'être mentionnée: mettre à niveau le noyau et tous les modules à leur dernière version actuelle avant de faire une mise à niveau majeure, car le code de mise à niveau est très susceptible de dépendre des dernières structures de table/données pour fonctionner correctement. Étant donné que les Drupales "au coup par coup", un pas à dans le cadre d'une stratégie de mise à jour temporelle, il serait très difficile de mettre en œuvre un code de mise à niveau qui détecterait différents états avant la mise à niveau et qui agirait en conséquence.