Treinamento escrito de DevOps

Como projetar seu pipeline DevOps de entrega e implantação contínuas?

Em muitas organizações, provavelmente inclusive a sua, os desenvolvedores programam isoladamente em ramificações separadas. Embora essa forma de trabalhar pareça favorecer a produtividade individual, ela prejudica a produtividade da equipe.

Ramificações separadas dificultam a mesclagem do código de vários desenvolvedores. Integrar os trechos de código, fazê-los funcionar juntos e entregar funcionalidades e benefícios aos clientes costuma exigir a participação de vários desenvolvedores, retrabalho considerável e a resolução de conflitos que já deveriam ter sido resolvidos.

O desafio aumenta quando você deixa de integrar continuamente

Como mesclar código é trabalhoso e cansativo durante o desenvolvimento, a maioria das equipes só o faz antes de entregar a aplicação para testes de integração ou aceitação do usuário. Isso agrava o problema. A equipe de garantia da qualidade acaba sendo a única responsável pelo sucesso da integração e pela qualidade do código conjunto. Além de absurdo, isso ajuda a explicar por que os projetos atrasam, os déficits orçamentários disparam, o ânimo e a motivação das equipes caem, os objetivos e compromissos da organização deixam de ser cumpridos e empresas de todo o mundo desperdiçam cerca de 600 bilhões de dólares por ano em trabalho de TI não orçado nem planejado. É o custo do retrabalho e das soluções paliativas de TI.

Como o desenvolvimento baseado em trunk (ramificação principal) pode ajudar?

A solução é combinar o desenvolvimento baseado em trunk com integração contínua e automação de testes. O desenvolvimento baseado em trunk é um modelo de ramificação no controle de versão em que os desenvolvedores colaboram no código em uma única ramificação, chamada “trunk”. Eles evitam criar outras ramificações de longa duração.

O desenvolvimento baseado em trunk viabiliza a integração contínua e, por extensão, a entrega contínua. Quando os desenvolvedores enviam mudanças ao trunk várias vezes ao dia, fica fácil cumprir a exigência central da integração contínua: todos os integrantes da equipe devem enviar código ao trunk pelo menos uma vez a cada 24 horas. Assim, o código fica sempre pronto para liberação sob demanda, o que ajuda a tornar a entrega contínua possível.

A integração contínua permite entregar código em partes menores, prontas para implantação

Envios frequentes de código permitem desenvolver e entregar lotes pequenos, o que aumenta a qualidade e facilita a resolução de problemas e conflitos. A integração contínua com envios diários incentiva a equipe a criar trechos de código menores, úteis e prontos para implantar, preservando a integridade das estruturas de integração e entrega contínuas. As atualizações no repositório comum também servem de meio para alinhar o trabalho, tomar decisões e obter feedback rapidamente.

Sempre que alguém envia código, a estrutura de integração contínua executa testes automatizados para as funções que dependem do módulo alterado ou são afetadas por ele. Se algo parar de funcionar, o responsável pelo envio deve corrigi-lo com prioridade máxima. Nada é mais importante nesse momento para que o restante da equipe possa continuar integrando seu trabalho ao trunk. Até a correção ou reversão rápida do envio com erro, outros envios para esse módulo do trunk ficam bloqueados para proteger a estabilidade e a confiabilidade.

Se você discorda desse princípio de DevOps, responda: por que acrescentar mais código a um módulo que já tem erros?

Você pode ter motivos legítimos, mas procure evitar a dívida técnica e o acúmulo de soluções paliativas.

Commits sujeitos a validação acrescentam uma camada de proteção ao desenvolvimento baseado em trunk

Sua equipe DevOps também pode recorrer a commits sujeitos a validação, que aumentam a qualidade e acrescentam proteção ao trunk.

Sempre que um desenvolvedor tenta enviar código, a automação de testes é executada primeiro para validá-lo. O código só é incorporado formalmente ao trunk depois que passa pela validação.

Use ambientes semelhantes ao de produção em todas as etapas do fluxo de valor da engenharia de software

