Imagine uma situação fantástica - o diretor da empresa decide implementar o DevOps. Ele mesmo, sem pressão de técnicos. Sem um exemplo convincente de concorrentes. A própria gerência reconheceu que é impossível melhorar a qualidade do produto, previsibilidade, transparência e repetibilidade dos processos de negócios no desenvolvimento e implementação de software sem as ferramentas de DevOps.
Apresentado? Isso deu certo? Você passou no teste para obter a imaginação mais rica!
De fato, é claro, não é assim. Na maioria das vezes, o gerenciamento não depende de nosso material de TI. Portanto, você tem que convencer. Mas como
Quando é apresentado um argumento para aumentar a cultura de comunicação entre programadores e administradores de sistema, é fácil se deparar com um contra-argumento: você não está civilizado agora ou o quê? Ou eles podem até lembrá-lo dos custos que a empresa já incorreu há um ou dois anos, quando você se mudou para o Agile. Existe um recurso em TI todos os anos que pode avançar nos processos de maneira revolucionária?
Quanto à melhoria da qualidade do produto, você também pode gaguejar. Mas tenha cuidado. Uma vez que a tarefa de programar sem erros ainda não foi cancelada. Sim, não há bugs, mas é por isso que a empresa tem um "departamento inteiro de testadores", certo?
A previsibilidade dos processos é geralmente um fator subjetivo, bastante difícil de justificar e evitar piadas sobre Wang e Nostradamus.
Além disso, se estivermos falando de uma empresa típica, nessa empresa, provavelmente, já existe uma equipe de TI estabelecida. E essa equipe no antigo ritmo habitual (exceto o Agile) trabalha em conjunto há muitos anos e dificilmente queima com o desejo (de novo) de mudar alguma coisa. Tudo combina com todos, exceto, é claro, a liderança. Que vê que em seus softwares quaisquer erros são constantemente transmitidos, os termos do lançamento de novas versões são alterados.
Obviamente, mais uma opção pode ser assumida quando uma pessoa chega à empresa com experiência em DevOps, representando claramente qual é o problema e como ele deve ser resolvido. E quem é capaz de transmitir sua opinião à liderança. No entanto, não esperemos um tio milagroso.
E muitos quebram isso. Eles começam a dizer que ninguém os apóia, que é impossível implementar qualquer coisa nesse pântano e depois simplesmente ir para outra empresa, onde o ciclo se repete.
Acontece um círculo vicioso? Não, apenas gradualmente chegamos à conclusão de que, com um negócio, você precisa falar apenas no idioma que ele entende - no idioma do dinheiro. Para fazer isso, obtemos o principal trunfo das pernas largas da manga - a redução do tempo de colocação no mercado. Precisamos mostrar que, graças ao DevOps, novas versões do produto serão lançadas como hotcakes. E vamos deixar o restante dos benefícios acima com a implementação do DevOps para a apresentação final, que criaremos para o diretor, quando tudo der certo. Muitos dirão que isso é óbvio demais. Não!
Precisamos de algo que nos leve um tempo e recursos mínimos (afinal, ninguém permitirá anular meses-homem para a implementação de um determinado DevOps e não comprará urgentemente novos servidores para nós), mas ao mesmo tempo fornecerá um resultado muito tangível (na verdade, reduzirá o Tempo para -Market).
Primeiro, você precisa encontrar um gargalo, mas ele é sempre um (o primeiro passo na teoria das restrições de Goldratt). Após a implementação bem-sucedida do Agile (e tudo isso faz sentido somente após a implementação do Agile), em termos de desenvolvimento de software, eles ainda precisam testar manualmente. Mesmo com um pool à mão livre, o teste de regressão pode levar de duas a três semanas. E pela maneira como os testadores “amam” realizar testes de regressão, eu sei tudo.
Portanto, determinamos que o teste é o gargalo. Então você precisa começar com sua automação. Muitos vão notar: é mais fácil falar do que fazer. Milhões de linhas de código já foram escritas, e é bom que os programadores cubram pelo menos algo com testes de unidade. De fato, nem tudo é tão assustador quanto parece. A experiência mostra que 80% do resultado bem-sucedido na forma de uma grave diminuição no tempo de colocação no mercado é alcançado por 20% dos esforços. Isso é o quanto custa a automação de testes no nosso caso.
Absolutamente de acordo com a lei de Pareto, sim.
E o mais importante, você pode começar a testar a automação antes que o gerenciamento aceite alocar recursos para a implementação das partes restantes do DevOps. Um pequeno projeto piloto que pode ser realizado sozinho em uma a duas semanas.
Mas, ao mesmo tempo, essa situação nos dá a chance de obter uma vitória espetacular e, mais importante, rápida. Depois disso, tendo uma atitude positiva e a bênção da liderança, você já pode pedir dinheiro e recursos.
Para começar, com certeza, seus programadores já estão usando algum tipo de software de servidor para compilações diárias. Pode ser TeamCity, Bamboo ou Jenkins - isso não importa. O principal é que já existe uma parte da automação e ela precisa ser usada; caso contrário, é fácil implantá-la em um dia.
Primeiro você precisa automatizar os testes de fumaça. Mas como entender o que automatizar? Sim, observe o que você quebrou regularmente ao publicar alterações nos últimos seis meses.
Em seguida, você precisa criar vários testes para verificar a operação dos principais processos de negócios. Como identificá-los? Perguntar a seus analistas / diretores / representantes comerciais que tipo de divisão o diretor irritado entra no escritório do programador e define as tarefas em voz alta.
Uma semana, no máximo, dois para criar esses testes. O resultado é um feedback muito rápido para erros globais.
E enquanto o projeto está em modo de prova de conceito, você não precisa preparar a mesma implantação automática do servidor para testes e outros arcos, mas faça tudo manualmente. Essa beleza pode ser feita com prazer junto com os administradores.
O que isso levará não é difícil de adivinhar. Os desenvolvedores verão imediatamente (e corrigirão) seus erros. Os testadores serão poupados da rotina de realizar testes longos e tediosos para regressão. Eles terão alguns dias para testar apenas as partes do código que foram sujeitas a edição. Sim exatamente. Caso contrário, volte ao início e converse novamente com analistas / diretores / representantes de negócios sobre processos críticos de negócios.
O gargalo devido ao qual os principais freios surgiram foi eliminado. Agora, tudo o que resta é liberar alguns novos lançamentos em um ambiente produtivo, remover as estatísticas do “era / era” e seguir esses números para o gerenciamento. Lucro!
Após uma vitória tão convincente, você já pode falar sobre a automação da implantação de stands (pelo menos para testes). Em seguida, solicite fundos para monitoramento e outras delícias do DevOps. Deve-se lembrar que os componentes restantes do sistema não terão mais um efeito impressionante para os negócios.
Exemplo de estúdio
No final do post, acho que seria apropriado dar um exemplo de um projeto concluído com êxito para a implementação do DevOps, implementado por nossa empresa.
Um grande varejista possui cerca de 20% dos negócios em uma loja online. Ao mesmo tempo, é necessário reagir muito rapidamente à situação do mercado e fazer as alterações necessárias no software. E frequentemente. E de alta qualidade. Qualquer batente no site pode afetar a conversão, os riscos são expressos em dinheiro real.
Para reduzir o tempo de atualização e melhorar a qualidade, foi criada uma plataforma especializada de autoteste, na qual as tarefas de rotina para testar alterações e regressão do site foram automatizadas. Além disso, foi construído o processo de interação do grupo de teste automatizado com as equipes de desenvolvimento. Isso permitiu que os desenvolvedores identificassem e corrigissem imediatamente os defeitos no sistema atualizado, sem esperar pelo teste de aceitação final.
Os representantes do varejista consideraram a experiência bem-sucedida e decidiram aplicá-la a outros produtos de software.
E outro pequeno exemplo, mas da prática de uma grande companhia de seguros. Antes da introdução da automação de teste, os lançamentos eram lançados a cada seis meses. Não porque a empresa o exigisse - simplesmente não funcionava com mais frequência. E o cliente só queria. Portanto, dois meses após o início da introdução das ferramentas de teste automático, a equipe de TI mudou para as iterações de duas semanas das versões lançadas.
Significativo o suficiente para começar a fazer isso, não é?
Sergey Stramnov, arquiteto de pré-venda do Jet Infosystems Software Solutions Center