Palestra: Desenvolvimento de builds automizados com Jenkins – Em Busca do build Perfeito!

No último dia 4 de abril estivemos no evento de comemoração dos 10 anos do GUMA-RS, apresentando uma palestra sobre Continuous Integration. Após a apresentação, fizemos um tutorial mostrando em funcionamento um pipeline do ciclo de desenvolvimento, desde o build até o deploy em produção, utilizando Jenkins. Desta forma levamos aos presentes algumas ideias do que pode ser feito em termos de automação e entrega contínua.

Abaixo segue os slides da apresentação. Os projetos que utilizamos estão no Github, aqui e aqui.

 

Anúncios

Automatizando tarefas repetitivas utilizando Jenkins

Pare para pensar. Em seu trabalho existem tarefas que se repetem com certa frequencia, e que você faz sempre a mesma coisa para resolvê-las? Você provavelmente gostaria de não fazer mais essas tarefas, assim teria tempo para fazer tarefas mais importantes que necessitam do seu raciocínio lógico, ou até mais tempo para o seu lazer, porque não?

A solução para este tipo de problema pode ser a automação dessas tarefas. Ao se criar scripts que automatizem o trabalho antes feito manualmente, vários benefícios são obtidos como abstração do funcionamento, já que qualquer desenvolvedor pode executar o script mesmo sem saber como ele funciona internamente, e qualidade, já que não são mais necessários passos manuais diminuindo a chance de erros.

E é neste ponto que entra o Jenkins. Jenkins é uma ferramenta de integração contínua que fornece uma interface amigável para criação de tarefas que podem ser executadas manualmente, através de um clique, ou ainda agendadas para rodar em determinados horários.

Vale ressaltar que o Jenkins somente executa os scripts criados, então o conhecimento em alguma linguagem de script ainda é necessário. O foco deste post fica somente sobre o Jenkins.

Instalação
Vá na página oficial do Jenkins e selecione o link para o Java Web Archive (.war). Você pode fazer o deploy do Jenkins em um servidor de aplicação normalmente, mas para fins didáticos, vou inicializar como uma aplicação standalone. Para fazer isso, basta navegar pelo prompt de comando até o diretório onde se encontra o arquivo que foi baixado, e executar o seguinte comando: java -jar jenkins.war. Abra seu navegador e digite o seguinte endereço: http://localhost:8080/. Se você fez tudo corretamente a página principal do Jenkins será exibida.

Builds
O exemplo que irei mostrar a seguir, é de um job (tarefa), que irá, a cada commit em um repositório do GitHub, realizar o build da aplicação, inclusive rodando seus testes unitários. Isso possibilita que os desenvolvedores mantenham seu código constantemente integrado com o resto do sistema, e fornece um rápido feedback quando erros ocorrem. Mais sobre Continuos Integration (Integração Contínua) você pode conferir aqui.

Como iremos utilizar o Github, é necessário instalar o plugin que fará a conexão com o repositório. Para instalar o plugin vá em Gerenciar Jenkins -> Gerenciar Plugins -> Disponíveis, selecione o GitHub Plugin, e clique em Download now and install after restart.

Agora que temos o plugin instalado, o próximo passo é criar o job no Jenkins. Clique em Novo(a) Job, defina um nome para o mesmo, e marque a opção Construir um projeto de software free-style.

jenkins1

Clique em Ok. Será exibida uma tela para configuração do job. Existem várias opções de configuração, mas vamos fazer um exemplo bem simples. Em Gerenciamento de Código Fonte marque a opção Git, e insira a url de seu repositório. Em Disparadores de Construção selecione a opção Construir periodicamente e insira os seguintes valores */5 * * * *. Isso determina que o Jenkins faça o build do projeto a cada 5 minutos. Clique em salvar, e o seu job estará pronto para ser executado.

Sem títuloAlém do exemplo

Este foi um exemplo bem básico, com o objetivo de demonstrar a instalação e funcionamento, e ainda despertar o interesse pela ferramenta. Muitas outras coisas podem ser automatizadas via Jenkins, como deploys de aplicações ou até compilações de livros, sua utilidade é muito vasta. Pesquise mais sobre o assunto, e começe a criar o hábito de automatizar suas tarefas que são repetitivas e acabam consumindo seu tempo todos os dias.

Continuous Delivery! Sua empresa está preparada?

Ainda depois de mais de 11 anos praticando agilidade, muitas são as equipes de desenvolvimento de software que sonham em realizar um deploy a partir de um simples click. O que geralmente ocorre é que as organizações e seus respectivos times/produtos muitas vezes não estão preparados para este grande passo. 

Para ilustrar e enriquecer este post, acompanhe algumas dicas e aprendizados adquiridos através de experiências e treinamentos como por exemplo com o autor do livro Continuous Delivery, @jezhumble.


