De alguna manera ponemos al cliente en un sistema de gestión de documentos electrónicos de un objeto. Y luego a otro objeto. Y uno mas. Y en el cuarto y quinto. Se dejaron llevar tanto que llegaron a 10 objetos distribuidos. Potente sucedió ... especialmente cuando llegamos a la entrega de cambios. Como parte del suministro al circuito productivo para 5 escenarios de sistemas de prueba, como resultado se necesitaron 10 horas y 6-7 empleados. Dichos costos nos obligaron a entregar lo menos posible. Después de tres años de operación, no pudimos soportarlo y decidimos condimentar el proyecto con una pizca de DevOps.
Ahora todas las pruebas pasan en 3 horas y participan 3 personas: un ingeniero y dos evaluadores. Las mejoras se expresan claramente en números y conducen a una reducción en el querido TTM. Según nuestra experiencia, hay muchos más clientes a los que DevOps puede ayudar que aquellos que incluso lo saben. Por lo tanto, para acercar DevOps a las personas, hemos desarrollado un constructor simple, del que hablaremos con más detalle en esta publicación.
Ahora lo contaremos con más detalle. En una compañía de energía en 10 grandes instalaciones, se está implementando un sistema de gestión de documentos técnicos. No es fácil aparecer en proyectos de esta magnitud sin DevOps, porque una gran proporción del trabajo manual retrasa en gran medida el trabajo y también reduce la calidad: todo el trabajo manual está lleno de errores. Por otro lado, hay proyectos en los que la instalación es única, pero es necesario que todo funcione de manera automática, constante y sin fallas, por ejemplo, los mismos sistemas de gestión de documentos en grandes organizaciones monolíticas. De lo contrario, alguien realizará la configuración manualmente, se olvidará de las instrucciones de implementación y, como resultado, la configuración se perderá en el producto y todo se bloqueará.
Por lo general, trabajamos con el cliente a través de un contrato, en cuyo caso nuestros intereses divergen un poco. El cliente mira el proyecto estrictamente dentro del presupuesto y los conocimientos tradicionales. Puede ser difícil explicarle los beneficios de varias prácticas de DevOps que no forman parte de TK. ¿Y si está interesado en lanzamientos rápidos con valor agregado para el negocio, en construir una tubería de automatización?
Por desgracia, al trabajar con un valor preaprobado, este interés no siempre es posible de encontrar. En nuestra práctica, hubo un caso en el que tuvimos que retomar el desarrollo de un contratista inescrupuloso e inexacto. Fue un horror: no hay códigos fuente reales, la base del código del mismo sistema en diferentes instalaciones es diferente, la documentación faltaba en parte, en parte era de una calidad terrible. Por supuesto, el cliente no tenía control de origen, ensamblaje, lanzamientos, etc.
Hasta ahora, no todo el mundo sabe acerca de DevOps, pero vale la pena hablar sobre sus ventajas, sobre el ahorro real de recursos, los ojos se iluminan para todos los clientes. Por lo tanto, cada vez hay más solicitudes que involucran a DevOps. Aquí, para hablar fácilmente el mismo idioma con los clientes, necesitamos conectar rápidamente los problemas comerciales y las prácticas de DevOps, lo que ayudará a construir una tubería de desarrollo adecuada.
Entonces, tenemos un conjunto de problemas por un lado, hay conocimiento, prácticas y herramientas DevOps por el otro. ¿Por qué no compartir la experiencia con todos?
Crear un constructor de DevOps
Ágil tiene su propio manifiesto. ITIL tiene su propia metodología. DevOps es menos afortunado: aún no ha adquirido plantillas y estándares. Aunque
algunos intentan determinar el grado de madurez de las empresas basándose en una evaluación de sus métodos de desarrollo y operación.
Afortunadamente, la notoria compañía Gartner en 2014
recopiló y analizó las prácticas clave de DevOps y las relaciones entre ellas. Basado en esto, publiqué la infografía:
Lo tomamos como la base de nuestro
constructor . En cada una de las cuatro áreas hay un conjunto de herramientas: las recopilamos en la base de datos, identificamos los puntos de integración más populares e identificados y los mecanismos de optimización adecuados. En total, resultaron
36 prácticas y 115 herramientas , una cuarta parte de las cuales son software abierto o libre. A continuación, hablaremos sobre lo que hicimos en cada área y, por ejemplo, cómo se implementó en el proyecto para crear un flujo de trabajo técnico desde el que comenzamos la publicación.
Los procesos
En el famoso proyecto EDMS, el sistema de gestión de documentación técnica se implementó de acuerdo con el mismo esquema en cada una de las 10 instalaciones. La instalación incluye 4 servidores: un servidor de base de datos, un servidor de aplicaciones, indexación de texto completo y gestión de contenido. En la instalación, trabajan dentro de un solo nodo, se encuentran en el centro de datos en las instalaciones. Todos los objetos varían ligeramente en la infraestructura, pero esto no interfiere con la interacción global.
Primero, de acuerdo con las prácticas de DevOps, automatizamos las infraestructuras localmente, luego llevamos la entrega al circuito de prueba y luego a la productividad del cliente. Cada proceso funcionó paso a paso. La configuración del entorno se fija en el sistema de código fuente, teniendo en cuenta la recopilación de la distribución para las actualizaciones automáticas. En el caso de cambios en la configuración, los ingenieros solo necesitan hacer los cambios apropiados en el sistema de control de versiones, y luego la actualización automática pasará sin problemas.
Gracias a este enfoque, el proceso de prueba se ha simplificado enormemente. Anteriormente, había probadores en el proyecto que solo hacían eso para actualizar manualmente los stands. Ahora solo vienen, ven que todo ha funcionado y se dedican a cosas más útiles. Cada actualización se prueba automáticamente, desde el nivel de la superficie hasta la automatización del escenario empresarial. Los resultados se presentan como informes separados en TestRail.
Cultura
La experimentación continua se explica mejor por el diseño de la prueba. Probar un sistema que aún no existe es un trabajo creativo. Al escribir un plan de prueba, debe comprender cómo realizar la prueba correctamente, qué ramas atravesar. Y también encuentre un equilibrio entre el tiempo y el presupuesto para determinar la cantidad óptima de cheques. Es importante elegir exactamente las pruebas necesarias, considerar cómo interactuará el usuario con el sistema, tener en cuenta el entorno y los posibles factores externos. No puedes prescindir de la experimentación continua.
Ahora sobre la cultura de la interacción. Solía haber dos partes beligerantes: ingenieros y desarrolladores. Los desarrolladores dijeron:
"No nos importa cómo comienza. Ustedes son ingenieros, son inteligentes, háganlo funcionar sin interrupción ” . Los ingenieros respondieron:
“Ustedes los desarrolladores son demasiado imprudentes. Tengamos más cuidado y publicaremos sus lanzamientos con menos frecuencia. Porque cada vez que nos pones un código holey, y cómo interactuamos no está claro " . Este es un problema de interacción cultural que, desde la perspectiva de DevOps, se construye de manera diferente. Aquí tiene ingenieros y desarrolladores que forman parte de un solo equipo que tiene como objetivo cambiar constantemente, pero al mismo tiempo un software confiable.
En la escala de un equipo, los especialistas están preparados para ayudarse mutuamente. ¿Cómo estuvo antes? Por ejemplo, se estaba preparando algún tipo de instrucción de despliegue grueso, páginas a 50. El ingeniero lo leyó, no entendió algo, juró y le pidió al desarrollador que comentara a las tres de la mañana. El desarrollador comentó y también juró: al final, nadie estaba contento. Además, naturalmente, hubo algunos errores, porque no recordará todo en las instrucciones. Y ahora el ingeniero, junto con el desarrollador, está escribiendo un script para la implementación automatizada de la infraestructura del software de la aplicación. Y hablan entre sí en casi el mismo idioma.
Personas
El tamaño del equipo está determinado por el alcance de la actualización. El equipo se recluta durante la formación del suministro, incluye a aquellos que lo deseen del equipo general del proyecto. Luego, se redacta un plan de actualización con responsabilidad para cada etapa, a medida que el equipo se ejecuta, informa. Todos los miembros del equipo son intercambiables. Como parte del equipo, también tenemos un desarrollador de seguridad, pero casi nunca tiene que conectarse.
Tecnología
En el esquema de tecnología, se destacan algunos puntos, pero debajo de ellos hay un montón de tecnologías, con sus descripciones, puede publicar un libro completo. Así destacaremos los más interesantes.
Infraestructura como código
Ahora, probablemente, no sorprenderá a nadie con este concepto, pero antes de que la descripción de las infraestructuras dejara mucho que desear.
Los ingenieros miraron con horror las instrucciones , los entornos de prueba eran únicos, fueron cuidados y apreciados, las partículas de polvo fueron expulsadas de ellos.
Ahora nadie tiene miedo de experimentar. Hay imágenes básicas de máquinas virtuales, hay escenarios listos para implementar entornos. Todas las plantillas y scripts se almacenan en el sistema de control de versiones y se actualizan rápidamente. Anteriormente, cuando era necesario entregar un paquete a un stand, aparecía un vacío de configuración. Ahora solo necesita agregar una línea en el código fuente.
Además de los escenarios de infraestructura y las tuberías, el enfoque de Documentación como Código también se utiliza para la documentación. Gracias a esto, es fácil conectar nuevas personas al proyecto, presentarles el sistema mediante las funciones descritas, por ejemplo, en el plan de prueba, y también reutilizar los casos de prueba.
Entrega continua y monitoreo
En nuestro último artículo sobre DevOps, hablamos sobre cómo elegimos las herramientas para implementar la entrega y el monitoreo continuos. A menudo no hay necesidad de reescribir nada: es suficiente usar scripts escritos previamente, construir correctamente la integración entre los componentes y crear una consola de administración común. Y todos los procesos pueden iniciarse con un solo botón o programación.
Hay diferentes conceptos en inglés, entrega continua e implementación continua. Ambos se pueden traducir como "entrega continua", pero de hecho hay una ligera diferencia entre ellos. En nuestro proyecto para la gestión de documentos técnicos de una empresa de energía distribuida, se utiliza Delivery, más bien, cuando la instalación para la venta se realiza por encargo. En la implementación, la instalación es automática. La entrega continua en este proyecto generalmente se ha convertido en una
parte central de DevOps .
En general, al recopilar ciertos parámetros, puede comprender claramente por qué las prácticas de DevOps son útiles. Y para transmitir esto al liderazgo, que es muy aficionado a los números. El número total de lanzamientos, el tiempo de ejecución de las etapas del guión, la proporción de lanzamientos exitosos: todo esto afecta directamente el tiempo de comercialización favorito de todos, es decir, el tiempo transcurrido desde el compromiso con el sistema de control de versiones hasta el lanzamiento de la versión en un entorno productivo. Con la introducción de las herramientas necesarias, los ingenieros reciben valiosos indicadores por correo, y el gerente del proyecto los ve en un tablero. Para que pueda apreciar de inmediato los beneficios de las nuevas herramientas. Y puede probarlos en su infraestructura utilizando el constructor DevOps.
No haremos trampa: para empezar, se volvió útil para nosotros. Como ya dijimos, el cliente necesita hablar el mismo idioma y, con la ayuda del constructor DevOps, podemos delinear rápidamente la base de dicha conversación. Los profesionales de negocios podrán evaluarse a sí mismos lo que necesitan y así desarrollarse más rápido. Intentamos hacer que el constructor sea lo más detallado posible, agregamos un montón de descripciones para que cualquier usuario entienda lo que elige.
El formato del diseñador le permite tener en cuenta la experiencia existente de la empresa en procesos de construcción y automatización. No tiene que desglosar todo y reconstruirlo si solo puede elegir soluciones que se integran normalmente en los procesos existentes que simplemente pueden llenar los vacíos.
Tal vez su desarrollo ya se haya movido a un nivel superior y nuestra herramienta parezca demasiado "de capitán". Pero lo encontramos útil para nosotros y esperamos que sea útil para algunos de los lectores. Le recordamos el
enlace al constructor; en todo caso, obtiene el circuito inmediatamente después de ingresar los datos de origen. Estaremos agradecidos por los comentarios y adiciones.