02/05/2017 Equipe IT Services

Processo de integração contínua DB1 IT Services

O processo de integração contínua se inicia no planejamento das funcionalidades, que são cadastradas como Features na ferramenta VSTS (Visual Studio Team Services), que são elaboradas pelo Analista de Negócios da equipe, e documentadas formalmente como requisitos.

Após a análise da funcionalidade, é feita a separação da feature em Product Backlog Items (PBI), que se referem a pedaços menores e entregáveis de uma funcionalidade.

Product Backlog Items

Figura 2 – Product Backlog Items

Feita a separação dos PBIs, é hora de separar as tasks que serão desenvolvidas, representa um pequeno bloco de um entregável de uma funcionalidade.

Desenvolvimento

Conclusão das tasks

O processo de desenvolvimento segue seu fluxo normalmente e após a finalização, o desenvolvedor deverá vincular o commit à task concluída, criando um vínculo do código feito com a tarefa, o entregável e a funcionalidade.

Changeset vinculado à tarefa

Figura 3 – Changeset vinculado à tarefa

Builds automatizados

A partir do commit, a ferramenta de build automatizado identifica que houve uma alteração no código e dispara uma compilação com a nova base de código, associando os artefatos gerados pela compilação e relatórios de testes à tarefa executada pelo desenvolvedor.

O processo de build automatizado é responsável por garantir que as alterações realizadas serão compiladas com sucesso, além de garantir a execução dos testes automatizados, alertando os responsáveis caso haja algum comportamento inesperado.

Build automatizado

Figura 4 – Build automatizado

Builds noturnos

Além dos builds automatizados disparados através de commits, temos também os builds noturnos, responsáveis por executar processos mais complexos ou custosos, como testes de integração, análise de código pelo SonarQube, testes end-to-end.

Estes builds são agendados e rodados diariamente após o expediente, visando não interferir no trabalho da equipe que pode estar dependendo da disponibilidade dos servidores envolvidos no processo.

Entrega

Tendo concluído o processo de build com sucesso, é iniciado o processo de entrega contínua, utilizando os artefatos gerados pela compilação, a plataforma de integração contínua iniciará o processo de entrega da funcionalidade para os ambientes configurados, sendo estes desenvolvimento, homologação e produção.

O primeiro ambiente é o de desenvolvimento, um ambiente com deploy contínuo, contendo sempre a última versão disponível da aplicação, com configurações finais da aplicação, para que a equipe de desenvolvimento consiga realizar testes no ambiente mais próximo da realidade do cliente.

O ambiente de homologação é onde a equipe de testes irá garantir que as funcionalidades solicitadas atendem o esperado pelo cliente. Este ambiente só será liberado obrigatoriamente após a entrega no ambiente de desenvolvimento, evitando erros grotescos, como problemas de configuração ou de atualização de bases de dados.

Por último, temos o ambiente de produção, estágio final do processo de entrega contínua, liberado após a equipe de testes garantir que todas as funcionalidades estão dentro do esperado e que não há problemas com a versão gerada.

Durante o processo de entrega contínua, pode ser identificado que houve um problema com a versão. Para que esta versão não seja promovida indevidamente para o ambiente de produção, é feito o bloqueio da mesma, travando o processo até que seja garantido que o cliente não terá problemas com a aplicação.

Cada entrega realizada, é vinculada a uma compilação, que por sua vez está vinculada a uma tarefa, que foi gerada a partir de um entregável correspondente a uma funcionalidade, tendo assim uma rastreabilidade completa do início ao fim do processo.

Entrega automatizada

Figura 5 – Entrega automatizada

Benefícios

Rastreabilidade

Como mencionado no decorrer do documento, é possível rastrear as entregas até o nível de funcionalidade, passando pelos testes executados, builds gerados, código alterado e tarefas realizadas.

Entregas mais seguras

Como não há intervenção manual, a chance de problemas durante as entregas é minimizada, ou seja, podemos realizar entregas mais frequentes, sem medo de problemas técnicos.

Entregas mais frequentes

A partir da implantação deste processo, principalmente da entrega contínua, conseguimos diminuir nossa frequência de entregas para um ritmo semanal, já que todo o processo está automatizado, e basta um clique para liberarmos uma nova versão para o cliente. Ao todo, desde Outubro de 2015, o tempo “economizado” com entregas foi de mais de 300 horas.

Próximos Passos

Integração com casos de testes pela plataforma VSTS

Apesar de ser feita a utilização de testes automatizados, sempre será necessária a execução de testes exploratórios manuais e geração de casos de teste, feitos pela equipe de testes.
Para integrar esse processo no fluxo atual, pretendemos dar início à utilização do hub de testes da plataforma VSTS, vinculando casos de testes, artefatos, possíveis bugs, relatórios de testes exploratórios, entre outros, aos entregáveis planejados no início do processo, dando uma visão clara da abrangência dos testes, além de facilitar a geração de tarefas para correção de possíveis bugs.

Casos de teste e testes exploratórios na plataforma VSTS

Figura 6 – Casos de teste e testes exploratórios na plataforma VSTS

Fluxos de aprovação de versões

Para termos um maior controle das entregas e garantir a satisfação do cliente, queremos implantar um fluxo de aprovação de releases, onde a promoção de uma versão só ocorrerá após a liberação de membros chave do time, como no caso da promoção do ambiente de homologação para produção, onde a equipe de testes irá aprovar a versão, confirmando que todos os processos foram cumpridos com sucesso.

Para maior segurança neste processo, pretendemos implantar um ambiente de pré-produção, para que o cliente possa testar as funcionalidades desenvolvidas e garantir novamente que tudo está conforme o esperado e assim, aprovar a versão e liberar a promoção para produção.

Responsáveis pela aprovação

Figura 7 – Responsáveis pela aprovação

Sobre o autor

Equipe IT Services A Equipe IT Services que escreveu esse artigo é formada por André Moraes, Andressa Pilar, Diego Campanari, Hadyne Biazoto, Luis Uzai, Marco Diniz, Marcos Tomazini, Mary Provinciatto, Pedro Santos, Pedro Silva, Rhafik Gonzalez, Ricardo Aleixo, Robson Cachoeira, Rodrigo Fernandes, Sérgio Bonani, Thiago Vidal e Vinicius Souza.