¿Cómo estructuro el código y las compilaciones para la entrega continua de múltiples aplicaciones en un equipo pequeño?

7

Background:

3-5 desarrolladores que admiten (y crean nuevas) aplicaciones internas para una empresa que no es de software. Utilizamos TFS, aunque no creo que eso importe mucho para mi pregunta.

Quiero poder desarrollar un canal de implementación y adoptar técnicas de integración / implementación continua.

Así es como se ve nuestro árbol de fuentes en este momento. Utilizamos un solo proyecto de equipo TFS.

$/MAIN/src/
$/MAIN/src/ApplicationA/VSSOlution.sln
$/MAIN/src/ApplicationA/ApplicationAProject1.csproj
$/MAIN/src/ApplicationA/ApplicationAProject2.csproj
$/MAIN/src/ApplicationB/...
$/MAIN/src/ApplicationC
$/MAIN/src/SharedInfrastructureA
$/MAIN/src/SharedInfrastructureB

Mi objetivo (un canal de promoción bastante típico)

  1. Cuando se realiza un cambio de código en una aplicación determinada, quiero poder compilar esa aplicación y desplegar automáticamente ese cambio en un servidor DEV.

    • También es posible que deba crear dependencias en los componentes de infraestructura compartida.
    • A menudo también tengo algunos scripts o cambios en la base de datos
  2. Si las pruebas de desarrollo pasan, quiero tener una implementación automática pero activada de esa compilación en un servidor STAGING donde los usuarios finales revisarán nuevas funciones.

  3. Una vez que haya sido aprobado por los usuarios finales, quiero un despliegue automático activado manualmente en producción

Pregunta :

¿Cómo puedo adoptar las mejores técnicas de implementación continua en un entorno de múltiples aplicaciones? Muchos de los consejos que veo son más específicos de una sola aplicación, ¿cómo se aplica mejor a múltiples aplicaciones?

  • Para el paso 1, ¿simplemente configuro un Team Build separado para cada aplicación?

  • ¿Cuál es el mejor enfoque para lograr los pasos 2 y 3 de promover la última compilación a nuevos entornos?

  • He visto que esto funciona bien con las aplicaciones web, pero ¿qué hay de los cambios en la base de datos?

pregunta kingdango 08.11.2012 - 19:45

3 respuestas

2

Creo que Jenkins CI debería ayudarte a lograr lo que quieres.

  • También puede administrar las dependencias entre diferentes aplicaciones utilizando los complementos de acción de compilación pre / post de Jenkins.
  • El complemento Build Pipeline lo ayudará a administrar la canalización. El último complemento permite "reintentar", lo que debería ayudarte a volver rápidamente a las versiones anteriores si lo deseas.
  • No he usado TFS, pero parece que Jenkins tiene complemento TFS disponible.

Sobre las migraciones de la base de datos, se debe realizar la versión del DB de la versión, de esa manera puede implementar un script de migración junto con el despliegue.

Jenkins + Build Pipeline ha estado funcionando bien para mí durante mucho tiempo. Estas eran principalmente aplicaciones web pequeñas / medianas complejas. Lo he probado para pequeñas aplicaciones de iOS y Android también.

    
respondido por el leenasn 09.11.2012 - 06:58
2

Muchos sistemas de CI, como teamcity o jenkins, pueden configurarse para monitorear su sistema de control de versiones y comenzar las compilaciones cuando se detectan los registros. La secuencia de eventos iniciada por el sistema de CI a menudo es así:

  1. Si la compilación se completa sin errores, se ejecutan las pruebas unitarias.
  2. Si la prueba de la unidad se completa sin fallas, la compilación se implementa en la etapa
  3. Si la implementación del servidor de ensayo es exitosa, se ejecutan las pruebas de integración (en esta etapa, las personas pueden conectarse al servidor de almacenamiento y también asegurarse de que el sistema esté funcionando)
  4. Si la integración prueba todas las pasadas, la compilación se copia al área de "buena compilación"
  5. Una persona puede desplegar la "buena compilación" a voluntad

Con respecto a los cambios en la base de datos, durante el proceso de implementación se podría restaurar una copia de seguridad de los datos en el servidor de ensayo y, a continuación, se podría iniciar un proceso de migración de la base de datos. Las pruebas de integración deberían detectar los problemas de migración y alertarle de que hubo problemas con la implementación en la fase de almacenamiento, lo que no permitiría la copia al área de "buenas compilaciones".

    
respondido por el Nathan Pilling 09.11.2012 - 02:34
0

En una empresa en la que trabajé hace unos años, teníamos TFS 2008 y manejábamos implementaciones mediante etiquetas de compilación y un flujo de trabajo de WF. Cuando una etiqueta de compilación cambia, un desencadenador implementaría la aplicación en un entorno. Los cambios en la base de datos se manejaron a través de los scripts de cambio incluidos en un proyecto de base de datos.

Si estuviera haciendo esto desde cero, consideraría TeamCity u otra solución de CI dedicada en lugar de tratar de mejorar TFS. Dicho esto, tal vez la historia con TFS haya mejorado hasta el punto de que es viable intentarlo con TFS.

    
respondido por el neontapir 08.11.2012 - 23:02