De alguma forma, colocamos o cliente em um objeto, sistema de gerenciamento eletrônico de documentos. E depois para outro objeto. E mais um. E no quarto e quinto. Eles ficaram tão empolgados que chegaram a 10 objetos distribuídos. Poderoso aconteceu ... especialmente quando chegamos à entrega das mudanças. Como parte do fornecimento ao circuito produtivo para 5 cenários de sistema de teste, foram necessárias 10 horas e 6-7 funcionários. Tais custos nos forçaram a entregar o mínimo possível. Após três anos de operação, não conseguimos suportar e decidimos temperar o projeto com uma pitada de DevOps.
Agora, todos os testes passam em 3 horas e 3 pessoas participam: um engenheiro e dois testadores. As melhorias são claramente expressas em números e levam a uma redução no amado TTM. Em nossa experiência, há muito mais clientes que o DevOps pode ajudar do que aqueles que sabem disso. Portanto, para tornar o DevOps mais próximo das pessoas, desenvolvemos um construtor simples, sobre o qual falaremos mais detalhadamente neste post.
Agora vamos contar com mais detalhes. Em uma empresa de energia em 10 grandes instalações, um sistema técnico de gerenciamento de documentos está sendo implantado. Não é fácil aparecer em projetos dessa magnitude sem o DevOps, porque uma grande proporção do trabalho manual atrasa muito o trabalho e também reduz a qualidade - todo o trabalho manual está repleto de erros. Por outro lado, existem projetos em que a instalação é uma, mas é necessário que tudo funcione automaticamente, constantemente e sem falhas - por exemplo, os mesmos sistemas de gerenciamento de documentos em grandes organizações monolíticas. Caso contrário, alguém fará a configuração manualmente, esquecerá as instruções de implantação - e, como resultado, as configurações serão perdidas no produto e tudo falhará.
Normalmente, trabalhamos com o cliente através de um contrato, caso em que nossos interesses divergem um pouco. O cliente observa o projeto estritamente dentro do orçamento e da TK. Pode ser difícil explicar a ele os benefícios de várias práticas de DevOps que não fazem parte do TK. E se ele estiver interessado em lançamentos rápidos com valor agregado para os negócios, na construção de um pipeline de automação?
Infelizmente, ao trabalhar com valor pré-aprovado, nem sempre é possível encontrar esse interesse. Em nossa prática, houve um caso em que tivemos que retomar o desenvolvimento de um contratado inescrupuloso e impreciso. Foi um horror: não existem códigos-fonte reais, a base de códigos do mesmo sistema em instalações diferentes é diferente, a documentação estava parcialmente ausente, parcialmente de péssima qualidade. Obviamente, o cliente não tinha controle de origem, montagem, liberações, etc.
Até agora, nem todo mundo sabe sobre o DevOps, mas vale a pena falar sobre suas vantagens, sobre a economia real de recursos, os olhos se iluminam para todos os clientes. Portanto, há mais e mais solicitações envolvendo DevOps ao longo do tempo. Aqui, para falar facilmente o mesmo idioma com os clientes, precisamos conectar rapidamente problemas de negócios e práticas de DevOps, o que ajudará a criar um pipeline de desenvolvimento adequado.
Portanto, temos um conjunto de problemas, por um lado, e, por outro lado, existem conhecimentos, práticas e ferramentas de DevOps. Por que não compartilhar a experiência com todos?
Criar um construtor DevOps
O Agile tem seu próprio manifesto. O ITIL possui uma metodologia própria. O DevOps tem menos sorte - ainda não adquiriu modelos e padrões. Embora
alguns estejam tentando determinar o grau de maturidade das empresas com base em uma avaliação de seus métodos de desenvolvimento e operação.
Felizmente, a notória empresa Gartner em 2014
coletou e analisou as principais práticas de DevOps e os relacionamentos entre elas. Com base nisso, lancei o infográfico:
Tomamos como base do nosso
construtor . Em cada uma das quatro áreas, há um conjunto de ferramentas - nós as coletamos no banco de dados, identificamos os pontos de integração mais populares e identificados e mecanismos de otimização adequados. No total,
36 práticas e 115 ferramentas foram implementadas, um quarto das quais são de software livre ou aberto. A seguir, falaremos sobre o que fizemos em cada área e, por exemplo, como foi implementado no projeto para criar um fluxo de trabalho técnico a partir do qual iniciamos a publicação.
Os processos
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: um servidor de banco de dados, um servidor de aplicativos, indexação de texto completo e gerenciamento de conteúdo. Na instalação, eles trabalham em um único nó, estão localizados no data center nas instalações. Todos os objetos variam ligeiramente em infraestrutura, mas isso não interfere na interação global.
Primeiro, de acordo com as práticas de DevOps, automatizamos as infraestruturas localmente, depois trouxemos a entrega ao circuito de teste e, em seguida, à produtividade 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 que a distribuição é coletada para atualizações automáticas. No caso de alterações na configuração, os engenheiros precisam apenas fazer as alterações apropriadas no sistema de controle de versão - e a atualização automática será aprovada sem problemas.
Graças a essa abordagem, o processo de teste foi bastante simplificado. Anteriormente, havia testadores no projeto que apenas faziam a atualização manual dos estandes. Agora eles vêm, veem que tudo funcionou e estão envolvidos em coisas mais úteis. Cada atualização é testada automaticamente - desde o nível da superfície até a automação do cenário de negócios. Os resultados são apresentados como relatórios separados no TestRail.
Cultura
A experimentação contínua é melhor explicada pelo design do teste. Testar um sistema que ainda não existe é um trabalho criativo. Ao escrever um plano de teste, você precisa entender como testar corretamente, quais ramificações passar. 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, considerar como o usuário irá interagir com o sistema, levar em consideração o ambiente e possíveis fatores externos. Você não pode prescindir da experimentação contínua.
Agora sobre a cultura da interação. Costumava haver duas partes em guerra - engenheiros e desenvolvedores. Os desenvolvedores disseram:
"Não nos importamos como isso começa. Vocês são engenheiros, são inteligentes, fazem funcionar sem interrupção .
” Os engenheiros responderam:
“Vocês desenvolvedores são muito imprudentes. Sejamos mais cuidadosos, e lançaremos seus lançamentos com menos frequência. Porque toda vez que você nos coloca um código holey, a maneira como interagimos não é clara .
” Esse é um problema de interação cultural que, do ponto de vista do DevOps, está estruturado de maneira diferente. Aqui você tem engenheiros e desenvolvedores que fazem parte de uma única equipe que visa mudar constantemente, mas ao mesmo tempo um software confiável.
Na escala de uma equipe, especialistas estão prontos para ajudar um ao outro. Como foi antes? Por exemplo, algum tipo de instrução de implantação espessa estava sendo preparada, páginas 50. O engenheiro leu, não entendeu nada, xingou e pediu ao desenvolvedor que comentasse às três da manhã. O desenvolvedor comentou e também jurou - no final, ninguém ficou feliz. Além disso, naturalmente, houve alguns erros, porque você não se lembrará de tudo nas instruções. E agora o engenheiro, juntamente com o desenvolvedor, está escrevendo um script para implantação automatizada da infraestrutura de software de aplicativo. E eles falam um com o outro quase na mesma língua.
Pessoas
O tamanho da equipe é determinado pela extensão da atualização. A equipe é recrutada durante a formação do suprimento, incluindo aqueles que desejam da equipe geral do projeto. Em seguida, um plano de atualização é elaborado com responsabilidade por cada estágio, conforme a equipe executa, ele relata. Todos os membros da equipe são intercambiáveis. Como parte da equipe, também temos um desenvolvedor de segurança, mas ele quase nunca precisa se conectar.
Tecnologia
No esquema de tecnologia, alguns pontos são destacados, mas por baixo deles há um monte de tecnologias - com suas descrições, você pode lançar um livro inteiro. Então, vamos destacar o mais interessante.
Infraestrutura como código
Agora, provavelmente, você não surpreenderá ninguém com esse conceito, mas antes da descrição das infra-estruturas deixou muito a desejar.
Os engenheiros olhavam horrorizados as instruções , os ambientes de teste eram únicos, eles eram cuidados e valorizados, partículas de poeira eram sopradas deles.
Agora ninguém tem medo de experimentar. Existem imagens básicas de máquinas virtuais, há cenários prontos para implantação de ambientes. Todos os modelos e scripts são armazenados no sistema de controle de versão e são atualizados rapidamente. Anteriormente, quando era necessário entregar um pacote em um suporte, aparecia uma lacuna de configuração. Agora você só precisa adicionar uma linha no código fonte.
Além de cenários de infraestrutura e pipelines, a documentação como uma abordagem de código também é usada para documentação. Graças a isso, é fácil conectar novas pessoas ao projeto, apresentá-las ao sistema pelas funções descritas, por exemplo, no plano de teste e também reutilizar casos de teste.
Entrega e Monitoramento Contínuos
Em nosso último artigo sobre DevOps, falamos sobre como escolhemos ferramentas para implementar a entrega e o monitoramento contínuos. Frequentemente, não há necessidade de reescrever nada - basta usar scripts escritos anteriormente, criar corretamente a integração entre os componentes e criar um console de gerenciamento comum. E todos os processos podem ser iniciados com um único botão ou agendamento.
Existem conceitos diferentes em inglês, Entrega contínua e Implantação contínua. Ambos podem ser traduzidos como "entrega contínua", mas, de fato, há uma pequena diferença entre eles. Em nosso projeto para o gerenciamento de documentos técnicos de uma empresa de energia distribuída, o Delivery é usado, antes, quando a instalação para vendas é realizada sob comando. Na implantação, a instalação é automática. A entrega contínua nesse projeto geralmente se tornou uma
parte central do DevOps .
Em geral, coletando certos parâmetros, você pode entender claramente por que as práticas de DevOps são úteis. E transmitir isso à liderança, que gosta muito de números. O número total de lançamentos, o tempo de execução das etapas do script, a porcentagem de lançamentos bem-sucedidos - tudo isso afeta diretamente o tempo favorito de mercado de todos, ou seja, o tempo entre o comprometimento com o sistema de controle de versão e o lançamento da versão em um ambiente produtivo. Com a introdução das ferramentas necessárias, os engenheiros recebem indicadores valiosos por correio e o gerente de projetos os vê em um painel. Assim, você pode apreciar imediatamente os benefícios de novas ferramentas. E você pode experimentá-los em sua infraestrutura usando o construtor DevOps.
Não vamos trapacear: para começar, ele se tornou útil para nós. Como já dissemos, o cliente precisa falar o mesmo idioma e, com a ajuda do construtor do DevOps, podemos delinear rapidamente a base dessa conversa. Os profissionais de negócios poderão avaliar a si mesmos o que precisam e, assim, desenvolver-se mais rapidamente. Tentamos tornar o construtor o mais detalhado possível, adicionamos várias descrições para que qualquer usuário entenda o que ele escolhe.
O formato do designer permite que você leve em consideração a experiência existente da empresa em processos de construção e automação. Você não precisa quebrar tudo e reconstruir se puder escolher apenas soluções que se integram normalmente aos processos existentes que podem simplesmente preencher as lacunas.
Talvez o seu desenvolvimento já tenha passado para um nível superior e nossa ferramenta parecerá muito "do capitão". Mas achamos útil para nós mesmos e esperamos que seja útil para alguns dos leitores. Lembramos o
link para o construtor - se houver, você obtém o circuito imediatamente após inserir os dados de origem. Agradecemos o feedback e as adições.