Marco Valtas

Participando do time do Snap-CI nos dá certeza de duas coisas. A primeira é que você irá aprender muito sobre como projetos são compilados (built) e implantados (deployed). A segunda é que você irá responder mais cedo ou mais tarde a seguinte pergunta:

"Qual é a diferença do Snap-CI para o Travis-CI (CircleCI, Codeship, e outros? Por que devo usar o Snap?"

Integração Contínua (CI) e Entrega Contínua (CD)

Estes dois conceitos apesar de distintos misturam-se no discurso de muita gente, talvez pela razão de que há uma dependência entre os dois. Você não fará Entrega Contínua sem antes fazer Integração Contínua, no entanto estes são ainda dois conceitos distintos, para resumir:

• Integração Contínua - Automação da compilação e teste do seu software quando qualquer mudança é realizada por um membro da equipe.
• Entrega Contínua - Capacidade de implantar seu software de forma automática e sob demanda.

Snap-CI e Travis-CI? E então? Qual é a diferença?

Pois é, há uma semelhança no nome e em suas funcionalidades básicas da compilação e teste de um projeto, no entanto a semelhança entre os dois diminui rapidamente quando consideramos outras funcionalidades.

Ser capaz de compilar e testar seu software quando ocorre uma mudança é a funcionalidade básica de um sistema de Integração Contínua, ambos Snap-CI e Traci-CI possuem esta funcionalidade, no entanto o Snap-CI faz uso de um conceito conhecido como Pipeline de Implantação (Deployment Pipeline, ver Parte II de Entrega Contínua).

Snap-CI e o Pipeline de Implantação

Eis um exemplo de um Pipeline de Implantação simples:

O primeiro retângulo mostra quais as mudanças foram introduzidas juntamente com link para o Github caso seja necessário um detalhamento maior. O restante dos retângulos são os estágios deste pipeline.

O que são estágios e para que eles servem?

De forma resumida, os estágios são apenas um conjunto de comandos, uma separação lógica de uma série de comandos executados. Considere todas as fases distintas que um software deve passar antes de ser colocado em produção. Alguns softwares precisam ser compilados, testados, analisados e etc. Em casos mais avançados podemos considerar o gerenciamento de configuração de infraestrutura como um ou mais estágios.

A capacidade de organizar as fases de automação em estágios nos dá a capacidade de separar diferentes aspectos da preparação do software para ser colocado em produção. Podemos pensar em testes unitários, checagens de formatação do código, checagens de segurança e etc. O software progride de estágio em estágio até ser considerado pronto para ser colocado em produção se todos os estágios forem bem sucedidos.

Implantação (Deployment)

Ao final de uma série de fases (estágios) podemos colocar o software em produção. No entanto muitas equipes de desenvolvimento não colocam o software e produção imediatamente, mas sim, num ambiente similar ao de produção para uma maior e mais detalhada verificação, no Brasil conhecemos este ambiente como "Homologação" e em inglês "User Acceptance Tests (UAT) ou Staging".

Um ponto importante é controlar o que é implantado e quando. Recordando a definição de Entrega Contínua:

• Entrega Contínua - Capacidade de implantar seu software de forma automática e sob demanda.

A tradução do sob demanda para o Snap-CI é o uso de estágios iniciados manualmente (manually triggered stages):

O que isso significa é que este estágio, chamado publish, não será executado automaticamente mas sim quando manualmente iniciado. Neste exemplo em particular isso significa que qualquer mudança feita no projeto não será colocada automaticamente em produção, mas sim, quando nós quisermos.

Podemos ter diversos estágios manuais, e entre eles, estágios automáticos. Esta é a peça chave desta funcionalidade, ela nos dá a flexibilidade de criarmos sequencias complexas de execução e implantação para o nosso projeto. E mais um detalhe, estágios manuais podem ser executados diversas vezes, permitindo implantações de versões anteriores se necessário. Para isso, é importante configurar Artefatos.

Artefatos (Artifacts)

Cada estágio executa uma série de comandos, ao final, queremos colocar em homologação ou produção aquelas mudanças que passaram por todos os estágios. Mas e os artefatos produzidos? Sendo mais específico, se temos um projeto que produz um pacote, binário ou etc, temos que compilar tudo de novo?

A resposta é não. Eis que entram os artefatos. Configurando um ou mais diretórios como alvos para artefatos, o Snap irá salvar e restaurar quaisquer arquivos presentes neles de estágio a estágio. A importância disso é ser compatível com a primeira prática de pipelines de implantação:

"Compile seus binários somente uma vez"

Entrega Contínua, Cap. 5, página 113.

Em consequência, quando você possui um estágio manual para implantação em produção, podemos realizar a implantação do mesmo binário gerado no início do pipeline, o mesmo que passou por todas as fases de teste e verificações.

Integração Contínua

Dentro das recomendações em Entrega Contínua em relação as práticas de Integração Contínua há um destaque ao uso de branches (Branches, frentes de trabalho e integração contínua, Cap. 14, página 395). A ideia básica é que, se as diferentes equipes trabalham num mesmo software mas estão separadas por branches, não podemos de fato assumir que há integração contínua das mudanças. Estamos apenas divergindo e atrasando o momento onde conflitos irão aparecer. De qualquer forma isso não significa que o uso de branches é proibido, mas que seu tempo de vida deve ser o mais curto possível, talvez alguns dias. Ainda resta, se utilizarmos branches em nosso controle de versão, integrar o código.

O Snap tem uma solução para facilitar esta integração e antecipar quando as duas ou mais frentes de trabalho estão divergindo, Automatic Branch Tracking. Ao habilitar esta funcionalidade o Snap irá não apenas executar o pipeline para o seu branch, mas também irá realizar o merge (apenas localmente) com a árvore principal de desenvolvimento e executar novamente o pipeline. Veja abaixo:

Ao final da execução ficamos sabendo não só que nossas mudanças passam pelo pipeline, mas também que irão passar ser fizermos o merge com a árvore principal do controle de versão. Ou seja, estamos sempre informados se nossas mudanças, que agora estão isoladas em um branch causarão ou não mudanças no resto do projeto.

Auditoria e Gestão de Mudanças

Por fim vou mencionar um tópico talvez não tão popular entre os desenvolvedores mas de grande importância para departamentos de T.I., Auditoria e Gestão de Mudanças. Este assunto é resumidamente abordado no livro Entrega Contínua (Cap. 15, página 440).

Quando possuímos uma equipe trabalhando num projeto e vemos que o pipeline está pronto para a fase de implantação, se iniciarmos o estágio de implantação quais mudanças serão publicadas?

Para esta questão o Snap fornece Stage History, onde as mudanças entre os pipelines pode ser visualizada por estágio. Eis um exemplo do histórico de mudanças que serão colocadas em produção do blog do Snap que é um projeto público.

O histórico nos dá uma visibilidade completa das implantações anteriores e quais serão publicadas se iniciarmos o próximo estágio de implantação. Não apenas isso mas também quem iniciou a publicação, dando a ampla visibilidade e rastreabilidade necessária em cenários de desenvolvimento do software em grandes e médias empresas.

Concluindo

Pelos exemplos acima espero ter esclarecido um pouco melhor as diferenças entre o Snap e seus similares. As semelhanças começam em seus nomes e a capacidade de compilar e testar seus projetos de software. Mas a partir daí, o foco do Snap volta-se para as práticas de Entrega Contínua e não apenas Integração Contínua, e esta é a diferença no uso do Snap.