Al principio
, CI y CD son en realidad tres conceptos, que incluyen un CI y dos CD. El nombre completo de CI es Integración continua, lo que significa integración continua. CD incluye Entrega continua e Implementación continua, que son entrega continua e implementación continua, respectivamente. Hay una dependencia de adelante hacia atrás entre estos tres conceptos.
CI/CD no es una herramienta, es una práctica de desarrollo de software, el núcleo es mejorar la eficiencia de la entrega de software mediante la introducción de la automatización. El objetivo final de CI/CD: ¡Permitir que los ingenieros entreguen software más rápido, con mayor calidad y más fácil!
Integración continua, entrega continua e implementación continua
Integración continua
¿Qué es la Integración Continua?
Definición: continuamente y con frecuencia (varias veces al día) "integre" el código local en la sucursal principal y asegúrese de que la sucursal principal esté disponible
El término integración continua, originado de la programación extrema, fue una de las prácticas originales de 12 en ese momento.El propósito de la integración continua es retroalimentar rápidamente los problemas para que los productos puedan iterarse rápidamente mientras se mantiene una alta calidad. Su medida central es que antes de que el código se integre en la red troncal, debe pasar la compilación, el escaneo de código, el escaneo de seguridad, las pruebas automatizadas, etc. Mientras la compilación falle, los problemas de alto nivel se analicen o los casos de prueba fallen, la integración no será posible.
Martin Fowler dijo: "La integración continua no elimina los errores, los hace muy fáciles de encontrar y corregir".
¿beneficio?
(1) Mejorar la velocidad de integración a través de la automatización
En el proceso tradicional de I+D, la compilación, las pruebas y la implementación generalmente se realizan manualmente.Después de la automatización, la frecuencia de integración puede aumentar considerablemente y los problemas de bajo nivel causados por el mantenimiento de scripts manuales pueden reducirse (2
) Poner el problema
delante de cada confirmación y desencadenar la compilación y las pruebas para encontrar problemas más rápido
(3) Evitar que el código local
se desvíe mucho de la red troncal Difícil de integrar.
¿Método de activación?
Dispare automáticamente, a través de servicios o herramientas de CI automatizados, monitoree automáticamente la base de código Git Push & MR y otros disparadores de eventos
Herramientas comunes como Jenkins, GitlabCI, CircleCI, GithubActions, etc.
Ant admite plataformas de integración continua: Swift (front end), LinkE CI (back end), partner (terminal), ACI (multilingüe), etc.
¿Problemas y obstáculos enfrentados?
El ideal es completo, pero la realidad es muy flaca. Aunque el concepto de integración continua es bueno, hay muchos problemas y obstáculos en el proceso de práctica, ¡que está lejos de ser tan simple como se imagina!
Problemas comunes como:
(1) Los entornos de ejecución heterogéneos conducen a diferencias en los resultados.
Por ejemplo, en las pruebas de Java, los usuarios generalmente ejecutan las pruebas localmente a través de IDEA, haga clic con el botón derecho para ejecutar pruebas o comandos mvn, pero hay muchas diferencias en el entorno y especificaciones de la máquina en los servicios de CI y locales. Por ejemplo, diferentes JDK, diferentes versiones de Maven, diferencias entre Mac y Linux, etc. harán que muchas ejecuciones locales pasen, pero las ejecuciones de CI fallan, o las ejecuciones de CI son significativamente más lentas que las ejecuciones locales.
La esencia de resolver este tipo de problemas es reducir la heterogeneidad, como estandarizar el entorno de ejecución a través de la creación de contenedores, mejorar el tiempo de prueba a través de la memoria caché de Maven, etc. Al mismo tiempo, como plataforma de CI/CD, también es mejor hacer que el proceso de pruebas y construcción transparentes (mecanismo de ejecución, códigos de error claros y soluciones) para facilitar el desarrollo de la solución de problemas de autoayuda cuando surgen problemas.
(2) No hay un requisito de prueba estricto.
El concepto de integración continua es que mientras haya un problema, debe repararse a tiempo. Por ejemplo, en la ejecución de la prueba, se debe garantizar que todos los casos se integren. Sin embargo, en escenarios reales, especialmente algunos proyectos históricos a gran escala, debido a deudas históricas y otras razones, no se pueden pasar todos los casos de prueba o deben resolverse mediante reintentos. Es difícil que el desarrollo tenga la motivación para cambio, lo que resulta en una calidad de integración ineficiente.
Por lo tanto, la premisa de la integración continua es que uno debe estar preparado para gastar mucha energía en administrar algunas deudas históricas en el proyecto, especialmente para mejorar los casos históricos, agregar nuevos casos, reducir el ruido de los casos y garantizar que cada prueba se active automáticamente. puede retroalimentar con precisión la calidad de integración!
(3) Velocidad de compilación y prueba muy lenta.
La velocidad de compilación o prueba en CI es muy lenta, lo que da como resultado una eficiencia de integración muy baja. Hay dos razones para la lentitud aquí. Una es que la prueba y la compilación en sí son lentas. esta vez, debe ser en profundidad. El análisis debe resolverse mediante la combinación de tecnologías como la agrupación paralela y el almacenamiento en caché distribuido.
La prueba de integración en la prueba automatizada aquí puede ser muy lenta, por lo que generalmente se garantiza pasar primero la prueba unitaria en la fase de integración continua, y la prueba de integración se completa en la fase de entrega continua.
Entrega continua (Continuous Delivery)
¿Qué es la entrega continua?
Definición: es el siguiente paso de la integración continua, que entrega de manera continua y frecuente nuevas versiones del software a un entorno similar al de producción (similar al prelanzamiento), la entrega a prueba y la aceptación del producto.
La entrega continua enfatiza la "entrega". No importa cómo se actualice, el software se puede entregar en cualquier momento y en cualquier lugar. En comparación con la integración continua, la entrega continua no solo entregará a un entorno similar a la producción, sino que también realizará algunas pruebas de integración, pruebas de API, etc. para garantizar que el producto entregado se pueda entregar directamente para su implementación.
¿Método de activación?
Activación manual, activación manual a través de la plataforma de I+D (como la activación de la canalización de implementación previa al lanzamiento de LinkE), el resultado general de la entrega es una imagen o un paquete binario
¿Problemas y obstáculos enfrentados?
(1) Es difícil garantizar que sea completamente consistente con el entorno en línea.
Dado que el entorno de entrega continua es difícil de ser consistente con el entorno en línea, es posible que no se verifiquen algunos problemas, lo que hace que el producto entregado tenga ciertos riesgos.
Exploración plan: entorno de simulación
(2) A menudo se encuentran muchos problemas de entorno de depuración conjunta dolorosos para el cerebro . Aunque el sistema se ha desarrollado, debido a varias razones, los sistemas aguas arriba y aguas abajo no están listos, lo que resulta en una entrega continua. Para sistemas con una gran cantidad de aguas arriba y dependencias aguas abajo, el pareado Existe una dependencia muy fuerte de la estabilidad y la eficiencia del entorno de ajuste
(3) Es difícil garantizar pruebas automatizadas estrictas y suficientes.
La entrega continua debe garantizar en última instancia que el producto entregado se pueda implementar directamente en línea, por lo que los requisitos de calidad para el código son muy altos y se requieren suficientes casos de prueba que cubran todos los escenarios.
Implementación continua (Continuous Deployment)
¿Qué es la implementación continua?
Definición: el siguiente paso en la entrega continua, implementar código "automáticamente" en producción
La implementación continua enfatiza la "implementación" y su objetivo es que el código se pueda implementar en cualquier momento y pueda ingresar a la etapa de producción.
La diferencia entre la implementación continua y la entrega continua es que la implementación continua se realiza automáticamente, mientras que la entrega continua se realiza manualmente.
¿Método de activación?
Active automáticamente, configure las tareas de tiempo a través de la plataforma de I+D y obtenga automáticamente los productos entregados para su implementación automática.
En la actualidad, incluso en Ant, debería haber pocos equipos y plataformas de I+D que realmente puedan lograr una implementación continua, porque las condiciones para la implementación continua son más estrictas.
¿Problemas y obstáculos enfrentados?
(1) Las condiciones de liberación son limitadas.
Algunos escenarios requieren un proceso de aprobación estricto y un bloqueo frecuente de la red
(2) Proceso de liberación manual ineficiente
. El proceso de liberación requiere confirmación manual una y otra vez. Determinación manual una y otra vez, no se preocupe por la liberación automática
Hormiga actual solución: desatendido
(3) falta de un mecanismo de retroalimentación rápido y preciso para problemas en línea (capacidad precisa de OPS)
sin OPS o demasiado ruido en OPS dará lugar a una retroalimentación inoportuna, por lo que I + D no me atrevo a entregar el proceso de implementación directamente al sistema, que también es la causa raíz de la confirmación manual requerida para la versión anterior
Actualmente, la empresa tiene requisitos muy altos para la seguridad en línea, y es difícil implementar una implementación continua a gran escala en Ant en esta etapa, especialmente para sistemas con requisitos de seguridad muy altos como el núcleo financiero. Sin embargo, no es necesario ser "talla única". Para aplicaciones de alto nivel en particular, puede probar estas aplicaciones en un área pequeña y, al mismo tiempo, continuar mejorando las herramientas OPS circundantes.
Finalmente
, imaginemos cómo debería ser un excelente proceso de I+D de CI/CD.
Asumiendo que el compañero de clase de desarrollo Xiao Ma se unió al trabajo el primer día, encendió la computadora y completó el en línea a través de los siguientes pasos:
Paso 1: Desde el código de clonación de AntCode al código local, modifique algunas líneas de código, después del prueba local, a través de git commit & push al almacén de código
Paso 2: El proceso de inserción activa automáticamente la canalización de CI. Después de 5 minutos, la ejecución finaliza y DingTalk notifica a Xiaoant que cierto caso de prueba ha fallado. Paso 3: Xiaoant modifica
localmente el caso fallido, se confirma y empuja nuevamente, y se activa nuevamente La canalización de CI ejecuta automáticamente la compilación, prueba, escaneo, etc., y se recibe el mensaje DingTalk y se pasa la ejecución.Paso 4: Xiaoma envía la función a la prueba
y aceptación del producto, encuentra un problema o recibe una sugerencia, y luego va al segundo paso para modificar el código.
Paso 5: después de que no haya ningún problema en la prueba y la aceptación del producto, active manualmente la canalización de implementación previa al lanzamiento y genere automáticamente la entrega del producto de implementación e ignore los procesos posteriores.
Paso 6: la canalización de implementación continua detecta automáticamente el paquete del producto de entrega cada pocos minutos e implementa automáticamente el producto en la línea después de encontrar una actualización. Después de que el lanzamiento sea exitoso, Xiaoma recibe una notificación de que la función de Xiaoma entra en vigor.
¿Estado ideal?
(1) La frecuencia del trabajo de horas extra debido a los lanzamientos debe reducirse considerablemente
(2) La mayor parte de la energía de desarrollo se gasta en escribir códigos y pensar en cómo escribir buenos códigos La plataforma realiza el escaneo y la implementación automáticamente, y la experiencia es bueno y la retroalimentación es precisa.