Una vez suministramos un sistema de gestión de documentos electrónicos a un cliente en una instalación. Y luego a otro objeto. Y uno más. Y el cuarto y el quinto. Nos dejamos llevar tanto que llegamos a 10 objetos repartidos. Resultó poderoso... especialmente cuando llegamos a implementar los cambios. Como parte de la entrega al circuito de producción, cinco escenarios del sistema de prueba requirieron finalmente 5 horas y entre 10 y 6 empleados. Estos costes nos obligaron a realizar las entregas con la menor frecuencia posible. Después de tres años de funcionamiento, no pudimos soportarlo y decidimos darle vida al proyecto con una pizca de DevOps.
Ahora todas las pruebas se realizan en 3 horas y en ellas participan 3 personas: un ingeniero y dos probadores. Las mejoras se expresan claramente en números y conducen a una reducción del tan querido TTM. Según nuestra experiencia, hay muchos más clientes que pueden beneficiarse de DevOps que aquellos que siquiera lo conocen. Por eso, para acercar DevOps a las personas, hemos desarrollado un constructor sencillo, del que hablaremos con más detalle en este post.
Ahora te lo contamos con más detalle. Una empresa de energía está implementando un sistema de gestión de documentos técnicos en 10 grandes instalaciones. No es fácil navegar en proyectos de esta escala sin DevOps, porque una gran parte del trabajo manual retrasa enormemente el trabajo y también reduce la calidad: todo trabajo manual está plagado de errores. Por otro lado, hay proyectos en los que solo hay una instalación, pero todo debe funcionar de forma automática, constante y sin fallas; por ejemplo, los mismos sistemas de flujo 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, en producción la configuración se perderá y todo colapsará.
Normalmente trabajamos con el cliente a través de un contrato y en este caso nuestros intereses divergen ligeramente. El cliente examina el proyecto estrictamente dentro del presupuesto y las especificaciones técnicas. Puede resultar difícil explicarle los beneficios de diversas prácticas de DevOps que no están incluidas en las especificaciones técnicas. ¿Qué pasa si está interesado en lanzamientos rápidos con valor comercial agregado o en crear un canal de automatización?
Lamentablemente, cuando se trabaja con un costo preaprobado, no siempre se encuentra este interés. En nuestra práctica, hubo un caso en el que tuvimos que retomar el desarrollo de un contratista sin escrúpulos y descuidado. Fue terrible: no había códigos fuente actualizados, el código base del mismo sistema era diferente en diferentes instalaciones, la documentación estaba parcialmente ausente y en parte era de pésima calidad. Por supuesto, el cliente no tenía control sobre el código fuente, ensamblador, lanzamientos, etc.
Hasta ahora no todo el mundo conoce DevOps, pero en cuanto hablamos de sus ventajas, del ahorro real de recursos, a todos los clientes se les iluminan los ojos. Por lo tanto, la cantidad de solicitudes que incluyen DevOps aumenta con el tiempo. Aquí, para hablar fácilmente el mismo idioma con los clientes, necesitamos conectar rápidamente los problemas comerciales y las prácticas de DevOps que ayudarán a construir un canal de desarrollo adecuado.
Entonces, tenemos una serie de problemas, por un lado, y tenemos conocimientos, prácticas y herramientas de DevOps, por el otro. ¿Por qué no compartir la experiencia con todos?
Creando un constructor DevOps
Agile tiene su propio manifiesto. ITIL tiene su propia metodología. DevOps es menos afortunado: aún no ha adquirido plantillas ni estándares. A pesar de determinar la madurez de las empresas a partir de una evaluación de su desarrollo y prácticas operativas.
Afortunadamente, la conocida empresa Gartner en 2014 y analizó prácticas clave de DevOps y las relaciones entre ellas. En base a esto, publiqué una infografía:
Lo tomamos como base para nuestro . Cada una de las cuatro áreas tiene un conjunto de herramientas: las recopilamos en una base de datos, identificamos las más populares, identificamos puntos de integración y mecanismos de optimización adecuados. En total resultó 36 prácticas y 115 herramientas, una cuarta parte de los cuales son software libre o de código abierto. A continuación hablaremos de lo que hemos conseguido en cada área y, a modo de ejemplo, de cómo se implementó en el proyecto de creación de gestión documental técnica con el que iniciamos el post.
Процессы
En el notorio proyecto EDMS, el sistema de gestión de documentación técnica se implementó según el mismo esquema en cada una de las 10 instalaciones. La instalación incluye 4 servidores: servidor de base de datos, servidor de aplicaciones, indexación de texto completo y gestión de contenidos. En la instalación operan dentro de un único nodo y están ubicados en el centro de datos de las instalaciones. Todos los objetos difieren ligeramente en infraestructura, pero esto no interfiere con la interacción global.
Primero, de acuerdo con las prácticas de DevOps, automatizamos la infraestructura localmente, luego llevamos la entrega al circuito de prueba y luego al producto del cliente. Cada proceso se desarrolló paso a paso. La configuración del entorno se fija en el sistema de código fuente, teniendo en cuenta que el kit de distribución está compilado para la actualización automática. En caso de cambios de configuración, los ingenieros simplemente deben realizar los cambios apropiados en el sistema de control de versiones y luego la actualización automática se realizará sin problemas.
Gracias a este enfoque, el proceso de prueba se ha simplificado enormemente. Anteriormente, el proyecto contaba con probadores que no hacían más que actualizar manualmente los stands. Ahora simplemente vienen, ven que todo funciona y hacen cosas más útiles. Cada actualización se prueba automáticamente, desde el nivel superficial hasta la automatización de escenarios empresariales. Los resultados se publican como informes separados en TestRail.
Cultura
La experimentación continua se explica mejor mediante el ejemplo del diseño de pruebas. Probar un sistema que aún no existe es un trabajo creativo. Al escribir un plan de prueba, es necesario comprender cómo realizar la prueba correctamente y qué ramas seguir. Y también buscar un equilibrio entre tiempo y presupuesto para determinar el número óptimo de controles. Es importante elegir exactamente las pruebas necesarias, pensar en cómo interactuará el usuario con el sistema, tener en cuenta el entorno y posibles factores externos. Es imposible prescindir de una experimentación continua.
Ahora sobre la cultura de la interacción. Anteriormente, había dos bandos opuestos: ingenieros y desarrolladores. Los desarrolladores dijeron: “No nos importa cómo se lanzará. Ustedes son ingenieros, son inteligentes, asegúrense de que funcione sin fallas". Los ingenieros respondieron: “Ustedes los desarrolladores son demasiado descuidados. Seamos más cuidadosos y reproduciremos tus lanzamientos con menos frecuencia. Porque cada vez que nos das un código con fugas, no tenemos claro cómo interactuar”.. Se trata de una cuestión de interacción cultural que se estructura de forma diferente desde la perspectiva de DevOps. Aquí, tanto los ingenieros como los desarrolladores forman parte de un único equipo que se centra en un software en constante cambio, pero al mismo tiempo fiable.
Dentro de un mismo equipo, los especialistas están decididos a ayudarse unos a otros. ¿Como era antes? Por ejemplo, se estaban preparando unas instrucciones de implementación gruesas, de unas 50 páginas, que el ingeniero las leyó, no entendió algo, maldijo y a las tres de la madrugada le pidió al desarrollador que comentara. El desarrollador comentó y también maldijo: al final nadie quedó contento. Además, naturalmente, hubo algunos errores porque no puedes recordar todo lo que está en las instrucciones. Y ahora el ingeniero, junto con el desarrollador, está escribiendo un script para la implementación automatizada de la infraestructura de software de aplicaciones. Y se hablan prácticamente en el mismo idioma.
personas
El tamaño del equipo está determinado por el alcance de la actualización. El equipo se forma durante la formación de la entrega e incluye a los interesados del equipo general del proyecto. Luego se redacta un plan de actualización con los responsables de cada etapa y el equipo informa a medida que avanza. Todos los miembros del equipo son intercambiables. Como parte del equipo, también tenemos un desarrollador de respaldo, pero casi nunca tiene que conectarse.
Tecnología
En el diagrama de tecnología, se resaltan algunos puntos, pero debajo de ellos hay un montón de tecnologías; se podría publicar un libro completo con sus descripciones. Así que destacaremos los más interesantes.
Infraestructura como Código
Ahora bien, probablemente este concepto no sorprenda a nadie, pero antes las descripciones de las infraestructuras dejaban mucho que desear. , los entornos de prueba eran únicos, eran apreciados y apreciados, de ellos se desprendían partículas de polvo.
Hoy en día 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 un sistema de control de versiones y se actualizan rápidamente. Anteriormente, cuando era necesario entregar un paquete en un stand, aparecía un hueco en la configuración. Ahora sólo necesitas agregar una línea al código fuente.
Además de los scripts y canalizaciones de infraestructura, 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 basándose en las funciones descritas, por ejemplo, en el plan de prueba, y también reutilizar casos de prueba.
Entrega y seguimiento continuos.
Sobre DevOps, hablamos sobre cómo seleccionamos herramientas para implementar la entrega y el monitoreo continuos. A menudo, no es necesario reescribir nada; basta con utilizar scripts escritos previamente, crear correctamente la integración entre componentes y crear una consola de administración común. Y todos los procesos se pueden iniciar usando un botón o programando.
En inglés existen diferentes conceptos, Entrega Continua y Despliegue Continuo. Ambos pueden traducirse como “entrega continua”, pero en realidad existe una ligera diferencia entre ellos. En nuestro proyecto para el flujo de documentos técnicos de una empresa de energía distribuida, más bien se utiliza la Entrega, cuando la instalación para la producción se realiza por orden. En la implementación, la instalación se produce automáticamente. La entrega continua en este proyecto generalmente se ha convertido parte central de DevOps.
En general, al recopilar ciertos parámetros, se puede comprender claramente por qué las prácticas de DevOps son útiles. Y transmítaselo a la dirección, que realmente ama los números. El número total de lanzamientos, el tiempo de ejecución de las etapas del script, la proporción de lanzamientos exitosos: todo esto afecta directamente el tiempo de comercialización favorito de todos, es decir, el tiempo desde el compromiso con el sistema de control de versiones hasta el lanzamiento de una versión en un entorno de producción. Con la implementación de las herramientas necesarias, los ingenieros reciben valiosos indicadores por correo y el director del proyecto los ve en el tablero. De esta manera podrá evaluar inmediatamente los beneficios de las nuevas herramientas. Y puede probarlos en su infraestructura utilizando el diseñador DevOps.
¿Quién necesitará nuestro ?
No finjamos: para empezar, nos resultó útil. Como ya hemos dicho, es necesario hablar el mismo idioma con el cliente y, con la ayuda del diseñador de DevOps, podemos esbozar rápidamente las bases de dicha conversación. Los especialistas en negocios podrán evaluar por sí mismos lo que necesitan y así desarrollarse más rápido. Intentamos que el diseñador fuera lo más detallado posible, agregando un montón de descripciones para que cualquier usuario entienda lo que está eligiendo.
El formato del diseñador le permite tener en cuenta los desarrollos existentes de la empresa en procesos de construcción y automatización. No hay necesidad de derribarlo todo y reconstruirlo si sólo se pueden elegir soluciones que se integren bien con los procesos existentes y que simplemente puedan llenar los vacíos.
Quizás su desarrollo ya haya pasado a un nivel superior y nuestra herramienta le parezca demasiado "de capitán". Pero lo encontramos útil para nosotros y esperamos que sea útil para algunos de los lectores. te recordamos al diseñador; en todo caso, recibirá el diagrama inmediatamente después de ingresar los datos iniciales. Estaremos agradecidos por sus comentarios y adiciones.
Fuente: habr.com