Ingeniería de lanzamiento de Lean Software (aplicación web)

Question

Estoy buscando reorganizar la forma en que lanzamos nuestro software interno. Todo el código (PHP webapps, algunas aplicaciones Java y scripts de Perl) se registra en los repositorios de Subversion, pero no hay ramas ni etiquetas, todo se registra en el tronco (solo alrededor de 1-3 desarrolladores por aplicación). En los servidores de producción de Linux, el software se ejecuta directamente desde una copia svn de trabajo (en realidad, la mayoría de los cambios también ocurren allí).

Ya que tenemos muchas aplicaciones pequeñas y lanzamos pequeños cambios al sistema en ejecución, estoy buscando una forma muy ágil o transparente de hacer una ingeniería de lanzamiento y limpiar este problema.

¿Hay alguna herramienta por ahí que pueda ayudarme a hacerlo en un entorno heterogéneo (de lenguaje) como ese? ¿O alguien tiene una idea de cómo hacer esto de manera adecuada?

De lo contrario, habría pensado en escribir algunos scripts de lanzamiento (shell) que crean automáticamente etiquetas de subversión desde el tronco y luego hacen una verificación de la etiqueta correspondiente a los servidores de producción. Pero eso también me suena un poco hack'ish.

Gracias,

Haes.

Answer 1

La integración continua es definitivamente el camino a seguir, cualquier CI (incluso los archivos de lotes minimalistas) es mejor que ninguno, pero solo será tan bueno como las políticas que tenga implementadas. Dado que sus archivos realmente no terminan como 'binarios' o 'distribuibles', marcar una versión podría requerir simplemente que marque el repositorio, o incluso simplemente esconder el número de revisión de Subversion en alguna parte. La política importante que necesita es que cualquier versión puede reconstruirse siempre que la necesite, de modo que pueda comparar las versiones actuales y anteriores, o volver a una versión anterior si algo sale mal. No se preocupe por la "sobrecarga" de crear etiquetas en svn, eso es muy eficiente.

Un script de lanzamiento que hace la etiqueta de subversion suena bien. Una implementación de CI (recomendaría CruiseControl ya que es ideal para trabajo heterogéneo, aunque la heterogeneidad requiere un poco más de sobrecarga de configuración) es excelente, ya que puede iniciar el proceso automáticamente en un registro de subversión y ejecutar pruebas automatizadas que determinan si es bueno suficiente para etiquetar o no.

Definitivamente no implementaría automáticamente en un servidor de lanzamiento. Un 'área de preparación' (llámela 'construcción nocturna', 'prueba beta', lo que sea) sería mejor. Deje que los usuarios lo aprovechen antes de que decida que es lo suficientemente bueno como para implementarlo en los servidores de producción. Y, siempre que tenga la política en lugar de poder revertir a una versión anterior, ha mitigado la posibilidad de un mal despliegue.

La comprobación automática en los servidores de producción es la única parte "pirata": una implementación, comprobación, etiquetado, implementación beta automatizada es lo suficientemente inteligente. Sin embargo, el despliegue a producción no debería tener un botón fácil.

Answer 2

Usa etiquetas y ramas; Que sea parte del ciclo de desarrollo. Al actualizar ese " stable-1.0 " Branch, ha probado el (los) cambio (s) y lo etiquetó "release-1.0.5", simplemente debes hacer clic en " svn switch " en el servidor a la nueva etiqueta. ¿No funcionó, a pesar de haberlo probado? Cambia de nuevo y averigua qué está mal.

Pero cuidado, bifurcarse en subversión puede ser una molestia, al menos en la versión 1.5. Si usted o sus desarrolladores no tienen experiencia con sucursales, espere un poco de molestia y / o errores al principio. Pero siempre y cuando no hayas cometido ningún código, debes perderlo (en el peor de los casos es simplemente difícil de fusionar).

Sus desarrolladores realmente deberían aprender a usar la ramificación; Puede ser muy útil para una variedad de propósitos (no solo para la ingeniería de versiones).

No not cambia automáticamente el código en sus servidores de producción; alguien podría golpear accidentalmente el botón equivocado. Las actualizaciones de producción siempre deben hacerse con cuidado. Las secuencias de comandos para agregar nuevas etiquetas son, por supuesto, innecesarias debido a su simplicidad, pero su millaje puede variar.

Una última cosa, no permita que nadie tenga cambios en su servidor de producción. Puede causar conflictos, y estos tienden a tomar tiempo para resolverlos. Sin mencionar que destruye tu capacidad de reproducir una versión determinada en diferentes estaciones de trabajo (¡funciona bien aquí! ¿Por qué no en el servidor? Hmm).

Answer 3

Algunos servidores de integración continua hacen este tipo de cosas, Hudson , por ejemplo, tiene integración de subversión. Puede etiquetar, ejecutar pruebas y desplegar por usted.

Answer 4

Yo usaría Hudson. además de obtener y etiquetar en svn (ref sblundy), puede ser útil en la administración de lanzamientos con el adecuado complementos . Por ejemplo, puedes probar un complemento para " promover " ; las compilaciones que implementa en producción, y mantiene una lista de las compilaciones promovidas en sí mismas y un registro de cambios / confirmaciones para las distintas versiones.