Busca avançada

CI/CD Além dos Conceitos

quinta-feira, 3 de janeiro de 2019 por Eduardo Spaki
CI/CD Além dos Conceitos

É fácil achar materiais de conceitos na Internet sobre o Continous Integration (CI) e o Continous Delivery (CD). Mas que tal conhecer alguns exemplos e ferramentas, bem como trazer isso um pouco mais próximo da realidade de desenvolvimento de software?

Recentemente, em uma consultoria para um cliente da Code21, tive a oportunidade de discutir e amadurecer bastante o processo de CI/CD dele. Se você precisar de alguma ajuda nesse processo, conte conosco!

E, como já explorei em outros textos, a historinha do programador de garagem (ou, nos dias de hoje, programador de quarto) que faz o App de um milhão de dólares, não acontece todo dia. Portanto, é importante cuidar bem do seu código fonte, saber trabalhar em equipe… e somente fazer o código do software não é o suficiente.

Muitas vezes precisamos controlar o ciclo de vida de nossa aplicação, e formar/trabalhar em squads, onde há papéis definidos, bem como ferramental de apoio.

E sobre CI/CD gostaria de falar de um papel em alta hoje em dia, o profissional de Devops.

Esse profissional, geralmente tem um background forte de infraestrutura. Conhece muito de redes de servidores, bem como é muito bom em scripting (conseguindo analisar e automatizar atividades em servidores usando scripts bash, powershell, etc).

Conforme o mundo da tecnologia foi evoluindo, saindo do mundo on-premisses para a nuvem, esse profissional ganhou muita habilidade nessas plataformas também.

Já ressaltei anteriormente, o mundo hoje demanda de muita tecnologia. Para pegar uma carona usamos um App, e mal nos damos conta que aquilo usa um GPS, que manda as coordenadas para um servidor, que dispara avisos para motoristas na região, que após o aceite a rota já é traçada, e ao final ainda é integrado ao nosso cartão de crédito que já fatura direto na nossa conta. Resumindo, o mundo é voraz por tecnologia, por software e inovação!

Com isso vem a necessidade de entregar muito mais rápido. Não podemos nos dar ao luxo de planejar um sistema muito bom e completo, mas só entregá-lo daqui 5 anos. Faz mais sentido, e é mais sustentável, pequenas entregas, em períodos curtos, que agregam novas funcionalidade, complementam e corrigem as já existentes (além disso, há a abordagem do MVP, que deixarei para uma próxima).

Para alcançar esse objetivo, o desenvolvedor de software foi aproximado de seus usuários. E o profissional de infra se aproximou do desenvolvedor, se tornando assim o DevOps.

Essa sinergia propicia melhor comunicação e entregas mais rápidas.

Lembro-me antigamente, que havia uma equipe responsável por desenvolver o software, outra (geralmente um ou mais profissionais seniors) para empacotar/gerar uma versão. Feito isso, o aplicativo compilado ficava a disposição de um profissional de infra, que dependendo da boa vontade colocava no ar a aplicação e “dava pau” (e aqui faz sentido “depender da boa vontade”, pois como ele não desenvolveu aquilo, não faz a mínima ideia do problema, mas a coisa estourou na mão/servidor dele… e não era a primeira vez). 

E começava a “jogação” de culpa, o profissional de infra falando que o servidor dele está ok, o desenvolvedor falando que quem montou a versão se esqueceu do código dele, quem montou a versão falando que pegou o código que estava lá (sem falar nos problemas de merge de código).

E lá se foi mais uma semana sem lançar versão de software pois a equipe está engessada sem saber o que fazer e onde está o problema. Me lembro ainda, que os devs pediam para o cara da infra para acessar o servidor, e o cara da infra dizia: está louco? acessar produção!?

Essa aproximação visa aprimorar a qualidade do código (através do CI), a compatibilidade de ambientes (homologação refletindo produção), a análise de logs de ambientes e bem como a entrega do mesmo código para todos os servidores de maneira igual (através do CD).

Primeiramente a comunicação entre dev e devops é mais curta e menos burocrática. Segundo que os dois unem forças para analisar logs e detectar problemas. Terceiro e particularmente considero uma das questões mais importantes: O fator humano é praticamente eliminado pela automação, evitando aquela famosa distração que levou ao “putz, esqueci de configurar isso naquele servidor”.

E CI/CD tem justamente haver com isso: automatizar!

Agora que já elucidei o Devops, vamos rever os conceitos.


CI

O Continous Integration propõe que, deve haver um repositório de código central e todos os desenvolvedores devem enviar seu código para lá. Obviamente que “central” aqui é subjetivo, mas em outra hora exploro mais os conceitos de “branch strategy”.

