Actualización de Drupal 6 a Drupal 7:¿Las mejores prácticas del programador?

Question

Aunque estoy usando drupal desde la serie D4, solo comencé a desarrollar profesionalmente con D6, por lo que, a pesar de que hice varias actualizaciones del sitio, nunca me enfrenté a la tarea de tener que portar mi propio código a una nueva versión.

Sé que la comunidad Drupal ofrecerá mucho soporte técnico sobre API modificadas y cambios arquitectónicos (consulte el módulo de madera muerta para D5-D6 o incluso estos resúmenes de instrucciones de D6-D7 para módulos y temas).

Sin embargo, lo que busco con mi pregunta está más en la línea de pensamiento estratégico, o en otras palabras, Estoy buscando aportes y consejos sobre cómo planificar/implementar/revisar el proceso de portar mi propio código., a la luz de lo que los colegas desarrolladores aprendieron a través de experiencias anteriores.Algún ejemplo:

1. ¿Me recomendaría comenzar a portar mis módulos tan pronto como tenga tiempo para hacerlo y mantener un D7 simultáneo durante algún tiempo (así estoy "preparado" para el día D) o me aconsejaría esperar a que llegue el día D? día en que el puerto estará efectivamente inminente ¿Y luego actualizar los módulos a D7 y eliminar la versión D6?
2. Sólo algunos de mis módulos tienen una cobertura de prueba completa.¿Recomendaría completar la cobertura de prueba para la versión D6 para que todas las pruebas funcionen para verificar el puerto D7, o recomendaría escribir mi dirección de prueba en el momento de la transferencia, para probar la versión D7?
3. ¿Descubrió que ser uno de los primeros en adoptarlo le brinda una ventaja en términos de nuevas funciones y mejores API o prefiere que sea más conveniente retrasar la conversión para aprovechar la mayor cantidad de módulos de contribución disponibles?
4. ¿Se ha fijado usted mismo estándares de calidad/criterios de evaluación o simplemente ha fijado el listón en "si funciona, estoy contento"?¿Por qué?Si establece ciertos estándares u objetivos, ¿cuáles fueron y cuáles serán?¿Cómo te ayudaron?
5. ¿Existen errores comunes que haya experimentado en el pasado y que cree que son aplicables al proceso de transferencia D6-D7?
6. ¿La portabilidad es un buen momento para hacer algo de refactorización o simplemente hará que todo sea más complejo para volver a armarlo?
7. ...

Estas preguntas no son una lista exhaustiva, pero espero que den una idea del tipo de información que estoy buscando.Prefiero decir:¡Todo lo que creas que es relevante y que no mencioné anteriormente obtiene un "plus"!:)

Si no logré expresarme con suficiente claridad, publique un comentario con la información que cree que debería agregar en la pregunta.¡Gracias de antemano por su tiempo!

PD:Sí, lo sé...D7 aún no está disponible y pasarán meses antes de que se actualicen importantes módulos de contribución...¡Pero nunca es demasiado pronto para empezar a pensar!:)

Answer 1

Buenas preguntas, así que veamos:

1. (cuándo comenzar a portar)
   Esto ciertamente depende de la complejidad de los módulos a portar.Si hay problemas realmente complejos/grandes, podría ser útil empezar temprano para encontrar puntos difíciles sin estar bajo presión.Para los más pequeños/estándar, intentaría encontrar un intervalo de tiempo más grande más adelante donde pueda transferir muchos de ellos seguidos para memorizar las cosas de rutina rápidamente (y beneficiarme de la documentación probablemente mejorada).

2. (cobertura de prueba)
   Normalmente, diría que sería aconsejable tener una buena cobertura de prueba antes de comenzar la refactorización/portación.Pero dado que Drupal-7 introduce un cambio importante con respecto al marco de pruebas al moverlo al núcleo, de todos modos esperaría la necesidad de reescribir una cantidad significativa de pruebas.Entonces, si no hay necesidad de mantener las versiones de Drupal-6 después de la migración, ahorraría tiempo y problemas y buscaría una mayor cobertura después de la migración.