O quão ágil é o seu time?

Hoje em dia não raros são os times de desenvolvimento de software que se consideram “ágeis”, ou que buscam nas praticas ágeis a base para seus ciclos de desenvolvimento. @Jezhumble costuma questionar o quão ágil um time de desenvolvimento é. E o mais importante, como chegar a uma métrica para mensurar tal informação. A reposta mais simples possível vem do mesmo @jezhumblee, onde ele sugere mensurar o quão rápido seu time consegue entregar software de qualidade a seus clientes. #ficaadica

Seu time está preparado para entregar software de forma contínua?

Ainda falando em desenvolvimento àgil de software, temos como premissa a entrega de software agregando valor ao negócio do cliente. Desta forma muitas equipes pecam na tentativa de estabelecer uma linha de entrega contínua a seus clientes, onde os motivos vão desde erros operacionais básicos das equipes até mesmo o despreparo por parte do cliente em relação ao modelo de entrega proposto.

Para evitar os pecados mencionados anteriormente, procure criar uma cultura de entrega continua. Faça com que a entrega de versões ou a simples entrega de uma nova funcionalidade faça parte do planejamento de cada equipe e não apenas após finalizado a codificação da mesma. Discuta estratégia de entregas. Discuta, reforce, defina o conceito de “PRONTO” com o seu time e lembre-se, tarefa pronta significa valor entregue ao cliente em produção.

Automação

Novamente parafraseando @jezhumble “… automação é tudo” ou talvez seria para tudo? O fato é que automação é um ponto chave para quem busca realizar entregas consistentes independentemente do tamanho do ciclo de desenvolvimento trabalhado.

Garanta através de “mecanismos de segurança” constantes validações sob a versão ainda em desenvolvimento, gerando feedback constante e garantindo que a linha de produção não pare, ou se caso venha parar que volte a produzir o quanto antes possível. Entre estes mecanismos estão a automação de testes validando a versão a cada commit realizado. Integrar continuamente a versão corrente evitado surpresas ao fechar versões para produção ou então rodar noturnamenta suites de regressões antecipando não conformidades geralmente identificadas apenas na validação de versões pré-produção.

Eliminar processos complexos e consequentemente dificeis de serem executados é um fator muito importante na automação de tarefas. Se uma tarefa é complexa para ser executada, talvez necessite ser executada com mais frequência buscando assim alternativas e soluções mais simples de serem executadas.

Não elimine a intervenção das pessoas no processo de entrega, pessoas são ótimas em heuristica.

“… se é demorado é porque é dificil, se é dificil é porque é manual, se é manual precisa ser automatizado”

 Continuous Deployment e Continuous Delivery

Os termos Continuous Deployment e Continuous Delivery podem nos gerar confusão. Pois bem vamos exemplificar o conceito de cadas um deles abaixo:

  • Continuous Deployment: É caracterizado pelo fechamento de builds de software funcionais.

Ex.: Realizar o fechamento de versão e realizar o deploy no ambiente de homologação a cada nova funcionalidade uma vez validada pelos testes. Note não estamos entregando software em produção. 

  • Continuous Delivery: Pode ser considerado o passo de simplesmente agregar valor ao negócio propriamente dito. Conforme o ambiente, baterias de validações podem fazer parte deste processo intermediado diretamente pelo pessoal de negócio, ou simplesmente em ambientes automatizados este mesmo time decide qual o melhor entregável deve ser promovido para produção clicando no botão “release”. http://goo.gl/QkaO 

Cultura DevOps 

Leve para dentro de seu time a cultura DevOps, fazendo o time de desenvolvimento sentir as dores atuais para realizar a liberação de uma nova versão. Fazer do time de operações uma extensão do time de desenvolvimento ou vice-versa.

Esta maior integração propicia ao desenvolvedor uma maior responsabilidade dentro do processo de liberação de novas versões. A prática de code refactoring não pode ser vista como ato de heroísmo e sim de responsabilidade e respeito para com o time. Um desenvolvedor deve garantir que após realizar uma refatoração em uma parte do sistema, tudo deve continuar funcionando conforme anteriormente.

Realize eventos para apresentar grandes mudanças no software, evitando assim também grandes surpresas e processos de rollbacks/fallbacks traumáticos. Mas esteja sempre preparado para executá-los da melhor forma possível.

Estude melhores práticas e formas de modo a facilitar o bom andamento do ciclo de desenvolvimento de seu time tais como:

  • Feature Toogles;
  • Feature Branching; 
  • Blue-Green Deployment;
  • Virtualização etc …

Pratique Chaos Monkey! Aprenda com suas falhas e a melhor forma de fazer isso é falhar frequentemete. Certifique-se de que sua infraestrutura pode ser recriada através do seu controle de versão, incluindo scripts de toda e qualquer espécie.