Necesito llevar un sitio al control de versiones y configurar el entorno de integración continua

Soy un emprendedor con un proyecto Drupal 6x que comenzó lo suficientemente pequeño como para no necesitar control de versiones (por desarrolladores), pero ahora estoy convencido de que no hay forma de hacerlo sin él. Hay una extensa documentación sobre JIRA, completa con historias de usuarios bien escritas que cubren todo. Leí un poco sobre cómo se podría hacer esto y se me ocurrió el siguiente plan:

1. Separe el código del sitio de la base de datos utilizando módulos
   1. Contexto
   2. Caracteristicas
   3. Brazo fuerte
   4. Profiler
2. Ponga el código en un repositorio SVN y cree un sitio provisional
3. Cree un espejo del servidor provisional en el servidor de producción EC2
4. Cree pruebas de Selenium y ejecútelas en la nube usando Saucelabs
5. Cree un flujo de trabajo de compilación en JIRA Studio usando Elastic Bamboo para ejecutar actualizaciones automáticas
6. Actualice e instale perfiles con Drush Make
7. Ejecutar actualizaciones en el servidor de producción (no estoy seguro de cómo)

Para empezar, hice una lista de aproximadamente 50 "Características", cada una con sus componentes (vistas, tipos de contenido, módulos, etc.). Sin duda, esto será un desafío ya que el sitio contiene alrededor de una docena de módulos personalizados y servicios web, sin mencionar otra docena de instancias de tipo de contenido "aplicación" que contiene código personalizado (la mayoría de los cuales me gustaría convertir a vistas o módulos actualizables) . Lo bueno es que el sitio aún no está en producción, por lo que el riesgo aún es limitado.

¿Alguien tiene alguna experiencia en hacer algo similar? ¿Qué trampas y limitaciones debo esperar encontrar? Le agradecería cualquier sugerencia para mejorar / corregir el plan anterior, o cualquier idea o consejo que sus expertos puedan tener para mí.

Ok, intentaré esto :) No podré responder completamente tu pregunta, pero tal vez te dé algunas pistas interesantes. Tenga en cuenta que mi numeración no responde directamente a la suya :)

1. Como ya mencioné en el comentario, ningún proyecto es demasiado pequeño para el control de versiones. Yo personalmente recomiendo a Git. Las razones son su increíble velocidad (el tiempo de espera en git se mide en milisegundos, no segundos) y la gran cantidad de funciones. Puede ser un poco difícil de entender, debido a nombres y argumentos extraños, pero la siguiente documentación explica que muchos de ellos son realmente buenos: http://www.eecs.harvard.edu/~cduan/technical/git/ . Otra razón es que ahora lo usa drupal.org, por lo que conocer git lo ayudará cuando quiera contribuir (proporcionando parches, parches de prueba, módulos de lanzamiento, ...)

2. Dicho esto, si desea usar SVN por alguna razón (como la integración con los servicios que planea usar), hágalo. SVN también funciona razonablemente bien y es mucho mejor que ningún control de fuente. (A menos que le preguntes a Linus Torvalds ..). Además, a menudo hay formas de migrar de un VCS a otro si cambia de opinión. SVN -> Git funciona bien, por ejemplo.

3. En tercer lugar, aborda este paso a paso. No intentes hacer todo de una vez. Le damos a usted (y a sus desarrolladores) el tiempo para aprender las nuevas herramientas.

4. Cambiar de Drupal 6 a Drupal 7 no es algo trivial. Especialmente con mucho código personalizado. Tenga en cuenta que solo hay toneladas de cambios de API y nuevos conceptos (como el sistema de entidad / campo), también existe el punto de que muchos módulos contribuidos aún no están completamente listos.

5. La administración de la implementación es uno de los puntos débiles de Drupal, que tampoco ha cambiado mucho en Drupal 7. Somos conscientes del problema y la gente está trabajando arduamente para resolver esto para Drupal 8: http://groups.drupal.org / build-systems-change-management / cmi . Características, etc. ayuda, pero no es una bala de plata. No todo se puede exportar como una característica.

6. También hay algunas opciones específicas de Drupal para implementar sitios de preparación / producción. Vale la pena echarle un vistazo a Pantheon (todavía en beta) y Acquia Dev Cloud .

7. La integración continua, las pruebas automatizadas son importantes y realmente útiles, pero también requieren tiempo para configurar, escribir las pruebas, etc. Tiempo que puede o no tener en este momento. Pero especialmente las pruebas automatizadas es un área donde es fácil hacer mejoras incrementales. Una vez que tenga un entorno configurado para ejecutarlos, puede escribir más y más pruebas según lo permita el tiempo.

Entonces, aquí está mi recomendación para la pregunta actualizada en el comentario:

Termine y suelte como está, pero comience a usar un VCS (sistema de control de versiones) para Drupal 6 ahora. Cree un entorno de ensayo para su sitio. Mire qué módulos (contribuidos) está utilizando y verifique si un puerto a Drupal 7 es factible en ese momento. No subestimes el tiempo que tomará. También comience a mejorar el proceso de prueba / implementación, comenzando con lo que cree que le brindará los mayores beneficios / costos.

También puede crear preguntas de seguimiento más específicas o buscar las que ya existen. Como puede ver, incluso dar solo algunas pistas a una pregunta como esta puede volverse enorme y tomar bastante tiempo.