Desafíos en la entrega continua y la implementación de productos de software





El artículo fue elaborado por Konstantin Bryukhanov, director del curso "CI / CD" . En él, Konstantin reveló una serie de puntos problemáticos relacionados con la implementación de código de producto de software en empresas de TI y recopiló recomendaciones de entre las mejores prácticas internacionales.






En la operación de TI, la dirección más demandada es precisamente el ajuste y la provisión de entrega y despliegue continuos. Las tecnologías y metodologías evolucionan constantemente, las herramientas se mejoran. Como tal, los requisitos de implementación y entrega más recientes incluyen la preparación y continuidad de las pruebas de cambio, la preparación y configuración de un entorno de prueba para el equipo de control de calidad.



Los avances tecnológicos y el software libre han llevado a un cambio significativo en el enfoque para organizar los procesos de CI / CD. La transición a nuevos principios influyó en gran medida en la cultura corporativa, las habilidades en demanda de los empleados y los principios mismos del trabajo en las organizaciones, lo que condujo a cambios a gran escala en el mundo del desarrollo de software.



Las soluciones en la nube son cada vez más prioritarias. La entrega continua de software requiere una colaboración eficaz entre los equipos de desarrollo, pruebas y operaciones, y la nube es ideal para esta colaboración.



Sin embargo, la fase de implementación, realizada en una topología distribuida compleja, es propensa a errores y generalmente requiere una solución de problemas manual. La fase de implementación del producto de un proceso de entrega continua a menudo crea cuellos de botella e impacta negativamente en la efectividad del proceso DevOps.



La entrega continua le permite lograr la automatización de las pruebas de cambios de software incrementales y la implementación rápida de actualizaciones de la manera más eficiente y segura. Este enfoque brinda a los usuarios la confianza de que se está utilizando la última versión del código en el entorno de producción, y los cambios realizados por los programadores pueden llegar a los clientes en cuestión de horas o incluso minutos.



Consideremos el escenario más común para implementar CI / CD en un proyecto:



  1. El equipo de desarrollo lanza una nueva versión del producto (nueva funcionalidad o corrección de errores de la versión anterior).
  2. El servicio de Integración Continua (CI) valida el código nuevo con una serie de pruebas que incluyen múltiples niveles de prueba, como pruebas de sintaxis, unidad y regresión.
  3. , (CD).
  4. (, ) , (staging), , .
  5. stage- CI/CD , .
  6. .




Este escenario es el más general y cubre la mayoría de las necesidades de los equipos de desarrollo y operaciones, pero aún presenta algunos problemas , por ejemplo:



  1. Reemplazo de archivos . A menudo es necesario actualizar o reemplazar archivos de configuración o regenerar algún contenido estático. En este caso, los usuarios pueden recibir errores hasta que el tráfico se cambie de la versión anterior del software a la nueva. Si la implementación falla, existe el riesgo de incompatibilidad de archivos.
  2. . , , . . , - , - .
  3. . . , , .. . , - , , .. .




Vale la pena señalar que los problemas enumerados anteriormente pueden surgir incluso en un entorno casi ideal, pero una de las principales dificultades para implementar la metodología DevOps es que no existe una imagen única de cómo debería ser el proceso de implementación de productos y entrega continua. Muchas empresas de TI saben muy poco sobre DevOps, a veces no entienden en absoluto esta metodología, mientras que otras ya tienen soluciones históricas sobre las cuales tienen que construir nuevos procesos. Teniendo en cuenta los altos requisitos para las calificaciones de los especialistas de Devops y su escasez en el mercado laboral, el empleador a menudo se ve obligado a utilizar los recursos que ya tiene a su disposición y asignar tareas de Devops a ingenieros novatos. Como resultado, hay aún más puntos débiles en el sistema.



Cuando se usa CI / CD sin una comprensión correcta de la metodología, sin un enfoque analítico para construir la infraestructura y los métodos para entregar el código, surgen los siguientes problemas:



1. Factor humano . El primer riesgo y el más significativo está asociado a factores humanos. Imaginemos una situación en la que sea necesario configurar varios servidores más similares a los existentes. Si el especialista que realizó las instalaciones o configuraciones anteriores no está disponible actualmente por cualquier motivo (enfermo, abandono, etc.) y no ha preparado instrucciones detalladas, entonces la situación se vuelve mucho más complicada. En este caso, cada nuevo especialista debe estudiar todo el proceso de configuración del servidor por completo, mientras que no tiene margen de error. Y además, es imposible estimar con precisión cuánto tiempo llevará configurar y garantizar su éxito.



Esto también incluye los riesgos asociados con el hecho de que el autor del método cometió un error, olvidó cubrir los procesos con pruebas o simplemente no tomó en cuenta algo y su sucesor no lo notó.



También debe recordarse que las empresas a menudo desarrollan varios proyectos, y el Departamento de Operaciones de TI suele ser uno, y un Ingeniero de Operaciones atiende varios proyectos. Si no existe un esquema y concepto único, entonces los procesos en diferentes equipos se construirán de diferentes formas, lo que complicará significativamente el desarrollo posterior de Devops en la empresa y hará un umbral alto para el ingreso de un ingeniero de operaciones a otro proyecto, donde ya se utilizan procesos que son diferentes a los que trabajó más temprano.



