Unha vez fornecemos un sistema de xestión de documentos electrónicos a un cliente nunha instalación. E despois a outro obxecto. E un máis. E no cuarto, e no quinto. Deixámonos levar tanto que chegamos a 10 obxectos distribuídos. Resultou poderosamente... especialmente cando chegamos a entregar os cambios. Como parte da entrega ao circuíto de produción, 5 escenarios do sistema de probas requiriron finalmente 10 horas e 6-7 empregados. Estes custos obrigáronnos a facer entregas o menos posible. Despois de tres anos de funcionamento, non o podíamos soportar e decidimos darlle sabor ao proxecto cun chisco de DevOps.
Agora todas as probas teñen lugar en 3 horas, e nel participan 3 persoas: un enxeñeiro e dous probadores. As melloras exprésanse claramente en números e levan a unha redución do querido TTM. Segundo a nosa experiencia, hai moitos máis clientes que poden beneficiarse de DevOps que aqueles que aínda o saben. Polo tanto, para achegar DevOps ás persoas, desenvolvemos un construtor sinxelo, do que falaremos con máis detalle nesta publicación.
Agora imos contarche con máis detalle. Unha empresa enerxética está a implantar un sistema de xestión de documentos técnicos en 10 grandes instalacións. Non é fácil navegar por proxectos desta escala sen DevOps, porque unha gran parte do traballo manual atrasa moito o traballo e tamén reduce a calidade: todo o traballo manual está cheo de erros. Por outra banda, hai proxectos nos que só hai unha instalación, pero todo ten que funcionar de forma automática, constante e sen fallas, por exemplo, os mesmos sistemas de fluxo de documentos en grandes organizacións monolíticas. Se non, alguén fará a configuración manualmente, esquecerá as instrucións de implantación e, como resultado, na produción perderase a configuración e todo colapsará.
Normalmente traballamos co cliente a través dun contrato, e neste caso os nosos intereses diverxen lixeiramente. O cliente observa o proxecto estrictamente dentro do orzamento e das especificacións técnicas. Pode ser difícil explicarlle os beneficios de varias prácticas de DevOps que non están incluídas nas especificacións técnicas. E se está interesado en lanzamentos rápidos con valor comercial engadido ou en construír unha canalización de automatización?
Por desgraza, cando se traballa cun custo preaprobado, este interese non sempre se atopa. Na nosa práctica, houbo un caso no que tivemos que recoller o desenvolvemento dun contratista sen escrúpulos e descoidado. Foi terrible: non había códigos fonte actualizados, o código base do mesmo sistema era diferente en diferentes instalacións, a documentación estaba parcialmente ausente e parcialmente de pésima calidade. Por suposto, o cliente non tiña control sobre o código fonte, a montaxe, as versións, etc.
Ata o momento, non todo o mundo sabe sobre DevOps, pero en canto falamos das súas vantaxes, sobre o aforro real de recursos, os ollos de todos os clientes iluminan. Polo tanto, o número de solicitudes que inclúen DevOps está aumentando co paso do tempo. Aquí, para falar facilmente o mesmo idioma cos clientes, necesitamos conectar rapidamente os problemas empresariais e as prácticas de DevOps que axuden a construír unha canalización de desenvolvemento adecuada.
Entón, temos un conxunto de problemas por unha banda, temos coñecementos, prácticas e ferramentas de DevOps por outra. Por que non compartir a experiencia con todos?
Creando un constructor DevOps
Agile ten o seu propio manifesto. ITIL ten a súa propia metodoloxía. DevOps ten menos sorte: aínda non adquiriu modelos nin estándares. Aínda que determinar a madurez das empresas a partir dunha avaliación do seu desenvolvemento e prácticas operativas.
Afortunadamente, a coñecida empresa Gartner en 2014 e analizou as prácticas clave de DevOps e as relacións entre elas. En base a isto, publiquei unha infografía:
Tomámolo como base para o noso . Cada unha das catro áreas ten un conxunto de ferramentas: recompilámolas nunha base de datos, identificamos as máis populares, identificamos puntos de integración e mecanismos de optimización axeitados. En total resultou 36 prácticas e 115 ferramentas, a cuarta parte dos cales son de código aberto ou software libre. A continuación, falaremos do conseguido en cada ámbito e, a modo de exemplo, de como se implantou no proxecto de creación de xestión documental técnica, co que iniciamos o post.
Os procesos
No famoso proxecto EDMS, o sistema de xestión da documentación técnica despregouse segundo o mesmo esquema en cada un dos 10 obxectos. A instalación inclúe 4 servidores: servidor de bases de datos, servidor de aplicacións, indexación de texto completo e xestión de contidos. Na instalación, operan dentro dun só nodo e sitúanse no centro de datos das instalacións. Todos os obxectos difiren lixeiramente na infraestrutura, pero isto non interfire coa interacción global.
Primeiro, segundo as prácticas de DevOps, automatizamos a infraestrutura localmente, despois levamos a entrega ao circuíto de proba e despois ao produto do cliente. Cada proceso foi elaborado paso a paso. A configuración do contorno está fixada no sistema de código fonte, tendo en conta que o kit de distribución está compilado para a actualización automática. En caso de cambios de configuración, os enxeñeiros simplemente precisan facer os cambios adecuados no sistema de control de versións e, a continuación, a actualización automática realizarase sen problemas.
Grazas a este enfoque, o proceso de proba simplificouse moito. Anteriormente, o proxecto tiña probadores que non facían máis que actualizar os stands manualmente. Agora só veñen, miran que todo funciona e fan cousas máis útiles. Cada actualización probárase automaticamente, desde o nivel superficial ata a automatización do escenario empresarial. Os resultados publícanse como informes separados en TestRail.
Cultura
A experimentación continua explícase mellor mediante o exemplo de deseño de probas. Probar un sistema que aínda non existe é un traballo creativo. Ao escribir un plan de proba, cómpre comprender como probar correctamente e que ramas seguir. E tamén atopar un equilibrio entre tempo e orzamento para determinar o número óptimo de cheques. É importante escoller exactamente as probas necesarias, pensar en como interactuará o usuario co sistema, ter en conta o ambiente e os posibles factores externos. É imposible prescindir da experimentación continua.
Agora sobre a cultura da interacción. Anteriormente, había dous lados opostos: enxeñeiros e desenvolvedores. Os desenvolvedores dixeron: "Non nos importa como se poña en marcha. Sodes enxeñeiros, sodes intelixentes, asegúrate de que funcione sen fallos". Os enxeñeiros responderon: "Vos desenvolvedores son demasiado descoidados. Teñamos máis coidado e reproduciremos os teus lanzamentos con menos frecuencia. Porque cada vez que nos dás un código con fugas, non nos queda claro como interactuar".. Este é un problema de interacción cultural que se estrutura de forma diferente desde a perspectiva de DevOps. Aquí, tanto enxeñeiros como programadores forman parte dun único equipo que se centra en cambiar constantemente, pero ao mesmo tempo en software fiable.
Dentro do mesmo equipo, os especialistas están decididos a axudarse mutuamente. Como era antes? Por exemplo, estaban a prepararse unhas grosas instrucións de despregamento, dunhas páxinas 50. O enxeñeiro leuna, non entendeu algo, maldixo e pediu ao desarrollador ás tres da mañá que comentase. O desenvolvedor comentou e tamén maldiciu - ao final, ninguén estaba feliz. Ademais, naturalmente, houbo algúns erros, porque non pode lembrar todo nas instrucións. E agora o enxeñeiro, xunto co desenvolvedor, está a escribir un guión para o despregue automatizado da infraestrutura de software de aplicación. E falan practicamente no mesmo idioma.
Persoas
O tamaño do equipo está determinado polo alcance da actualización. O equipo é contratado durante a formación da entrega e inclúe os interesados do equipo xeral do proxecto. Despois escríbese un plan de actualización cos responsables de cada etapa, e o equipo informa a medida que avanza. Todos os membros do equipo son intercambiables. Como parte do equipo, tamén temos un programador de copia de seguridade, pero case nunca se ten que conectar.
Tecnoloxía
No diagrama tecnolóxico, destacan algúns puntos, pero debaixo deles hai unha morea de tecnoloxías: podes publicar un libro enteiro coas súas descricións. Así que destacaremos os máis interesantes.
A infraestrutura como código
Agora, probablemente, este concepto non sorprenderá a ninguén, pero antes as descricións das infraestruturas deixaban moito que desexar. , os ambientes de proba eran únicos, eran apreciados e apreciados, partículas de po foron expulsadas deles.
Hoxe en día ninguén ten medo de experimentar. Hai imaxes básicas de máquinas virtuais, hai escenarios preparados para despregar contornas. Todos os modelos e scripts gárdanse nun sistema de control de versións e actualízanse rapidamente. Anteriormente, cando era necesario entregar un paquete a un stand, apareceu unha brecha de configuración. Agora só tes que engadir unha liña ao código fonte.
Ademais dos scripts e canalizacións de infraestrutura, tamén se utiliza o enfoque Documentación como código para a documentación. Grazas a isto, é fácil conectar novas persoas ao proxecto, introducilas no sistema en función das funcións descritas, por exemplo, no plan de probas e tamén reutilizar casos de proba.
Entrega e seguimento continuo
sobre DevOps, falamos de como seleccionamos ferramentas para implementar a entrega e o seguimento continuos. Moitas veces non hai necesidade de reescribir nada: abonda con usar scripts escritos previamente, construír correctamente a integración entre compoñentes e crear unha consola de xestión común. E todos os procesos pódense iniciar usando un botón ou programa.
En inglés hai diferentes conceptos, Continuous Delivery e Continuous Deployment. Ambos pódense traducir como "entrega continua", pero de feito hai unha lixeira diferenza entre eles. No noso proxecto para o fluxo de documentos técnicos dunha empresa de enerxía distribuída, utilízase a entrega - cando a instalación para a produción ocorre baixo o mando. En Implementación, a instalación prodúcese automaticamente. A entrega continua neste proxecto converteuse en xeral parte central de DevOps.
En xeral, ao recoller certos parámetros, pode comprender claramente por que son útiles as prácticas de DevOps. E transmíteo á dirección, que lle encantan os números. O número total de lanzamentos, o tempo de execución das fases do script, a proporción de lanzamentos exitosos: todo isto afecta directamente ao momento favorito de todos para o mercado, é dicir, o tempo desde a comprobación do sistema de control de versións ata o lanzamento dunha versión nun ambiente de produción. Coa implementación das ferramentas necesarias, os enxeñeiros reciben por correo valiosos indicadores e o director do proxecto veos no panel. Deste xeito, pode avaliar inmediatamente os beneficios das novas ferramentas. E podes probalos na túa infraestrutura usando o deseñador DevOps.
Quen necesitará o noso ?
Non pretendamos: para comezar, fíxosenos útil. Como xa dixemos, cómpre falar o mesmo idioma co cliente e coa axuda do deseñador de DevOps podemos esbozar rapidamente a base para tal conversación. Os especialistas en empresas poderán avaliar por si mesmos o que necesitan e así desenvolverse máis rápido. Tentamos que o deseñador fose o máis detallado posible, engadindo un montón de descricións para que calquera usuario entenda o que está a escoller.
O formato do deseñador permítelle ter en conta os desenvolvementos existentes da empresa en procesos de construción e automatización. Non hai necesidade de derrubar todo e reconstruílo se só pode escoller solucións que se integren ben cos procesos existentes e que simplemente poidan cubrir as lagoas.
Quizais o teu desenvolvemento xa pasou a un nivel superior e a nosa ferramenta parecerá demasiado "de capitán". Pero parécenos útil para nós mesmos e esperamos que sexa útil para algúns dos lectores. Lembrámosche ao deseñador: se hai algo, recibe o diagrama inmediatamente despois de introducir os datos iniciais. Agradeceremos os teus comentarios e engadidos.
Fonte: www.habr.com