Outro desafio comum em organizações de TI são as inconsistências entre os ambientes de produção e de pré-produção, como desenvolvimento, integração e testes. Pode haver diferenças de configuração, versão e nível de correção dos sistemas operacionais, bancos de dados, ferramentas de terceiros e APIs. Versões diferentes do seu código também podem estar espalhadas por ambientes de produção e pré-produção. Até pequenas diferenças entre as versões da JVM podem determinar o sucesso da implantação em produção. Sem pleno controle dos ambientes e conhecimento do que contêm, não dá para saber o que vai sair deles.

Inclua o gerenciamento de ambientes no trabalho diário de desenvolvimento e entrega de software

Os sistemas de pré-produção devem replicar os sistemas de produção. Permita que a equipe crie ambientes de autosserviço sob demanda, de forma automatizada, para realizar o trabalho diário de engenharia de software com segurança em ambientes semelhantes ao de produção.

O fluxo de valor de TI oferece valor tanto com o código do software quanto com os ambientes em que ele roda. Os especialistas de desenvolvimento e operações precisam considerar dois elementos igualmente importantes:

1. Código para criar o software que oferece valor aos seus clientes internos e/ou externos.
2. Código para criar os ambientes de pré-produção e de produção que hospedam o software.

Use uma fonte única de referência (trunk) para controlar o software e os ambientes
(ou seja, adote infraestrutura como código (IaC))

Com DevOps, as tarefas de criação dos ambientes de pré-produção e produção passam a fazer parte do trunk, o que constitui a definição mais pura de infraestrutura como código (IaC). Especialistas de desenvolvimento e operações criam juntos a infraestrutura como código, substituindo a atuação isolada de equipes de operações que mal conhecem as particularidades do software a hospedar.

Para tratar o código do software e o dos ambientes com a mesma importância, use uma única fonte de referência, o trunk, para armazenar ambos.

Para criar todos os sistemas de pré-produção e de produção e o pipeline de implantação, inclusive suas estruturas de integração e entrega contínuas, armazene no controle de versão tanto o código do software quanto as configurações, os scripts e tudo o que for necessário para montar a cadeia de entrega de ponta a ponta. Se quiser alterar permanentemente uma configuração de um ambiente, faça a mudança nos scripts que o criam. Assim, quem criar um ambiente na próxima vez não precisará refazer o trabalho do zero.

A maior parte da documentação detalhada fica obsoleta rapidamente. Vale mais a pena manter atualizados os scripts de criação de ambientes. Sem ambientes de autosserviço sob demanda, a infraestrutura em nuvem continuará subutilizada como plataforma de hospedagem, e a iniciativa DevOps será mais uma tentativa subutilizada de melhorar processos. Você deve conseguir criar ambientes completos de produção e pré-produção a partir do controle de versão. Com DevOps, é mais fácil e rápido recriar ambientes do que corrigi-los. Mudanças manuais nos ambientes deixam de ser permitidas. Use somente código e configuração para recriar, configurar e iniciar os ambientes.

Você tem uma nova Definição de Pronto (DoD)

Com a estrutura de entrega contínua e o pipeline de implantação em funcionamento, você precisa repensar sua “Definição de Pronto (DoD)”.

Uma tarefa deve ser classificada como “Pronta” quando as funcionalidades e os benefícios que ela oferece ao cliente forem:

• criados a partir do trunk automaticamente ou com um clique,
• testados em ambientes semelhantes ao de produção com testes automatizados,
• demonstrados em ambientes semelhantes ao de produção,
• preparados para implantação ou, melhor ainda, já implantados em produção, novamente de forma automática ou com um clique.

CONCLUSÃO

Com DevOps, a integração do código faz parte do trabalho diário e deixa de ficar para o fim dos projetos. Desenvolvedores, equipes de operações e especialistas em segurança da informação ensaiam repetidamente a implantação do próprio trabalho ao longo do ciclo de vida da engenharia de software. Isso aumenta a probabilidade de implantações tranquilas em produção.

Ao adotar a integração contínua, você também obtém maior volume de entregas para o negócio, melhor estabilidade do software e dos ambientes, mais satisfação no trabalho e melhor qualidade de serviço para clientes internos e externos.