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


41

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í.


Es una pregunta muy interesante. Eso es algo que pensé implementar también en mi sitio web, pero lo dejé porque no parecía eficiente. Si sigue adelante, por favor denos su opinión.
Tivie

3
Definitivamente una pregunta interesante, pero también difícil de responder. Estás haciendo múltiples preguntas, por lo que es difícil darte una respuesta completa / mejor. Solo una pista: en mi humilde opinión, ningún proyecto es demasiado pequeño para el control de versiones. Especialmente ahora con VCS distribuido como git, se necesitan 5 segundos para colocar su código en un repositorio local. Ver también drupal.stackexchange.com/questions/316/…
Berdir

En retrospectiva, de hecho, ningún proyecto es demasiado pequeño para el control de versiones (si solo lo supiera entonces). Revisé ese enlace y me trae otra pregunta importante. Si vamos a extraer el núcleo de Drupal de su propio repositorio de git, ¿deberíamos usar git para proyectos de Drupal en lugar de SVN? La razón por la que estamos usando SVN es porque hay un soporte nativo en JIRA Studio, lo cual es importante para nosotros dado que queremos usar las funciones de compilación automatizadas de JIRA (Elastic Bamboo). Perdón por las múltiples preguntas :-(
druflex

ACTUALIZACIÓN: Después de una revisión de código, se determinó que hay mucho código personalizado en el proyecto, lo que será realmente difícil de exportar utilizando características. Entonces, las opciones que tenemos frente a nosotros son: (1) Finalizar y lanzar como está, y comenzar el desarrollo paralelo en D7 usando el control de versión adecuado. Esto significa disputar la base de datos más tarde. De miedo. (2) Rehaga las funciones esenciales en D6, lance, luego haga la Integración continua. (3) Rehaga las funciones esenciales en D7, lance, luego haga la Integración continua. La pregunta principal es cuánto tiempo llevará cada una de estas opciones. Si fueras yo, ¿por qué votarías?
druflex

Respuestas:


23

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.


Muchas gracias por una gran respuesta integral. Estoy bastante decidido sobre exactamente lo que me recomiendan. Incluso incluyendo a Git en realidad. Moveré JIRA de alojado a independiente para poder usar el complemento Git. Entonces D6 lo es. Libere la versión actual ahora y comience a volver a crear una copia adecuada de las mejores prácticas en paralelo, utilizando la mayor cantidad de código existente posible. Gracias de nuevo por el apoyo. ¡Aclamaciones!
druflex

+1 Buen consejo, integral, realista y real. Estás hablando por experiencia. Gracias.
therobyouknow
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.