Imagen:
¡Hola a todos! Somos ingenieros de automatización de la empresa. y apoyamos el desarrollo de los productos de la empresa: apoyamos todo el proceso de ensamblaje desde la confirmación de una línea de código por parte de los desarrolladores hasta la publicación de productos terminados y licencias en servidores de actualización. Informalmente, nos llamamos ingenieros DevOps. En este artículo queremos hablar sobre las etapas tecnológicas del proceso de producción de software, cómo las vemos y cómo las clasificamos.
Del material aprenderá sobre la complejidad de coordinar el desarrollo de múltiples productos, sobre qué es un mapa tecnológico y cómo ayuda a optimizar y replicar soluciones, cuáles son las principales etapas y pasos del proceso de desarrollo, cómo son las áreas de responsabilidad entre DevOps y los equipos de nuestra empresa.
Acerca del caos y DevOps
Brevemente, el concepto de DevOps incluye herramientas y servicios de desarrollo, así como metodologías y mejores prácticas para su uso. Destaquemos el mundial. objetivo de la implementación de ideas DevOps en nuestra empresa: se trata de una reducción consistente en el costo de producción y mantenimiento de los productos en términos cuantitativos (horas-hombre o horas-máquina, CPU, RAM, Disco, etc.). La forma más fácil y obvia de reducir el costo total de desarrollo a nivel de toda la empresa es minimizando el costo de realizar tareas seriales típicas en todas las etapas de producción. Pero, ¿cuáles son estas etapas, cómo separarlas del proceso general, en qué pasos consisten?
Cuando una empresa desarrolla un producto, todo está más o menos claro: suele haber una hoja de ruta y un esquema de desarrollo comunes. Pero, ¿qué hacer cuando la línea de productos se amplía y hay más productos? A primera vista, tienen procesos y líneas de ensamblaje similares, y comienza el juego de "encontrar X diferencias" en registros y scripts. Pero, ¿qué pasa si ya hay más de 5 proyectos en desarrollo activo y se requiere soporte para varias versiones desarrolladas durante varios años? ¿Queremos reutilizar el máximo número posible de soluciones en los pipelines de productos o estamos dispuestos a gastar dinero en un desarrollo único para cada uno?
¿Cómo encontrar un equilibrio entre la unicidad y las soluciones en serie?
Estas preguntas comenzaron a surgir ante nosotros cada vez más a menudo desde 2015. El número de productos creció, y tratamos de expandir al mínimo nuestro departamento de automatización (DevOps), que apoyaba las líneas de ensamblaje de estos productos. Al mismo tiempo, queríamos replicar tantas soluciones como fuera posible entre productos. Después de todo, ¿por qué hacer lo mismo en diez productos de formas diferentes?
Director de Desarrollo: "Chicos, ¿podemos evaluar de alguna manera lo que DevOps hace por los productos?"
nosotros: “No sabemos, no hicimos esa pregunta, pero ¿qué indicadores se deben considerar?”
Director de Desarrollo: "¡Quién sabe! Pensar…"
Como en aquella famosa película: "¡Estoy en un hotel!.." - "Uh... ¿Me puedes indicar el camino?" Al reflexionar, llegamos a la conclusión de que primero debemos decidir sobre los estados finales de los productos; esto se convirtió en nuestro primer objetivo.
Entonces, ¿cómo analiza una docena de productos con equipos bastante grandes de 10 a 200 personas y determina métricas medibles al replicar soluciones?
1:0 a favor de Chaos, 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 del quinto cuadrado 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 con más de 50 pasos. Me sentí triste y quería aullar a la luna; en general, no encajaba.
Tareas típicas de producción
Modelar los procesos de producción es un trabajo muy complejo y minucioso: necesita recopilar, procesar y analizar una gran cantidad de datos de varios departamentos y cadenas de producción. Puedes leer más sobre esto en el artículo "".
Cuando comenzamos a modelar nuestro proceso de producción, teníamos un objetivo específico: transmitir a todos los empleados involucrados 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 la confirmación de una línea 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 delimitan las áreas de responsabilidad de cada etapa,
- qué contratos existen a la entrada y salida de cada etapa.
Al hacer clic en la imagen se abrirá en tamaño completo.
Nuestro trabajo en la empresa se divide en varias áreas funcionales. La dirección de infraestructura se dedica a la optimización del funcionamiento de todos los recursos "de hierro" del departamento, así como a la automatización del despliegue de máquinas virtuales y del entorno sobre las mismas. La dirección de monitoreo proporciona control de desempeño del 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 los proyectos. Y, finalmente, la dirección webdev proporciona la publicación de lanzamientos en los servidores de actualización GUS y FLUS, así como la licencia de productos que utilizan el servicio LicenseLab. Para respaldar la canalización de producción, configuramos y mantenemos muchos servicios de soporte diferentes para desarrolladores (puede escuchar historias sobre algunos de ellos en reuniones anteriores: и). También desarrollamos herramientas de automatización interna, incluyendo .
En los últimos cinco años, nuestro trabajo ha acumulado muchas operaciones del mismo tipo y rutinarias, y nuestros desarrolladores de otros departamentos provienen principalmente de los llamados tareas típicas, cuya solución está total o parcialmente automatizada, no causa dificultades a los ejecutantes y no requiere cantidades significativas de trabajo. Junto con las áreas líderes, analizamos tales tareas y pudimos identificar categorías individuales de trabajo, o pasos de producción, las etapas se dividieron en pasos indivisibles, y varias etapas se suman cadena de proceso de produccion.
El ejemplo más simple de una cadena tecnológica son las etapas de montaje, despliegue y prueba de cada uno de nuestros productos dentro de la empresa. A su vez, por ejemplo, la etapa de compilación consta de muchos pasos típicos separados: descargar fuentes de GitLab, preparar dependencias y bibliotecas de terceros, probar unidades y analizar código estático, ejecutar un script de compilación en GitLab CI, publicar artefactos en el repositorio en Artefacto y generación de 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é: ""Y"".
Muchas cadenas típicas de producción se forman proceso de manufactura. El enfoque estándar para describir procesos es usar modelos IDEF0 funcionales.
Un ejemplo de modelado de un proceso de CI de fabricación
Prestamos especial atención al desarrollo de proyectos estándar para un sistema de integración continua. Esto permitió lograr la unificación de proyectos, destacando los denominados esquema de compilación de lanzamiento con promociones.
Así es como funciona. Todos los proyectos parecen típicos: incluyen la configuración de ensamblajes que caen en el repositorio de instantáneas en Artifactory, luego de lo cual se implementan y prueban en bancos de prueba y luego se promueven al repositorio de lanzamiento. El servicio Artifactory es un único punto de distribución para todos los artefactos de compilación entre equipos y otros servicios.
Si simplificamos y generalizamos en gran medida nuestro esquema de lanzamiento, entonces incluye los siguientes pasos:
- ensamblaje de productos multiplataforma,
- despliegue a bancos de pruebas,
- ejecutando pruebas funcionales y de otro tipo,
- promover compilaciones probadas para liberar repositorios en Artifactory,
- publicación de compilaciones de lanzamiento en servidores de actualización,
- entrega de montajes y actualizaciones a producción,
- iniciando la instalación y actualización del producto.
Por ejemplo, considere el modelo tecnológico de este esquema de lanzamiento típico (en adelante, simplemente Modelo) en forma de un modelo IDEF0 funcional. Refleja las principales etapas de nuestro proceso de CI. Los modelos IDEF0 utilizan los llamados notación ICOM (Input-Control-Output-Mechanism) para describir qué recursos se utilizan en cada etapa, en función de qué reglas y requisitos se realiza el trabajo, cuál es la salida y qué mecanismos, servicios o personas implementan una etapa en particular.
Al hacer clic en la imagen se abrirá en tamaño completo.
Como regla, es más fácil descomponer y detallar la descripción de procesos en modelos funcionales. Pero a medida que crece el número de elementos, se vuelve cada vez más difícil entender algo en ellos. Pero en el desarrollo real también existen etapas auxiliares: seguimiento, certificación de productos, automatización de procesos de trabajo, entre otras. Es por el problema de escala que abandonamos esta descripción.
nacimiento de la esperanza
En un libro, encontramos viejos mapas soviéticos que describen procesos tecnológicos (que, por cierto, todavía se usan hoy en día en muchas empresas y universidades estatales). ¡Espere, espere, porque también tenemos un flujo de trabajo!... Hay etapas, resultados, métricas, requisitos, indicadores, etc., etc. ¿Por qué no intentar aplicar diagramas de flujo a nuestros pipelines de productos también? Había un sentimiento: “¡Esto es todo! Hemos encontrado el hilo adecuado, ¡es hora de tirar bien!
En una tabla simple, decidimos registrar los productos por columnas y las etapas tecnológicas y los pasos de la cartera de productos por filas. Los hitos son algo grande, como un paso de creación de productos. Y los pasos son algo más pequeños y detallados, como 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 las filas y columnas del mapa, colocamos los estados para una etapa y un producto específicos. Para los estados, se definió un conjunto de estados:
- Sin información - o inapropiado. Es necesario analizar la demanda de una etapa en el producto. O bien el análisis ya se ha realizado, pero actualmente no se necesita la etapa o no se justifica económicamente.
- pospuesto - o no relevante en este momento. Se necesita una etapa en la tubería, pero no hay fuerzas para la implementación este año.
- Programado. La etapa está prevista para su ejecución este año.
- Implementado. La etapa en la tubería se implementa en el volumen requerido.
El llenado de la mesa comenzó proyecto por proyecto. Primero, se clasificaron las etapas y pasos de un proyecto y se registraron sus estados. Luego tomaron el siguiente proyecto, arreglaron los estados en él y agregaron las etapas y pasos que faltaban en proyectos anteriores. Como resultado, obtuvimos las etapas y pasos de todo nuestro pipeline de producción y sus estados en un proyecto específico. Resultó algo similar a la matriz de competencias de canalización de productos. A esa matriz la llamamos mapa tecnológico.
Con la ayuda del mapa tecnológico, coordinamos metrológicamente de forma razonable con los equipos los planes de trabajo del año y los objetivos que queremos alcanzar juntos: qué etapas sumamos al proyecto este año y cuáles dejamos para más adelante. Además, en el transcurso del trabajo, es posible que tengamos mejoras en las etapas que hemos completado para un solo producto. Luego ampliamos nuestro mapa e introducimos esta mejora como una etapa o un nuevo paso, luego analizamos para cada producto y averiguamos la viabilidad de replicar la mejora.
Pueden objetarnos: “Todo esto, por supuesto, está bien, solo que con el tiempo la cantidad de pasos y etapas se volverá prohibitivamente grande. ¿Cómo ser?
Hemos introducido descripciones estándar y bastante completas de los requisitos para cada etapa y paso, para que todos los miembros de la empresa los entiendan de la misma manera. Con el tiempo, a medida que se introducen mejoras, un paso puede ser absorbido por otra etapa o paso, y luego "colapsarán". Al mismo tiempo, todos los requisitos y matices tecnológicos se ajustan a los requisitos de la etapa o paso de generalización.
¿Cómo evaluar el efecto de replicar soluciones? Usamos un enfoque extremadamente simple: atribuimos los costos de capital iniciales para la implementación de una nueva etapa a los costos generales anuales del producto y luego los dividimos entre todos al replicar.
Partes del desarrollo ya se muestran como hitos y pasos en el mapa. Podemos influir en la reducción del costo del producto mediante la introducción de 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).
Mapa tecnológico del proceso productivo
Si tomamos todas nuestras etapas y pasos, los codificamos con etiquetas y los expandimos en una cadena, resultará 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 de creación de productos [Crear], implementarlos en servidores de prueba [Implementar], probar [Prueba], promover compilaciones para liberar repositorios en función de los resultados de las pruebas [Promocionar], generar y publicar licencias [Licencia], publicar [ Publish] en el servidor de actualización GUS y entrega a los servidores de actualización FLUS, instalación y actualización de los componentes del producto en la infraestructura del cliente utilizando Product Configuration Management [Install], así como la recopilación de telemetría [Telemetry] de los productos instalados.
Además de ellos, se pueden distinguir etapas separadas: monitoreo del estado de la infraestructura [InfMonitoring], control de versiones del código fuente [SourceCodeControl], preparación del entorno de compilación [Preparar], gestión de proyectos [Flujo de trabajo], provisión de herramientas de comunicación a los equipos [Comunicación], certificación de productos [ Certificación] y garantizar la autosuficiencia de los procesos de CI [CISelfSufficiency] (por ejemplo, independencia de las asambleas de Internet). Ni siquiera se considerarán decenas de pasos en nuestros procesos, porque son muy específicos.
Será mucho más fácil de entender y ver todo el proceso de producción si se presenta en la forma mapa tecnológico; esta es una tabla en la que se escriben en filas las etapas individuales de producción y los pasos descompuestos del Modelo, y en columnas una descripción de lo que se hace en cada etapa o paso. El énfasis principal se pone en los recursos que aporta 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 productos. Gracias a ello, se hizo más fácil para nuestro equipo de automatización interactuar con los desarrolladores y planificar conjuntamente la implementación de las etapas de automatización, así como comprender qué costos de mano de obra y recursos (humanos y de hardware) se requerirán para esto.
Dentro de nuestra empresa, el mapa se genera automáticamente a partir de la plantilla jinja como un archivo HTML normal y luego se carga en el servidor de páginas de GitLab. Se puede ver una captura de pantalla con un ejemplo de un mapa completamente generado .
Al hacer clic en la imagen se abrirá en tamaño completo.
En resumen, el mapa tecnológico es una imagen generalizada del proceso de producción, que refleja bloques claramente clasificados con una funcionalidad típica.
Estructura de nuestra hoja de ruta
El mapa consta de varias partes:
- Área de título: aquí hay una descripción general del mapa, se introducen conceptos básicos, se definen los principales recursos y resultados del proceso de producción.
- Tablero: aquí puede controlar la visualización de datos para productos individuales, se proporciona un resumen de las etapas implementadas y los pasos en general para todos los productos.
- 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 dan descripciones breves y completas de las etapas;
- se indican los recursos de insumos y servicios utilizados en cada etapa;
- se indican los resultados de cada etapa y un paso separado;
- se indica el área de responsabilidad para cada etapa y paso;
- se han determinado los recursos técnicos, tales como HDD (SSD), RAM, vCPU, y las horas-hombre necesarias para soportar el trabajo en esta etapa, tanto en el momento actual - un hecho, como a futuro - un plan;
- para cada producto se indica qué etapas o pasos tecnológicos del mismo han sido implementados, planificados para implementar, irrelevantes o no implementados.
Toma de decisiones en base al mapa tecnológico
Después de examinar el mapa, es posible realizar algunas acciones, según el rol del empleado en la empresa (gerente de desarrollo, gerente de producto, desarrollador o probador):
- comprender qué etapas faltan en un producto o proyecto real y evaluar la necesidad de su implementación;
- delimitar las áreas de responsabilidad entre varios departamentos si trabajan en diferentes etapas;
- acordar contratos en las entradas y salidas de los escenarios;
- integre su etapa de trabajo en el proceso de desarrollo general;
- Evaluar con mayor precisión la necesidad de recursos que aportan cada una de las etapas.
Resumiendo todo lo anterior
El enrutamiento es versátil, extensible y fácil de mantener. Es mucho más fácil desarrollar y mantener una descripción de procesos de esta forma que en un modelo IDEF0 académico estricto. Además, una descripción tabular es más simple, más familiar y mejor estructurada que un modelo funcional.
Para la implementación técnica de los pasos, tenemos una herramienta interna especial, CrossBuilder, una herramienta de capa entre los sistemas, servicios e infraestructura de CI. El desarrollador no necesita cortar su bicicleta: en nuestro sistema de CI, basta con ejecutar uno de los scripts (la llamada tarea) de la herramienta CrossBuilder, que lo ejecutará correctamente, teniendo en cuenta las características de nuestra infraestructura. .
resultados
El artículo resultó ser bastante largo, pero esto es inevitable cuando se describe el modelado de procesos complejos. Al final, me gustaría fijar brevemente nuestras ideas principales:
- El objetivo de implementar las ideas de DevOps en nuestra empresa es reducir de manera constante el costo de producción y mantenimiento de los productos de la empresa en términos cuantitativos (horas-hombre o horas-máquina, vCPU, RAM, Disco).
- La 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á total o parcialmente automatizada, no causa dificultades para los ejecutantes y no requiere costos de mano de obra 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 alcance.
- De tareas típicas dispares, hemos llegado a cadenas tecnológicas complejas y modelos multinivel del proceso de producción, que pueden ser descritos por un modelo IDEF0 funcional o un mapa tecnológico más simple.
- El mapa tecnológico es una representación tabular de las etapas y pasos del proceso productivo. Lo más importante: el mapa te permite ver todo el proceso en su totalidad, en grandes piezas con posibilidad de detallarlas.
- Con base en el mapa tecnológico, es posible evaluar la necesidad de introducir etapas en un producto en particular, delimitar áreas de responsabilidad, acordar contratos en las entradas y salidas de las etapas y evaluar con mayor precisión la necesidad de recursos.
En los siguientes artículos, describiremos con más detalle qué herramientas técnicas se utilizan para implementar ciertas etapas tecnológicas en nuestro mapa.
Autores del artículo:
- — Jefe de Automatización (DevOps) en Positive Technologies
- - Diputado Jefe del Departamento de Automatización (DevOps) en Positive Technologies
Fuente: habr.com