Jenkins Pipeline e DevOps: como conectar o desenvolvimento à entrega de software

Sysadmin há 12 anos e especialista em Zabbix, Daniel Requena palestrou na “Edição Especial Meetup DevOps SP patrocinada pela CVC com conteúdo de Especialistas”, e o bate-papo foi centrado na importância de se criar uma pipeline a fim de “acelerar” a adoção DevOps nas empresas.

“O objetivo de uma pipeline é automatizar o processo de entrega de software em produção de forma rápida, ao mesmo tempo garantindo sua estabilidade, qualidade e resiliência”, define Requena, que enxerga a pipeline como um ponto convergente de tudo o que acontece em um processo DevOps.

Mas, como uma pipeline se conecta com a abordagem DevOps? Consideremos os 4 pilares básicos:

• C – cultura
• A – automação
• M – métricas
• S – compartilhamento (sharing)

Basicamente, a cultura DevOps visa quebrar barreiras entre os times, ao passo que a pipeline une todos os mundos: infra, desenvolvimento, automação – porque todas as equipes querem entregar com qualidade – e métricas, porque seria possível coletar quantos rollouts foram feitos, por exemplo, além de muitos outros dados; e engloba também o compartilhamento, porque nunca será um trabalho de uma única equipe. O DevOps é multidisciplinar por si só.

Na visão de Requena, como é desenvolvedor que cria a aplicação para o cliente, é também quem está mais próximo dele. E o resultado disso é o dev responder diretamente quando há problemas na aplicação. Porém, quando há uma integração entre Dev e Ops, o cliente está no meio e o cliente não precisa ligar para o help desk. Existe um senso maior de responsabilidade e entrega de produto como um todo. “O que não quer dizer que Ops vai virar Dev, ou Dev irá virar Ops, pelo menos não por enquanto”, brinca Requena. “Mas não é essa a ideia do DevOps”, lembra ele.

Porque escolher o Jenkins?

Qualquer iniciativa para automatizar é bem vinda, portanto o ideal não é se apegar a ferramentas, mas sim escolher a que melhor irá entregar o serviço.

No nosso caso, escolhemos o Jenkins por algumas razões peculiares:

• – É o mais antigo no mercado, portanto o mais utilizado
• – É orientado a plugins (extensível)
• – Muito flexível
• – Farta documentação e material (livros, cursos etc)
• – Oferece versão com suporte (a quem possa interessar)

No vídeo com a íntegra da palestra de Daniel Requena você assistirá uma demo com os dois casos de uso descritos abaixo:

Cenário 1

• – Desenvolvedor único no projeto
• – Tudo na master (sem branches)
• – Sem testes
• – Execução direta (CD) em Docker
• – Um job “Freestyle” vs Coded (Script)
• – Notificações

Cenário 2

• – Mais um dev no time
• – Gitflow mínimo (FB)
• – Testes unitários e de integração
• – Ambiente isolado para testes: se você fizer um push dentro da sua branch, a pipeline vai entender que ele veio de uma feature branch e não de uma master; a aplicação vai executar um container em paralelo com uma porta totalmente diferente e te mandar no slack para só para testar; o fluxo não é mais o mesmo, não é necessário testar na produção ou na máquina: você tem uma pipeline que identifica quem não commitou diretamente na master, e tem um comportamento diferente, portanto.
• – Notificações mais completas

Assista ao vídeo com a íntegra da palestra de Daniel Requena no Meetup DevOps SP:

Referências

https://gitlab.com/requena1/flask-app
https://gitlab.com/my_pipelines/flask-app
https://gitlab.com/my_pipelines/acctests
https://jenkins.io/doc/book/pipeline
https://opendevops.com.br

Gostou do conteúdo? Tem alguma dúvida? Entre em contato com nossos Especialistas Mandic Cloud, ficamos felizes em ajudá-lo.