A ideia é que os desenvolvedores devem estar sempre colocando seus códigos ali continuamente em um curto período de tempo. Basicamente é: fez uma feature, já envia!

A cada novo envio que o repositório recebe, o código é checado, validado, compilado e testado. Tudo isso deve acontecer de forma automática, sem interferência humana, para que seja viável.

O resultado dessa análise deve gerar indicadores e relatórios que refletem a saúde do codigo/software. Assim, fica fácil saber se algum código está quebrando, bem como encontrar os erros e falhas para corrigir. E lembrando: corrigiu, enviou novamente!

Como isso é possível? Daqui a pouco vou abordar algumas ferramentas.


CD

O Continous Delivery é estabelecer uma forma de implantar automaticamente uma versão, de forma eficiente e quando necessária, no ambiente desejado. Essa versão será baseada no resultado do CI, assim há como garantir que uma versão contém determinados códigos, bem como se está testada e livre de problemas.

Aqui também entra um pouco de “branch strategy”, pois há quem prefira que o mesmo código/binário seja copiado entre os ambientes (ex: o binário de homologação, será copiado para produção). Já outros preferem que o código seja recompilado para os ambientes (ex: dado um determinado marco, como um commit de um determinado código, seja compilado e implantado em homologação, e quando for para a produção recompila novamente o código a partir desse marco). Mas como disse, isso é papo para outra hora.


Resumindo

De maneira bem simplista, fazer um build automatizado e gerar um pacote com o mínimo de qualidade garantida é um CI.

Implantar e orquestrar esse pacote entre os servidores é o CD (deploy/release).


Pipeline

Um termo muito utilizado aqui é o pipeline (em português o pessoal gosta de usar “esteira”). Basicamente é a sequência de tarefas que o devops vai automatizar para alcançar um CI/CD.

Logo a pipeline terá etapas/tarefas sequenciais, ex: 
1.    Pega a última versão do código
2.    Faz análise estática de código
3.    Compila
4.    Realiza testes unitários
5.    Empacota
6.    Conecta no Servidor
7.    Implanta
8.    Verifica se a implantação foi bem-sucedida
9.    Lança os relatórios com eventuais erros e status das operações anteriores

Para ficar mais claro, imagine um projeto Angular em um GIT, poderia ter uma sequência de scripts assim:
1.    cd c:\myapps // acessa o diretório onde a aplicação está instalada
2.    rm myapp // remove a versão atual da aplicação
3.    cd c:\reposiroty\myapp // acessa o diretório onde está o fonte da aplicação
4.    git pull // pega a última versão do código
5.    ng test // executa testes unitários
6.    ng build // build e deploy

Lógico que esse foi um exemplo bem simplista. Há como definir estratégias de rollback, off-rotation, etc.

Há também ferramentas que auxiliam esse processo. Mas é legal ter essa visão, pois o que as ferramentas fazem, por baixo dos panos, é rodar scripts como esse em sequência ou até mesmo os que você desejar escrever.


Ferramentas

Uma das plataformas que mais trabalhei foi o TFS, que hoje está disponível na nuvem com o nome de Azure DevOps. Como plataforma, fornece repositórios de código baseado em GIT, processos de build, testes e entrega, contemplando o CI/CD.

Além disso, ele já vem com uma série de atividades prontas para você compilar e publicar seu software. É muito fácil fazer deploy de uma API NodeJS e hospedar ela no Azure.

O Azure Devops tem esse conjunto de ferramentas. Mas é possível usar outras ferramentas e combiná-las para montar uma plataforma de CI/CD. Uma dessas ferramentas que trabalhei bastante foi o Jenkins. Gratuita e livre. Ele tem mecanismos de build, notificação por e-mail, histórico, se pluga com vários compiladores e é fácil colocar scripts para rodar nele.

O Gitlab surgiu como uma alternativa mais corporativa ao Github. Ambos hoje contam com pipelines. Nessa mesma onda, o Bitbucket, versão da plataforma desenvolvido pela Atlassian, a dona do famoso Jira, também conta com pipelines.

Um ponto que vale a pena ressaltar em todas as ferramentas citadas é que elas contam com integrações (baseadas em webhooks) onde é possível plugar notificações via Slack ou Skype, por exemplo. Na onda de orquestradores, podemos citar o Octopus. É possível plugar o Jenkins nele e deixar com que o Octopus distribua sua aplicação pelos servidores.

Já na onda de automação para Apps mobile, algo que tem estado em voga é o Fastlane, fazer delivery de Apps inclui disponibilizar nas lojas das plataformas (App Store ou Google Play) e elas tem suas burocracias.
 

Existem inúmeras outras ferramentas para apoiar o CI/CD. Em breve pretendo elencar algumas e explorar na prática aqui. E você, conhece ou já usou alguma? Deixe sua opinião nos comentários.
 

Compartilhar