Imagen: UnsplashHola a todos! Somos ingenieros de automatización de
Positive Technologies y apoyamos el desarrollo de productos de la compañía: respaldamos toda la línea de ensamblaje desde los desarrolladores que comprometen una línea de código hasta la publicación de productos terminados y licencias en servidores de actualización. Informalmente, somos llamados ingenieros de DevOps. En este artículo queremos hablar sobre las etapas tecnológicas del proceso de producción de software, sobre cómo los vemos y cómo los clasificamos.
Del material aprenderá sobre la complejidad de coordinar el desarrollo de múltiples productos, sobre qué es un flujo de trabajo y cómo ayuda a organizar y replicar soluciones, cuáles son las principales etapas y pasos del proceso de desarrollo, cómo se dividen las responsabilidades entre DevOps y los equipos de nuestra empresa.
Sobre el caos y DevOps
Tenga en cuenta brevemente que el concepto de DevOps incluye herramientas y servicios de desarrollo, así como metodologías y mejores prácticas para su uso. Seleccionaremos el
objetivo global al introducir ideas de DevOps en nuestra empresa: esta es una reducción constante en el costo de producción y mantenimiento de productos en términos cuantitativos (horas hombre u horas máquina, CPU, RAM, Disco, etc.). La forma más simple y obvia de reducir el costo total de desarrollo a nivel de la empresa es
minimizar el costo de realizar tareas en
serie típicas en todas las etapas de producción. Pero, ¿cuáles son estas etapas, cómo distinguirlas del proceso general, en qué pasos consisten?
Cuando una empresa desarrolla un solo producto, todo está más o menos claro: generalmente hay una hoja de ruta y un esquema de desarrollo comunes. Pero, ¿qué hacer cuando la línea de productos se expande y hay más productos? A primera vista, tienen procesos y líneas de ensamblaje similares y el juego "encuentra X diferencias" en los registros y scripts comienza. ¿Y si ya hay más de 5 proyectos en desarrollo activo y necesita soporte para varias versiones desarrolladas durante varios años? ¿Queremos reutilizar la mayor cantidad posible de soluciones en transportadores de productos o estamos listos para gastar dinero en un desarrollo único para cada uno?
¿Cómo encontrar un equilibrio entre la unicidad y la serialidad de las soluciones?
Estos problemas comenzaron a surgir ante nosotros con mayor frecuencia desde 2015. La cantidad de productos creció e intentamos minimizar nuestra expansión de nuestro departamento de automatización (DevOps), que apoyaba las líneas de ensamblaje de estos productos. Al mismo tiempo, quería la mayor cantidad de soluciones posibles para replicar entre productos. Después de todo, ¿por qué hacer lo mismo en diez productos de diferentes maneras?
Director de desarrollo : "Chicos, ¿podemos evaluar de alguna manera lo que hace DevOps para los productos?"
Nosotros : "No sabemos, no nos hicimos esa pregunta, pero ¿qué indicadores deberían considerarse?"
Director de desarrollo : “¡Y quién sabe! Piensa ... "
Como en la famosa película: "¡A mi hotel! .." - "Uh ... ¿Me mostrarás el camino?" Pensando, llegamos a la conclusión de que primero debe decidir sobre los estados finales de los productos; Este fue nuestro primer objetivo.
Entonces, ¿cómo analiza una docena de productos con equipos suficientemente grandes de 10 a 200 personas y determina métricas medibles al replicar soluciones?
1: 0 a favor del Caos, o DevOps en los omóplatos
Comenzamos con un intento de aplicar diagramas IDEF0 y varios diagramas de procesos comerciales de la serie BPwin. La confusión comenzó después de la quinta casilla de la siguiente etapa del próximo proyecto, y estos cuadrados para cada proyecto se pueden dibujar en la cola de una pitón larga en más de 50 pasos. Estaba triste y quería aullar a la luna, no encajaba en general.
Tareas típicas de producción
Modelar procesos de producción es un trabajo muy complejo y laborioso: debe recopilar, procesar y analizar una gran cantidad de datos en varios departamentos y cadenas de producción. Puede leer más sobre esto en el artículo "
Modelado de procesos de producción en empresas de TI ".
Cuando comenzamos a modelar nuestro proceso de producción, perseguimos un objetivo específico: transmitir a cada empleado involucrado en el desarrollo de los productos de nuestra empresa y a los gerentes de proyecto:
- cómo los productos y sus componentes, a partir de una línea de confirmación de código, llegan al cliente en forma de instaladores y actualizaciones,
- qué recursos se proporcionan para cada etapa de producción de productos,
- qué servicios están involucrados en cada etapa,
- ¿Cómo se diferencian las áreas de responsabilidad para cada etapa?
- qué contratos existen en la entrada y salida de cada etapa.
Al hacer clic en la imagen se abrirá a tamaño completoNuestro trabajo en la empresa se divide en varias áreas funcionales. La dirección de la infraestructura es optimizar el funcionamiento de todos los recursos "de hierro" del departamento, así como automatizar la implementación de máquinas virtuales y el entorno en ellos. La dirección de monitoreo proporciona monitoreo de salud de servicio 24/7; También proporcionamos monitoreo como un servicio para desarrolladores. La dirección del flujo de trabajo proporciona a los equipos herramientas para administrar los procesos de desarrollo y prueba, analizar el estado del código y obtener análisis de proyectos. Y finalmente, webdev proporciona versiones de publicación en los servidores de actualización GUS y FLUS, así como productos de licencia que utilizan el servicio LicenseLab. Para respaldar el proceso de producción, configuramos y mantenemos muchos servicios de soporte diferentes para desarrolladores (puede escuchar historias sobre algunos de ellos en los viejos mitaps:
Op! DevOps! 2016 y
Op! DevOps! 2017 ). También desarrollamos herramientas de automatización interna, incluidas
soluciones de código abierto .
En los últimos cinco años, se han acumulado muchas operaciones del mismo tipo y de rutina en nuestro trabajo, y de nuestros desarrolladores de otros departamentos provienen principalmente las llamadas
tareas estándar , cuya solución está automatizada en su totalidad o en parte, no causa dificultades a los artistas y no requiere cantidades significativas de trabajo. Junto con las instrucciones principales, analizamos tales tareas y pudimos distinguir ciertas categorías de trabajo o
etapas de producción , dividimos las etapas en pasos indivisibles, y la
cadena tecnológica de producción consta de varias etapas.
El ejemplo más simple de una cadena tecnológica son las etapas de montaje, implementación y prueba de cada uno de nuestros productos dentro de la empresa. A su vez, por ejemplo, la fase de compilación consiste en muchos pasos típicos separados: descargar la fuente de GitLab, preparar dependencias y bibliotecas de terceros, pruebas de unidad y análisis de código estático, ejecutar un script de compilación en GitLab CI, publicar artefactos en la tienda en Artifactory y generar notas de lanzamiento a través de nuestra herramienta interna ChangelogBuilder.
Puede leer sobre las tareas típicas de DevOps en nuestros otros artículos sobre Habré: "
Experiencia personal: cómo se ve nuestro sistema de integración continua " y "
Automatización de los procesos de desarrollo: cómo implementamos las ideas de DevOps en tecnologías positivas ".
Muchas cadenas de producción típicas forman el
proceso de producción . Un enfoque estándar para describir procesos es utilizar modelos IDEF0 funcionales.
Un ejemplo de modelado de un proceso de producción de CI
Prestamos especial atención al desarrollo de proyectos modelo para un sistema de integración continua. Esto nos permitió lograr la unificación de proyectos, destacando el llamado
esquema de ensamblaje de lanzamiento con avances .
Así es como funciona. Todos los proyectos parecen típicos: incluyen la configuración de ensamblajes que se incluyen en el repositorio de instantáneas en Artifactory, después de lo cual se implementan y prueban en bancos de prueba, y luego se promocionan al repositorio de lanzamiento. El servicio Artifactory es el único punto de distribución de todos los artefactos de construcción entre equipos y otros servicios.
Si simplificamos y generalizamos en gran medida nuestro esquema de lanzamiento, entonces incluye los siguientes pasos:
- montaje de productos multiplataforma,
- despliegue para probar stands,
- ejecutando pruebas funcionales y de otro tipo,
- promoción de compilaciones probadas para liberar repositorios en Artifactory,
- Publicar versiones de lanzamiento para actualizar servidores,
- entrega de ensamblajes y actualizaciones a producción,
- Inicie la instalación y las actualizaciones del producto.
Por ejemplo, considere el modelo tecnológico de este esquema de lanzamiento típico (en adelante denominado simplemente Modelo) en forma de un modelo IDEF0 funcional. Refleja las etapas principales de nuestro proceso de CI. Los modelos IDEF0 utilizan la denominada
notación ICOM (mecanismo de entrada-control-salida) para describir qué recursos se utilizan en cada etapa, en función de qué reglas y requisitos, qué se hace, qué se produce y qué mecanismos, servicios o personas implementar una etapa específica.
Al hacer clic en la imagen se abrirá a tamaño completoComo regla, en los modelos funcionales es más fácil descomponer y detallar la descripción de los procesos. Pero con un aumento en el número de elementos, comprender en ellos algo se vuelve cada vez más difícil. Pero en el desarrollo real también hay pasos auxiliares: monitoreo, certificación de productos, automatización de procesos de trabajo y otros. Es por el problema de escala que abandonamos tal descripción.
El nacimiento de la esperanza
En un libro, encontraron viejos mapas soviéticos que describen procesos tecnológicos (que, por cierto, ahora se usan en muchas empresas y universidades estatales). ¡Espera, espera, porque también tenemos un proceso tecnológico! ... Hay etapas, resultados, métricas, requisitos, indicadores, etc. ... ¿Por qué no intentar aplicar mapas tecnológicos a nuestros transportadores de productos? Había un sentimiento: “¡Aquí está! ¡Encontramos el hilo correcto, es hora de tirar bien!
En una tabla simple, decidimos fijar los productos en columnas y en las filas etapas y pasos tecnológicos del transportador de productos. Etapas: esto es algo grande, por ejemplo, la etapa de ensamblaje del producto. Y los pasos son algo más pequeño y más detallado, por ejemplo, el paso de descargar el código fuente al servidor de compilación o el paso de compilar el código.
En las intersecciones de filas y columnas del mapa, colocamos los estados para una etapa y un producto en particular. Para los estados, se han definido muchos estados:
- Sin datos , o poco práctico. Es necesario realizar un análisis de la relevancia de la etapa en el producto. O bien el análisis ya se ha llevado a cabo, pero la etapa actualmente no es necesaria o no está económicamente justificada.
- Pospuesto o irrelevante en este momento. Se necesita una etapa en el transportador, pero este año no hay fuerzas para la implementación.
- Programado La etapa está prevista para la implementación de este año.
- Esta implementado . La etapa en el transportador se implementa en el volumen requerido.
Llenar la mesa comenzó en cuanto al proyecto. Al principio, se clasificaron las etapas y los pasos de un proyecto y se registraron estados para ellos. Luego tomaron el siguiente proyecto, registraron los estados en él y agregaron los pasos y los pasos que estaban ausentes en proyectos anteriores. Como resultado, obtuvimos las etapas y los pasos de todo nuestro transportador de producción y sus estados en un proyecto específico. Resultó algo similar a la matriz de competencias del transportador de productos. Llamamos a tal matriz un mapa tecnológico.
Utilizando el mapa tecnológico, coordinamos metrológicamente de manera razonable con los planes y objetivos de trabajo anuales de los equipos que queremos lograr conjuntamente: qué etapas agregamos este año al proyecto y cuáles dejamos para más adelante. Además, en el proceso de trabajo, podemos recibir mejoras en las etapas que realizamos para un solo producto. Luego ampliamos nuestro mapa e introducimos esta mejora como una etapa o un nuevo paso, luego analizamos cada producto y descubrimos la conveniencia de replicar la mejora.
Pueden objetarnos: “Esto es todo, por supuesto, bueno, solo con el tiempo el número de pasos y etapas se volverá prohibitivamente grande. ¿Cómo ser?
Hemos introducido descripciones estándar y suficientemente completas de los requisitos para cada etapa y paso, de modo que todos los entiendan por igual dentro de la empresa. Con el tiempo, al introducir mejoras, un paso puede ser absorbido en otro paso o paso, luego se "colapsarán". Al mismo tiempo, todos los requisitos y matices tecnológicos se ajustan a los requisitos de una etapa o etapa generalizadora.
¿Cómo evaluar el efecto de replicar decisiones? Utilizamos un enfoque extremadamente simple: atribuimos los costos de capital iniciales para la implementación de la nueva etapa a los costos anuales generales de alimentos, y luego los dividimos en todos al replicar.
Partes del desarrollo ya se reflejan como pasos y pasos en el mapa. Podemos influir en la reducción de los costos del producto mediante la introducción de la automatización para etapas típicas. Después de eso, consideramos los cambios en las características cualitativas, las métricas cuantitativas y la ganancia recibida por los equipos (en horas hombre o horas máquina de ahorro).
Diagrama de flujo del proceso
Si tomamos todas nuestras etapas y pasos, codificamos con etiquetas y nos expandimos en una cadena, entonces resultará ser muy largo e incomprensible (solo la "cola de pitón" de la que hablamos al principio del artículo):
[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]
Estas son las etapas del ensamblaje del producto [Compilar], su implementación para probar servidores [Implementar], probar [Prueba], promoción de ensamblajes para liberar repositorios basados en pruebas [Promover], generación y publicación de licencias [Licencia], publicación [Publicar] en el servidor de actualización GUS y entregando a los servidores de actualización de FLUS, instalando y actualizando componentes del producto en la infraestructura del cliente usando la Gestión de la Configuración del Producto [Instalar], así como recolectando telemetría [Telemetría] de los productos instalados.
Además de ellos, hay etapas separadas: monitoreo del estado de la infraestructura [InfMonitoring], control de versión del código fuente [SourceCodeControl], preparación del entorno de ensamblaje [Preparar], gestión del proyecto [Flujo de trabajo], proporcionar a los equipos herramientas de comunicación [Comunicación], certificación del producto [Certificación] y proporcionar autosuficiencia de los procesos de CI [CISelfSufficiency] (por ejemplo, independencia de las asambleas de Internet). Ni siquiera consideraremos docenas de pasos en nuestros procesos, porque son muy específicos.
Será mucho más fácil de entender y echar un vistazo a todo el proceso de producción, si se presenta en forma de un
mapa tecnológico ; Esta es una tabla en la que los pasos de producción individuales y los pasos descompuestos del Modelo se escriben en filas, y las columnas describen lo que se hace en cada paso o paso. El énfasis principal se pone en los recursos que proporcionan cada etapa y la delimitación de áreas de responsabilidad.
El mapa para nosotros es una especie de clasificador. Refleja las grandes partes tecnológicas de la producción de alimentos. Gracias a esto, se hizo más fácil para nuestro equipo de automatizadores interactuar con los desarrolladores y planificar conjuntamente la implementación de las etapas de automatización, así como comprender qué mano de obra y recursos (humanos y de hierro) se requieren.
Dentro de nuestra empresa, se genera automáticamente un mapa a partir de una plantilla jinja en forma de un archivo HTML normal, y luego se carga en el servidor de páginas de GitLab.
Aquí se puede ver una captura de pantalla con un ejemplo de un mapa completamente generado.
Al hacer clic en la imagen se abrirá a tamaño completoEn resumen, el diagrama de flujo es una imagen generalizada del proceso de producción, que refleja claramente los bloques clasificados con funcionalidad típica.
La estructura de nuestro enrutamiento.
El mapa consta de varias partes:
- Área de encabezado: aquí hay una descripción general del mapa, se introducen conceptos básicos, se determinan los recursos básicos y los resultados del proceso de producción.
- Panel de información: aquí puede controlar la visualización de datos de productos individuales, proporciona un resumen de los pasos y pasos tomados para todos los productos en general.
- Mapa tecnológico: una descripción tabular del proceso tecnológico. En el mapa:
- se dan todas las etapas, pasos y sus códigos;
- Se da una breve y completa descripción de las etapas;
- Se indican los recursos y servicios de entrada utilizados en cada etapa;
- se indican los resultados de cada etapa y paso individual;
- Se indica el área de responsabilidad de cada paso y paso;
- Se identifican los recursos técnicos, por ejemplo, HDD (SSD), RAM, vCPU y horas hombre necesarias para apoyar el trabajo en esta etapa, tanto en el momento actual, un hecho como en el futuro, un plan;
- para cada producto se indica qué pasos tecnológicos o pasos para él se han implementado, se planifican para la implementación, son irrelevantes o no se implementan.
Toma de decisiones basada en el mapa tecnológico.
Después de examinar el mapa, es posible tomar algunas medidas, dependiendo del rol del empleado en la empresa (gerente de desarrollo, gerente de producto, desarrollador o probador):
- comprender qué pasos faltan en un producto o proyecto real y evaluar la necesidad de su implementación;
- para diferenciar zonas de responsabilidad entre varios departamentos si trabajan en diferentes etapas;
- acordar contratos en las entradas y salidas de las etapas;
- integre su etapa de trabajo en el proceso de desarrollo general;
- Evaluar con mayor precisión la necesidad de recursos que proporcionan cada una de las etapas.
Resumiendo todo lo anterior
El enrutamiento es universal, extensible y fácil de mantener. Es mucho más fácil desarrollar y mantener una descripción de los procesos de esta forma que en un riguroso modelo académico IDEF0. Además, la descripción tabular es más simple, más familiar y mejor estructurada que el modelo funcional.
Para la implementación técnica de los pasos, somos responsables de la herramienta interna especial CrossBuilder, una herramienta de capa intermedia entre los sistemas, servicios e infraestructura de CI. El desarrollador no necesita ver su bicicleta: en nuestro sistema CI es suficiente ejecutar uno de los scripts (la llamada tarea) de la herramienta CrossBuilder, que la ejecutará correctamente teniendo en cuenta las peculiaridades de nuestra infraestructura.
Resumen
El artículo resultó ser bastante largo, pero esto es inevitable cuando se describe el modelado de procesos complejos. Al final, quiero arreglar brevemente nuestras ideas principales:
- El objetivo de presentar las ideas de DevOps en nuestra compañía es una reducción constante en el costo de producción y mantenimiento de los productos de la compañía en términos cuantitativos (horas hombre u horas máquina, vCPU, RAM, Disco).
- Una forma de reducir el costo total de desarrollo es minimizar el costo de realizar tareas en serie típicas: etapas y pasos del proceso tecnológico.
- Una tarea típica es una tarea cuya solución está automatizada total o parcialmente, no causa dificultades a los artistas y no requiere costos laborales significativos.
- El proceso de producción consta de etapas, las etapas se dividen en pasos indivisibles, que son tareas típicas de diferente escala y volumen.
- Desde tareas típicas dispares, hemos llegado a cadenas tecnológicas complejas y modelos multinivel del proceso de producción, que pueden describirse mediante un modelo IDEF0 funcional o un diagrama de flujo más simple.
- Una ruta es una presentación tabular de los pasos y pasos de un proceso de fabricación. Lo más importante: el mapa le permite ver todo el proceso, en grandes piezas con la posibilidad de detallar.
- Según el diagrama de flujo, puede evaluar la necesidad de implementar etapas en un producto en particular, delimitar áreas de responsabilidad, acordar contratos para las entradas y salidas de las etapas y evaluar con mayor precisión la necesidad de recursos.
En los siguientes artículos, hablaremos con más detalle sobre qué herramientas técnicas se utilizan para implementar ciertas etapas tecnológicas en nuestro mapa.
Autores del artículo: