Maturidade DevOps – Gestão de Builds e Integração Contínua

Este é o segundo post da série sobre maturidade em práticas DevOps. E aqui vamos discutir a maturidade na gestão de builds e integração contínua, prática nuclear dentro do mundo DevOps.

Antes de discutirmos a maturidade, é necessário esclarecer o que é um build. Na prática DevOps, um build é  um código executável gerado a partir de  instruções automatizadas e precisas de compilação a partir do código fonte e que atenda a um critério mínimo de testes.

Observe que esta definição tem duas implicações práticas:

  1. O código executável precisa ser gerado a partir de um arquivo chamado de definição de build para que possa ser compilado em qualquer ambiente. Isso evita a síndrome do desenvolvedor lambão que diz para você – “Na minha máquina compila”.
  2. O código executável deve passar com sucesso por uma suíte de testes automatizados para garantir sua estabilidade mínima (chamados de smoke tests). E isso evita a segunda síndrome do seu colega de trabalho, o desenvolvedor lambão, que diz para você – “Na minha máquina funciona”.

Com essa definição posta, podemos definir a nossa escala de maturidade.

  1. Maturidade 1 – Inicial – Aqui não existe uma cultura de builds. A compilação está acoplado às IDES como o Eclipse ou Visual Studio e é totalmente dependente destes ambientes. É comum que códigos compilem ou rodem em máquinas específicas apenas. Neste estágio também não observamos uma suíte de automação de testes que buscam garantir a qualidade do build.
  2. Maturidade 2 – Consciente –  Aqui a cultura de builds começa a ser instalada. Ferramentas como o Make, Maven, Gradle, Rake, Nuget e MSBuild começam a ser utilizadas pelo time para eliminar dependências de máquina na compilação. Isso permite que o código seja compilado com facilidade em qualquer máquina. Neste nível o time também introduz um suíte mínima de testes de fumaça (smoke tests) para garantir a estabilidade do build.
  3. Maturidade 3 – Gerenciado – Aqui os builds começam a ser executados em intervalos regulares em ambientes dedicados (ambientes de integração). Ferramentas como o Jenkins, GitLab, IBM Racional Team Concert, Ansible, Microsoft TFS ou Microsoft VSTS entram em cena para baixar do repositório os códigos fontes, compilar e testar os builds. Falhas na geração dos builds geram defeitos automatizados para o time de desenvolvimento. Neste nível também observamos uma maior cobertura  das suítes de testes (desejável maior que 20% do código fonte) e verificação automatizada das métricas de qualidade de código.
  4. Maturidade 4 – Avançado – Aqui temos um incremento na frequência de execução do build. Os builds começam a ser executados várias vezes por dia e operam até mesmo em ambientes paralelos com objetivos distintos (ex. Ambiente de build para testes de performance e ambiente de Build para testes funcionais). A cobertura do código fonte é agora expressiva e normalmente passa de 50% do código fonte e inclui testes funcionais e outros tipos de teste como performance, usabilidade ou segurança.
  5. Maturidade 5 – Melhoria Contínua – Aqui o time está tão avançado que ele começa a experimentar a prática da integração contínua (continuous integration), que formalmente definida é o processo de geração de builds disparado por modificações no código fonte. Em outros times, existem também políticas automatizadas que impedem o commit de código fonte que provoque quebra nos builds (padrão Gated Commit).

Podemos entender esta escala de maturidade a partir de dois fatores: frequência de execução e número de processos de qualidade executados. Um time com baixa maturidade não executa builds com frequência e não possui processos automatizados de qualidade que garantam o build gerado. Já um time de alta maturidade faz isso várias vezes por dia e cobre muitos processos técnicos tais como: testes de unidade, testes de tela, testes de integração, testes de segurança, testes de usabilidade, testes de performance, verificação da qualidade do código e até mesmo conformidade arquitetural a padrões pré-estabelecidos.

Naturalmente, este é um assunto denso e requer disciplina e tempo para ser implementado. Mas os resultados são notáveis e pagam, com juros, o esforço investido.

Recursos de Aprendizado

Se você deseja avançar a maturidade do seu time nesta importante prática, deixo aqui um conjunto importante de livros que são hoje referência para desenvolvedores profissionais. Os dois primeiros são específicos sobre a prática de Gestão de Builds, Integração Contínua e assuntos correlatos como a Entrega Contínua (Continuous Delivery). Temos aqui também dois livros sobre ferramentas populares – Jenkins e Microsoft VSTS. E finalmente dois livros sobre DevOps, sendo que o último é escrito na forma de uma história, o que torna a leitura bastante agradável.

51o9tzpyaul     41db4qikfil-_sx348_bo1204203200_
51ufxhdzvfl     41x0usghmnl-_sy346_

51mcvngdt6l   5170sr05qal


E você, ainda convive com desenvolvedores lambões? Ou já começou a aumentar a maturidade de gestão de builds no seu ambiente. Compartilhe aqui a sua experiência com esta prática.

 

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

w

Conectando a %s