Certa vez, fornecemos um sistema de gerenciamento eletrônico de documentos para um cliente em uma instalação. E então para outro objeto. E mais um. E no quarto e no quinto. Ficamos tão empolgados que chegamos a 10 objetos distribuídos. O resultado foi poderoso... especialmente quando entregamos as mudanças. Como parte da entrega ao circuito de produção, 5 cenários do sistema de testes exigiram, em última análise, 10 horas e 6 a 7 funcionários. Tais custos obrigaram-nos a fazer entregas tão raramente quanto possível. Depois de três anos de operação, não aguentamos mais e decidimos apimentar o projeto com uma pitada de DevOps.
Agora todos os testes acontecem em 3 horas e participam 3 pessoas: um engenheiro e dois testadores. As melhorias são claramente expressas em números e levam a uma redução do tão querido TTM. Em nossa experiência, há muito mais clientes que podem se beneficiar do DevOps do que aqueles que sequer sabem disso. Portanto, para aproximar o DevOps das pessoas, desenvolvemos um construtor simples, do qual falaremos com mais detalhes neste post.
Agora vamos contar com mais detalhes. Uma empresa de energia está a implementar um sistema de gestão de documentos técnicos em 10 grandes instalações. Não é fácil navegar em projetos desta escala sem DevOps, porque uma grande parte do trabalho manual atrasa muito o trabalho e também reduz a qualidade – todo trabalho manual está repleto de erros. Por outro lado, existem projetos onde existe apenas uma instalação, mas tudo precisa funcionar de forma automática, constante e sem falhas – por exemplo, os mesmos sistemas de fluxo de documentos em grandes organizações monolíticas. Caso contrário, alguém fará as configurações manualmente, esquecerá as instruções de implantação - e como resultado, na produção as configurações serão perdidas e tudo entrará em colapso.
Normalmente trabalhamos com o cliente através de um contrato e neste caso os nossos interesses divergem ligeiramente. O cliente analisa o projeto estritamente dentro do orçamento e especificações técnicas. Pode ser difícil explicar-lhe os benefícios de diversas práticas DevOps que não estão incluídas nas especificações técnicas. E se ele estiver interessado em lançamentos rápidos com valor comercial agregado ou em construir um pipeline de automação?
Infelizmente, quando se trabalha com um custo pré-aprovado, nem sempre esse interesse é encontrado. Em nossa prática, houve um caso em que tivemos que contratar o desenvolvimento de um empreiteiro sem escrúpulos e descuidado. Foi terrível: não havia códigos-fonte atualizados, a base de código do mesmo sistema era diferente em instalações diferentes, a documentação estava parcialmente ausente e parcialmente de péssima qualidade. É claro que o cliente não tinha controle sobre o código-fonte, montagem, lançamentos, etc.
Até o momento nem todo mundo conhece o DevOps, mas assim que falamos das suas vantagens, da real economia de recursos, os olhos de todos os clientes se iluminam. Portanto, o número de solicitações que incluem DevOps está aumentando com o tempo. Aqui, para falar facilmente a mesma língua com os clientes, precisamos conectar rapidamente os problemas de negócios e as práticas de DevOps que ajudarão a construir um pipeline de desenvolvimento adequado.
Então, temos um conjunto de problemas por um lado, temos conhecimentos, práticas e ferramentas DevOps por outro. Por que não compartilhar a experiência com todos?
Criando um construtor DevOps
Agile tem seu próprio manifesto. ITIL possui metodologia própria. O DevOps tem menos sorte - ainda não adquiriu modelos e padrões. Embora determinar a maturidade das empresas com base na avaliação do seu desenvolvimento e práticas operacionais.
Felizmente, a conhecida empresa Gartner em 2014 e analisou as principais práticas de DevOps e as relações entre elas. Com base nisso, lancei um infográfico:
Tomamos isso como base para o nosso . Cada uma das quatro áreas possui um conjunto de ferramentas - reunimos em um banco de dados, identificamos as mais populares, identificamos pontos de integração e mecanismos de otimização adequados. No total acabou 36 práticas e 115 ferramentas, um quarto dos quais são de código aberto ou software livre. A seguir falaremos sobre o que conquistamos em cada área e, a título de exemplo, como isso foi implementado no projeto de criação de gestão técnica de documentos, com o qual iniciamos o post.
Процессы
No notório projeto EDMS, o sistema de gerenciamento de documentação técnica foi implantado de acordo com o mesmo esquema em cada uma das 10 instalações. A instalação inclui 4 servidores: servidor de banco de dados, servidor de aplicativos, indexação de texto completo e gerenciamento de conteúdo. Na instalação, eles operam dentro de um único nó e ficam localizados no data center das instalações. Todos os objetos diferem ligeiramente em infraestrutura, mas isso não interfere na interação global.
Primeiro, de acordo com as práticas de DevOps, automatizamos a infraestrutura localmente, depois levamos a entrega para o circuito de testes e depois para o produto do cliente. Cada processo foi elaborado passo a passo. As configurações do ambiente são fixadas no sistema de código-fonte, levando em consideração qual kit de distribuição é compilado para atualização automática. Em caso de alterações na configuração, os engenheiros só precisam fazer as alterações apropriadas no sistema de controle de versão - e então a atualização automática ocorrerá sem problemas.
Graças a esta abordagem, o processo de teste foi bastante simplificado. Anteriormente, o projeto contava com testadores que não faziam nada além de atualizar manualmente os estandes. Agora eles só vêm, vêem se tudo está funcionando e fazem coisas mais úteis. Cada atualização é testada automaticamente – desde o nível superficial até a automação do cenário de negócios. Os resultados são publicados como relatórios separados no TestRail.
Cultura
A experimentação contínua é melhor explicada através do exemplo de design de teste. Testar um sistema que ainda não existe é um trabalho criativo. Ao escrever um plano de teste, você precisa entender como testar corretamente e quais ramificações seguir. E também encontre um equilíbrio entre tempo e orçamento para determinar o número ideal de verificações. É importante escolher exatamente os testes necessários, pensar em como o usuário irá interagir com o sistema, levar em consideração o ambiente e possíveis fatores externos. É impossível prescindir da experimentação contínua.
Agora sobre a cultura da interação. Anteriormente, havia dois lados opostos - engenheiros e desenvolvedores. Os desenvolvedores disseram: “Não nos importamos como será lançado. Vocês são engenheiros, são inteligentes, certifiquem-se de que tudo funcione sem falhas". Os engenheiros responderam: “Vocês, desenvolvedores, são muito descuidados. Vamos ter mais cuidado e tocaremos seus lançamentos com menos frequência. Porque toda vez que você nos fornece um código vazado, não fica claro para nós como interagir.”. Esta é uma questão de interação cultural estruturada de forma diferente da perspectiva do DevOps. Aqui, engenheiros e desenvolvedores fazem parte de uma única equipe focada em software em constante mudança, mas ao mesmo tempo confiável.
Dentro da mesma equipe, os especialistas estão determinados a ajudar uns aos outros. Como era antes? Por exemplo, estavam sendo preparadas algumas instruções de implantação grossas, com cerca de 50 páginas, o engenheiro leu, não entendeu alguma coisa, xingou e pediu ao desenvolvedor às três da manhã para comentar. O desenvolvedor comentou e também xingou – no final, ninguém ficou feliz. Além disso, naturalmente, houve alguns erros, porque você não consegue lembrar de tudo nas instruções. E agora o engenheiro, junto com o desenvolvedor, está escrevendo um script para a implantação automatizada da infraestrutura de software aplicativo. E eles falam praticamente na mesma língua.
Pessoas
O tamanho da equipe é determinado pelo escopo da atualização. A equipe é recrutada durante a formação da entrega, inclui os interessados da equipe geral do projeto. Em seguida, um plano de atualização é escrito com os responsáveis por cada etapa, e a equipe reporta à medida que avança. Todos os membros da equipe são intercambiáveis. Como parte da equipe, também temos um desenvolvedor reserva, mas ele quase nunca precisa se conectar.
Tecnologia
No diagrama de tecnologia, alguns pontos são destacados, mas abaixo deles há um monte de tecnologias - você poderia publicar um livro inteiro com suas descrições. Então vamos destacar o mais interessante.
Infraestrutura como código
Agora, provavelmente, este conceito não surpreenderá ninguém, mas anteriormente as descrições das infra-estruturas deixavam muito a desejar. , os ambientes de teste eram únicos, eram apreciados e apreciados, partículas de poeira eram expelidas deles.
Hoje em dia ninguém tem medo de experimentar. Existem imagens básicas de máquinas virtuais, existem cenários prontos para implantação de ambientes. Todos os modelos e scripts são armazenados em um sistema de controle de versão e atualizados imediatamente. Anteriormente, quando era necessário entregar uma embalagem em um estande, aparecia uma lacuna de configuração. Agora você só precisa adicionar uma linha ao código-fonte.
Além de scripts e pipelines de infraestrutura, a abordagem Documentação como Código também é usada para documentação. Graças a isso, é fácil conectar novas pessoas ao projeto, apresentá-las ao sistema com base nas funções descritas, por exemplo, no plano de testes, e também reaproveitar casos de testes.
Entrega e monitoramento contínuos
sobre DevOps, falamos sobre como selecionamos ferramentas para implementação de entrega e monitoramento contínuos. Muitas vezes não há necessidade de reescrever nada - basta usar scripts previamente escritos, construir corretamente a integração entre os componentes e criar um console de gerenciamento comum. E todos os processos podem ser iniciados usando um botão ou agendamento.
Em inglês existem diferentes conceitos, Continuous Delivery e Continuous Deployment. Ambos podem ser traduzidos como “entrega contínua”, mas na verdade existe uma pequena diferença entre eles. Em nosso projeto de fluxo de documentos técnicos de uma empresa de energia distribuída, utiliza-se sim o Delivery - quando a instalação para produção ocorre sob comando. Na implantação, a instalação ocorre automaticamente. A Entrega Contínua neste projeto geralmente se tornou parte central do DevOps.
Em geral, ao coletar determinados parâmetros, você pode entender claramente por que as práticas de DevOps são úteis. E transmita isso à gestão, que realmente adora números. O número total de lançamentos, o tempo de execução das etapas do script, a parcela de lançamentos bem-sucedidos - tudo isso afeta diretamente o tempo de lançamento favorito de todos, ou seja, o tempo desde o commit no sistema de controle de versão até o lançamento de uma versão em um ambiente de produção. Com a implementação das ferramentas necessárias, os engenheiros recebem indicadores valiosos por correio, e o gerente do projeto os vê no painel. Desta forma você pode avaliar imediatamente os benefícios das novas ferramentas. E você pode experimentá-los em sua infraestrutura usando o designer DevOps.
Quem vai precisar do nosso ?
Não vamos fingir: para começar, ele se tornou útil para nós. Como já falamos, é preciso falar a mesma língua com o cliente, e com a ajuda do designer DevOps podemos esboçar rapidamente a base para tal conversa. Os especialistas em negócios poderão avaliar por si próprios o que precisam e, assim, desenvolver-se mais rapidamente. Tentamos deixar o designer o mais detalhado possível, adicionando um monte de descrições para que qualquer usuário entenda o que está escolhendo.
O formato do projetista permite levar em consideração os desenvolvimentos existentes na empresa em processos construtivos e automação. Não há necessidade de demolir e reconstruir tudo se você puder escolher apenas soluções que se integrem bem aos processos existentes e que possam simplesmente preencher as lacunas.
Talvez o seu desenvolvimento já tenha passado para um nível superior e nossa ferramenta pareça muito “capitã”. Mas achamos que é útil para nós mesmos e esperamos que seja útil para alguns leitores. Nós lembramos você para o designer - se houver, você receberá o diagrama imediatamente após inserir os dados iniciais. Ficaremos gratos por seus comentários e acréscimos.
Fonte: habr.com