¿Cómo migrar de "Integración Arcana" a Integración Continua?

Question

Ahora mismo, un proyecto en el que estoy trabajando ha alcanzado un nivel de complejidad que requiere más de unos pocos pasos (¡de hecho se vuelve arcano!) Para producir un producto completo/utilizable. Y desafortunadamente no comenzamos con una mentalidad de Integración Continua, así que como se puede imaginar es algo doloroso a veces, y en otros puedo perder fácilmente medio día tratando de obtener una construcción limpia/probada.

De todos modos, como cualquier proyecto ENORME, consta de muchos componentes en muchos idiomas diferentes (no solo el estilo empresarial Java o C# por ejemplo), sino también muchos recursos gráficos y textuales. Ahora el problema es que cuando busco la Integración Continua, siempre encuentro mejores prácticas y técnicas que suponen que uno está comenzando un nuevo proyecto desde cero. Sin embargo, este no es un proyecto nuevo, así que me preguntaba cuáles son algunos buenos recursos para comenzar a migrar proactivamente desde la integración Arcana hacia la integración continua :)

¡Gracias de antemano!

Answer 1

Aquí está en dos pasos simples (hah).

1. Ir a la acumulación repetible:
   1. Uso de control de origen, obtener todo el código comprobarse en
   2. establecer y documentar todas las herramientas que se utilizan para construir (sobre todo, cuál es la versión del compilador).. Tener un despliegue repetible y un proceso de configuración para estas herramientas.
   3. Establezca y documente claramente cualquier recurso que sea necesario construir, pero que no esté registrado (instalaciones de terceros, service packs, etc.). Tener una implementación repetible y un proceso de configuración para estas dependencias.
2. antes de comprometerse a control de código fuente, los desarrolladores deben
   1. actualizar su copia de trabajo
   2. éxito construir
   3. carrera y pasar las pruebas automatizadas

Estos pasos se pueden hacer 1 a la vez, una especie de camino a seguir. Obtendrás beneficios en cada etapa. Por ejemplo, si no está utilizando el control de fuente en absoluto, simplemente poner el código en control de fuente (sin nada más) es un gran paso adelante. Además, si no hay pruebas automatizadas, los desarrolladores no pueden ejecutarlas, pero aún pueden obtener las confirmaciones previas y hacer que el compilador verifique su trabajo.

Si puede hacer todo esto, obtendrá un buen lugar.

Los objetivos son los procesos de compilación repetibles y los desarrolladores que están conectados a la forma en que sus cambios afectan a la compilación y a otros desarrolladores.

A continuación, puede cosechar los bonos mediante el establecimiento de un mayor cumplimiento:

• Desarrolladores establecen una frecuente cometer hábito. El código que está en la copia de trabajo nunca debe tener más de 1 día.
• El proceso de compilación automatizado supervisa el control de origen para registros y obtiene los resultados en un lugar donde los usuarios pueden aceptarlos (como un entorno de prueba, una vista previa o simplemente colocando un .exe donde el usuario puede encontrarlo))

Answer 2

Supongo que la migración no es realmente una opción: las soluciones mediocres solo empeorarán las cosas.

Mi enfoque sería tomar a un ingeniero creativo que entienda el proceso de construcción, recostarlo y decir "Arregle esto". Dale una semana o dos.

El objetivo final sería un proceso que se ejecuta desde el principio hasta el final con un solo comando make.

También recomiendo un procedimiento automatizado de "Configuración" en el que simplemente realiza un pago y ejecuta un archivo por lotes desde un recurso compartido de red para instalar y construir todas sus herramientas. La cantidad de tiempo que esto ahorrará en general es asombroso si trae nuevos programadores. La mayoría de los proyectos tardan de uno a tres días en configurarse en una computadora nueva, y siempre es el "nuevo" programador el que no sabe lo que sucede instalando en su propio sistema ...

Answer 3

De la misma manera comes un elefante (un bocado a la vez) ;-) La integración continua requiere una construcción automatizada. Comience con eso. Automatice la construcción de cada pieza. Ant o NAnt es una gran manera de hacer esto. Haga que la construcción de cada componente sea una tarea NAnt. Entonces toda la construcción de su sistema puede agregar esas tareas individuales.

A partir de ahí, puede agregar tareas para implementación, para pruebas unitarias, etc. Si desea utilizar una tecnología CI, puede conectarla a su compilación NAnt.

Answer 4

En resumen: incrementalmente

Elegir un marco que va a trabajar a través de la amplia gama de proyectos.

Uno por uno, agregue componentes al marco.

Si no está familiarizado con el marco, haga primero un par de los componentes más fáciles para reducir el riesgo de atornillar.

Si comprende el marco, aborde primero algunos de los componentes más difíciles y/o comunes, para que su equipo (y la administración) aprecien los beneficios desde el principio y respalden más el esfuerzo.

Asegúrese de tener un plan para incluir todos de sus componentes, porque es entonces cuando se obtendrán todos los beneficios.

Traiga a su equipo con usted; asegúrese de tener un consenso de que esto va a ser valioso, o las personas no lo mantendrán a medida que cambien los componentes.

Answer 5

Comenzaría por escribir todos los pasos necesarios para realizar la construcción y la prueba manualmente. Después de eso, al menos tienes una guía para hacerlo a la antigua, y escribir cosas te da la oportunidad de verlo como un proceso completo.

A continuación, busque las piezas para script.

Lo ideal es desencadenar una compilación y una prueba a partir de una confirmación de código y solo reconstruir y volver a probar las partes modificadas, tal vez con una compilación completa y una prueba todas las noches o semanalmente. Necesitará archivos de registro o entradas de la base de datos e informes sobre el éxito de la construcción o la falta de ella.

Querrá buscar y evaluar productos preconstruidos y kits de construcción de código abierto propios.Ciertamente puede escribir todos los scripts e informes, pero llevará un tiempo y probablemente terminará con un sistema de informes apenas lo suficientemente bueno, ya que su trabajo es codificar el producto, no codificar el sistema de compilación. :-)