Quiero ser más eficiente y quiero usar las herramientas de operaciones de manera eficiente.
Con esto en mente, quería aprender más sobre la integración continua, pero parece que hay muchas cosas diferentes al respecto.
De hecho, estoy trabajando con trajes de Jetbrains en mi trabajo (IntelliJ, WebStorm ...), por lo que quería seguir usándolos y quería usar TeamCity, que parecía ser una gran herramienta con muchos complementos para una integración continua.
Mi problema es que no sé cuáles son las diferencias entre:
automatización de edificios (TeamCity es este tipo de software): Sé que podemos construir nuestra aplicación con un repositorio VCS remoto y es genial, pero ¿cuál es el objetivo principal de eso? ¿Qué tipo de información es importante al hacer esto? De hecho, ya sé si mi software se construye o no localmente, y mis compañeros de equipo también. Entonces, ¿cuál es el objetivo de usarlo sin implementar la automatización?
implementando automatización (TeamCity no parece hacerlo fácilmente)
- integración continua (que parece ser una conjunción de los dos anteriores)
- entrega continua (¿qué es esto exactamente? ¿Por qué es diferente de la integración continua?)
¿Me pueden ayudar a entender un poco más esto?
Respuestas:
Wikipedia ofrece muy buenos resúmenes de la mayoría de estos términos. Aquí está mi opinión sobre ellos:
La automatización de compilación es la automatización de cómo se construye el software en lugar de invocar manualmente el compilador. Esto se lograría mediante herramientas como, por ejemplo, Make o Ant .
La automatización de implementación consiste en tomar su software integrado y desplegarlo o instalarlo en un sistema de prueba o producción.
La integración continua significa que un proceso automatizado construya su software continuamente a medida que los desarrolladores registran el código y ejecutan pruebas unitarias para garantizar que el código aún funcione. Por ejemplo, cada 15 a 30 minutos un servidor puede reactivarse, escanear VCS para ver si hay nuevos registros, luego actualizar y construir el proyecto si se realizaron cambios. Además de realizar pasos de compilación, esta también es una gran oportunidad para ejecutar pruebas unitarias automatizadas y controles de calidad de código .
La entrega continua es una combinación de todos los conceptos anteriores donde las compilaciones de software también se implementan en un sistema de prueba, opcionalmente con las pruebas realizadas y los informes generados.
Como mínimo, debe tener automatización de compilación, es decir, un script de compilación de algún tipo. Eso le permite hacer clic en un botón o emitir un comando para construir su proyecto. El beneficio de esto es que reduce los errores de ejecutar pasos manualmente. Los entornos de compilación complejos pueden involucrar la generación de código (piense en DAO desde configuraciones, código de interfaz como JAXB ), compilar código, empaquetarlo, personalizar metadatos, etc. Con muchas cosas para hacer, necesita una lista de verificación: ¿por qué no hacer que la lista de verificación sea su script de compilación y utiliza una herramienta para ejecutarlo? Reduce los errores y proporciona consistencia.
El siguiente es CI: es realmente bueno tenerlo, pero no es estrictamente necesario. Ayuda a identificar problemas de construcción temprano. Si tiene varios desarrolladores registrando el código durante todo el día y tal vez no sincronizando sus propios espacios de trabajo constantemente, existe el riesgo de que sus cambios interfieran entre sí. Me refiero específicamente a errores de código estático, no a conflictos de control de versiones. Un servidor de compilación de CI mitigará este riesgo.
Finalmente tenemos los pasos de implementación. La idea aquí es ahorrar tiempo y reducir el error de la implementación manual del software. Al igual que la automatización de compilación, hay cientos de formas de arruinar una implementación de software. Personalmente, me he quedado hasta tarde en la oficina para solucionar problemas de implementación manual en muchas ocasiones cuando necesitamos un sistema que funcione para los clientes que vienen al sitio mañana. La automatización de múltiples sistemas presenta más riesgos: en lugar de que un sistema se bloquee o tenga errores extraños, ahora tenemos múltiplessistemas que pueden salir mal. Sin embargo, ese riesgo es mucho más bajo que alguien que pierde un paso en una lista de verificación o emite un comando incorrecto y arruina un despliegue. Si tiene suerte, simplemente puede restaurar una copia de seguridad de la base de datos y comenzar de nuevo, si tiene mala suerte, un error puede hacer que el sistema funcione incorrectamente. ¿Es un defecto de software? ¿El técnico no configuró una configuración correctamente? Esto lleva tiempo para diagnosticar, tiempo que quizás no tenga y tiempo que no necesita gastar si automatiza el proceso.
fuente
La integración continua es la práctica de fusionar todos los cambios de los desarrolladores en una línea principal compartida varias veces al día. Esta práctica ahora es tan omnipresente que puede no parecer tan significativa, sin embargo, tradicionalmente los equipos trabajarían en software durante semanas o incluso meses de forma aislada. El resultado fue "Infierno de integración" cuando se fusionaron flujos de trabajo separados. La integración continua se usa normalmente con compilaciones automatizadas de la línea principal compartida para encontrar problemas temprano, pero se trata más de compromisos frecuentes y flujo de trabajo del desarrollador que de DevOps.
Las compilaciones automatizadas son valiosas para detectar problemas que pueden hacer que la compilación pase localmente, pero falla en el servidor de compilación (por ejemplo, olvidó registrar un archivo, las dependencias en el servidor de compilación no coinciden). Hacer que el servidor de compilación detecte estos problemas significa que puede solucionarlos antes que sus compañeros de equipo.
La entrega continua implica la implementación, ejecución y prueba continuas de su software. Si bien las compilaciones automatizadas aseguran que su software realmente se compila (y las pruebas unitarias pasan), no significa que sus scripts de implementación aún funcionen o que su software realmente se ejecute de extremo a extremo. El objetivo de la entrega continua es tener una serie de controles que garanticen que la línea principal permanezca en un estado adecuado para el despliegue en producción.
La implementación continua es el siguiente paso lógico: implementar automáticamente cada confirmación que pasa con éxito a través de la canalización de entrega continua. Hay varios beneficios en esta práctica, pero para mí, la idea principal aquí es que los compromisos pequeños y frecuentes son menos riesgosos.
Recomiendo leer este libro para más información:
fuente
Teamcity, como muchas de las herramientas de compilación, es solo una aplicación central que le permite ejecutar muchas tareas diferentes. Esto incluye realizar compilaciones como compilaciones de CI, compilaciones de lanzamiento completo y le permite realizar implementaciones. Si está utilizando teamcity para llamar a ant o nant para ejecutar msbuild en un archivo de solución, también puede llamar a scripts nant que realizarán implementaciones. Puede requerir un poco de secuencias de comandos, pero no es difícil.
Utilizamos teamcity y bamboo para CI completos, CI de bases de datos y se implementa en el entorno INTegration. Luego usamos teamcity para compilaciones de lanzamiento completo y para crear scripts de migración db automáticamente. Estos se registran en SVN a través de trabajos de teamcity que llaman a scripts nant. Para las implementaciones, lo adivinó, usamos teamcity para llamar a Nant para realizar tareas de implementación. Esto funciona bien ya que el agente de teamcity habla con el servidor de teamcity y el agente puede existir en uno de los servidores en una ubicación DMZ que ayuda a mover el código más allá de los cortafuegos, etc. Así que teamcity o bambú es todo lo que necesita para manejar todo el escenario .
fuente