3. (early adopter vs.espera y verás)
   Usando Drupal desde la versión 4.7, siempre hemos esperado al menos el primer lanzamiento oficial de una nueva versión principal antes de siquiera pensar en migrar.Con Drupal 6, esperamos el módulo de vistas antes de portar nuestro primer sitio, y todavía tenemos algunos proyectos más pequeños en Drupal-5, ya que están funcionando bien y sería difícil justificar la factura adicional para nuestros clientes mientras todavía hay correcciones de mantenimiento/seguridad para ello.Hay mucho tiempo en un día y siempre hay una acumulación de errores que corregir, características que agregar, etc., por lo que no sirve de nada jugar con tecnología inacabada mientras hay cosas más inminentes que hacer que beneficiarían inmediatamente a nuestros clientes.Ahora bien, esto ciertamente sería diferente si tuviéramos que mantener uno o más módulos contribuidos "oficiales", ya que ofrecer una adaptación temprana sería algo bueno.
   Estoy un poco en apuros aquí: ser uno de los primeros en adoptar ciertamente beneficia a la comunidad, ya que alguien tiene que encontrar los errores antes de poder solucionarlos, pero por otro lado, no tiene mucho sentido comercial luchar hora tras hora con errores. otros podrían haberlo encontrado/solucionado si hubieras esperado un poco más.Mientras tenga que hacer esto para ganarme la vida, necesito cuidar mis recursos, tratando de lograr un equilibrio aceptable entre servir a la comunidad y beneficiarme de ella :-/

4. (normas de calidad)
   "Si funciona, soy feliz" simplemente no es suficiente, ya que no quiero ser feliz sólo momentáneamente, sino también mañana.Entonces, uno de mis estándares de calidad es que necesito estar (algo) seguro de haber asimilado los nuevos conceptos lo suficientemente bien para no sólo hacer que las cosas funcionen, sino también hacer que funcionen como deberían.Ahora bien, esto es difícil de definir con mayor precisión, ya que es obviamente imposible saber si uno "lo entendió" antes de "entenderlo", por lo que se reduce a una intuición/distinción de "sí, funciona" vs.'sí, eso parece correcto', y hay que aceptar que con bastante frecuencia se equivocará al respecto.
   Dicho esto, un punto particular al que estoy atento es "intervenir lo antes posible".Como principiante, a menudo modificaba cosas "después del hecho" durante la etapa de tematización, mientras que hubiera sido mucho más fácil aplicar la "solución" antes en la cadena de procesamiento por medio de un gancho u otro.Entonces, ahora mismo, cada vez que estoy a punto de 'ajustar' algo en la capa del tema, deliberadamente me tomo un poco de tiempo para verificar si esto no se puede hacer de manera más limpia/compatible dentro de un gancho anteriormente.Como espero que Drupal-7 agregue aún más opciones de enlace, esto es algo a lo que prestaré especial atención, ya que generalmente reduce los conflictos y la "rotura repentina de cosas" al agregar nuevos módulos.

5. (errores comunes)
   Bueno, principalmente la migración temprana, descubriendo después/en el medio que uno o más módulos necesarios no estaban disponibles para la nueva versión en absoluto, o solo en estado de desarrollo/alfa/beta temprana.Así que me aseguraría de compilar un completo primero una lista de módulos usados/necesarios, enumerando su estado de portabilidad, junto con una inspección rápida de sus colas de problemas.
   Además de eso, hasta ahora siempre he sido muy Estoy satisfecho con las nuevas versiones y sus mejoras, y espero con ansias Drupal-7 nuevamente.

6. (refactorización durante la portabilidad)
   Se podría decir que la portabilidad es una refactorización bastante grande en sí misma, por lo que no hay necesidad de aumentar la complejidad reestructurando cosas no relacionadas con la portabilidad.Por otro lado, si de todos modos ya tienes que destrozar tus módulos, ¿por qué no aprovechar la oportunidad para realizar una revisión importante?Intentaría trazar una línea basada en la complejidad: para módulos grandes/complejos, haría el puerto lo más directo posible y lo refactorizaría más adelante, si fuera necesario.Para módulos más pequeños, realmente no debería importar, ya que la probabilidad de introducir errores sutiles debería ser bastante pequeña.

7. (otras cosas)
   ...hay que pensarlo...

---

Bueno, otras cosas:

• Necesidades de recursos: dados algunos de los subprocesos de Drupal-7, parece que es probable que aumenten, por lo que esto debe evaluarse antes de migrar sitios más pequeños que se encuentran en una cuenta de hosting compartida/restringida.

• Las últimas versiones primero: esta es bastante obvia y siempre se destaca en las guías de actualización, pero vale la pena mencionarla:Primero actualice el núcleo y todos los módulos a su última versión actual antes de realizar una actualización importante, ya que es muy probable que el código de actualización dependa de las últimas estructuras de tablas/datos para funcionar correctamente.Dada la estrategia de actualización 'poco a poco' de Drupal, paso a paso, sería muy difícil implementar un código de actualización que detectara diferentes estados previos a la actualización y actuara en consecuencia.