2. Escenarios no idempotentes... La idempotencia es un atributo crítico de los escenarios de implementación de código y entrega continua, especialmente en implementaciones de infraestructura. El ingeniero debe estar seguro de que cada vez que se ejecutan los scripts, el resultado estará garantizado, esperado y sin cambios de forma única al reproducir el mismo script. A menudo, al implementar Devops en una empresa, los ingenieros están tratando de desarrollar una solución comercial y es posible que no tengan en cuenta la idempotencia o simplemente no conozcan este requisito. En este caso, la empresa recibe una bomba de tiempo. Existe la posibilidad de entregar código inesperado a las instalaciones de producción. Por ejemplo, si alguien actualizó un módulo CMS para un proyecto y, por lo tanto, influyó en otros, cuando esto no se esperaba.



3. Almacenamiento de datos sensibles y organización del acceso. Uno de los puntos más importantes en el enfoque de Devops para almacenar datos secretos, restringir derechos, organizar la red y el acceso de los usuarios. Hasta ahora, no existen prácticas y herramientas uniformemente aceptadas para resolver este problema, y ​​los ingenieros deben realizar investigaciones cada vez, dependiendo de la organización actual de la infraestructura y los métodos adoptados para restringir el acceso. Por ello, la implementación de la metodología Devops en una empresa se complica por el hecho de que es imposible encontrar de manera inequívoca una solución para su caso particular, y el uso de prácticas ajenas no siempre garantiza la seguridad.



4. Modelo presupuestario definido , más adecuado a la metodología Waterfall.



5. Elevados requisitos de seguridad.En consecuencia, es imposible ubicar la infraestructura de los proyectos nacionales de TI en el área de responsabilidad de empresas comerciales extranjeras, por ejemplo, Amazon, Microsoft.



6. Gran cantidad de "código heredado", "infraestructura heredada" que debe mantenerse. La necesidad de integración con una gran cantidad de sistemas heredados.



Por lo tanto, el proceso de construcción de Devops en una empresa puede ir acompañado de una serie de problemas y no siempre resuelve los problemas para los que fue creado.



El primer paso importante es abandonar la relación con los servidores como un elemento de infraestructura único y difícil de personalizar., transición de la configuración manual del servidor a la gestión de infraestructura automatizada y centralizada. El proceso de configuración de cada servidor debe describirse en forma de una configuración que sea fácil de leer, modificable y lista para múltiples reutilizaciones seguras, proporcionando un resultado garantizado inequívoco. Ejemplos de sistemas de orquestadores industriales son Chef o Ansible. Estos sistemas le permiten administrar una gran cantidad de servidores con costos mínimos.



El siguiente paso importante es aplicar pruebas automatizadaspara cubrir tanto como sea posible la funcionalidad del código que se está desarrollando (tanto software como infraestructura). En otras palabras, tener una infraestructura implementada, pero sin pruebas automatizadas, el cuello de botella del proceso de desarrollo será la verificación oportuna de la funcionalidad. La automatización del proceso de prueba debe comenzar con la escritura real del código del software (prueba unitaria), la aplicación de pruebas primarias en el servidor responsable de la construcción del software y una prueba de la configuración del servidor. Esto reducirá la carga de trabajo del equipo de control de calidad del software y reducirá significativamente el tiempo que tarda el software en pasar por la tubería.



El último paso lógico es la recopilación y el análisis centralizados de los archivos de registro de todos los servidores.para la notificación oportuna a todos los interesados ​​y el seguimiento proactivo del estado de la infraestructura en su conjunto.



Las pautas anteriores lo ayudarán a construir una infraestructura escalable y resistente que pueda manejar un proceso de desarrollo intensivo. La implementación de DevOps requiere la participación de todos en el proceso, desde la prueba y el desarrollo hasta los gerentes y las operaciones. En cada etapa se requiere un análisis retrospectivo constante del proceso, ya que como resultado de errores aleatorios al cambiar la configuración, los sistemas dejan de funcionar por completo. Es necesario mejorar la telemetría para detectar errores y recuperarse mejor, y para proteger la canalización de implementación y cumplir con los objetivos de cambio de administración. Esto le permitirá recibir el máximo apoyo de la administración para implementar iniciativas de DevOps, crear un entorno de trabajo más animado y amigable,para que cualquier participante pueda aprender durante todo el tiempo; esto no solo ayudará a cada participante a alcanzar sus metas, sino que también llevará a la organización al éxito.



En 3 meses en nuestro curso en línea "CI / CD" que va a desarrollar una comprensión de la arquitectura de los proveedores de nube, aprende a automatizar el análisis de código y buscar vulnerabilidades, y aprender cómo personalizar los procesos de construcción, pruebas e instalación de una aplicación a partir de los tres proveedores más grandes . El programa está diseñado para especialistas con experiencia en administración; una prueba de ingreso especial lo ayudará a determinar si tiene suficiente preparación para la capacitación.






Lee mas:






All Articles