Monografia Poli UFRJ - Case da Implantação de um pipeline de Entrega Contínua de Software em uma Empresa de Mídias

Case da Implantação de um pipeline de Entrega Contínua de
Software em uma Empresa de Mídias Samanta Cicília de Barros Souza Universidade Federal do Rio de Janeiro Curso de Pós Graduação MBA em Garantia de Qualidade de Software Orientadora: Ester José Casado de Lima de Campos, MSc Rio de Janeiro 2015

i FICHA CATALOGRÁFICA Souza, Samanta Cicília de Barros. Case da
implantação de um pipeline de Entrega Contínua de Software em uma Empresa de Mídias / Samanta Cicília de Barros Souza. – Rio de Janeiro, 2015. vii, 34 f.: il. Dissertação (MBA em Garantia de Qualidade de Software) – Universidade Federal do Rio de Janeiro - UFRJ, Escola Politécnica, 2015. Orientadora: Ester José Casado de Lima de Campos 1. Entrega Contínua. 2. Desenvolvimento de Software. 3. Metodologia Ágil. I. Campos, Ester José Casado de Lima de (Orient.). II. Universidade Federal do Rio de Janeiro. Escola Politécnica. III. Entrega Contínua: em Busca do Melhor Software.

iii RESUMO SOUZA, Samanta Cicília de Barros. Entrega Contínua de
Software. Orientadora: Ester Lima de Campos. Rio de Janeiro: UFRJ, Escola Politécnica, 2015. Dissertação (MBA em Garantia de Qualidade de Software). O aumento da complexidade no desenvolvimento de software e o surgimento de novas tecnologias e ferramentas tornam a entrega de software de qualidade e que atenda as necessidades do negócio, cada vez mais complexa. Essa monografia consiste em um estudo de caso sobre a aplicação de Entrega Contínua em uma Empresa do setor de mídias. Com a implantação desse processo concluímos que o tempo de entrega de novas funcionalidades em um software pode ser reduzido, gerando valor para o cliente cada vez mais rápido e mantendo os padrões de qualidade através de um pipeline de implantação que permeia todas as fases do desenvolvimento de software e executa testes automatizados em diferentes níveis.

iv ÍNDICE 1 - Introdução .............................................................................................................................. 1 1.1. Problema .......................................................................................................................
1 1.2. Motivação ..................................................................................................................... 2 1.3. Objetivo ......................................................................................................................... 3 1.4. Estrutura da Dissertação ............................................................................................ 4 2. Revisão Literária ................................................................................................................. 5 2.1. Manifesto Ágil ............................................................................................................... 5 2.1.1. Valores ................................................................................................................... 6 2.1.2. Princípios ............................................................................................................... 6 2.2. Scrum e Kanban .......................................................................................................... 7 2.3. Controle de Versão ..................................................................................................... 8 2.4. Testes Automatizados ................................................................................................ 8 2.4.1. Quadrante de Testes Ágeis ................................................................................ 9 2.4.2. Pirâmide de Automação de Testes ................................................................. 10 2.5. Integração Contínua .................................................................................................. 11 2.6. Entrega Contínua de Software ................................................................................ 12 2.6.1. Pipeline de Implantação .................................................................................... 12 2.6.1.1. Estágio de Commit ......................................................................................... 13 2.6.1.2. Automação de Testes de Aceitação ............................................................ 15 2.6.1.3. Automação de Testes de Capacidade ......................................................... 15 2.6.1.4. Implantação e Entrega da Versão ................................................................ 16 3. Propostas da Solução ...................................................................................................... 17 3.1. Cenário do Estudo de Caso ..................................................................................... 17 3.2. Solução ....................................................................................................................... 18 3.2.1. Estágio de Commit ................................................................................................. 19 3.2.2. Estágio de Aceite ................................................................................................... 21 3.2.2.1. Deploy em Integração ........................................................................................ 21 3.2.2.1.1. Promover para Staging ................................................................................... 22 3.2.2.2. Deploy em Staging ............................................................................................. 23 3.2.2.2.1. Promover para Produção ............................................................................... 24 3.2.2.3. Deploy em Produção .......................................................................................... 27 3.3. O processo de implantação da Entrega Contínua ................................................ 29 4. Conclusão .......................................................................................................................... 31

v Referências Bibliográficas ....................................................................................................... 33

vi LISTA DE FIGURAS Figura 1 - Valores do Manifesto
Ágil. Fonte: Manifesto Ágil ............................... 5 Figura 2 – Quadrante de Testes Ágeis. Fonte: Marick B. .................................. 9 Figura 3 - Pirâmide de Automação de Testes. Fonte: Cohn (2009) .................. 11 Figura 4 – Pipeline de Implantação. Fonte: Humble e Farley (2014) ................ 13 Figura 5 - Estágio de Commit. Fonte: Humble e Farley (2014) ......................... 14 Figura 6 - Estágio de Testes de Aceitação. Fonte: Humble e Farley (2014) .... 15 Figura 7 Pipeline de Implantação ..................................................................... 18 Figura 8 Commit Stage da Aplicação ................................................................ 19 Figura 9 Gerenciador de Artefatos .................................................................... 20 Figura 11 Gerenciador de Artefatos atualizado com a versão de Integração ... 22 Figura 12 Gerenciador de Artefatos atualizado com o Promover para Staging 23 Figura 13 Deploy em Staging ............................................................................ 24 Figura 14 Gerenciador de Artefatos atualizado com a versão de Integração ... 24 Figura 15 Análise de Log Automatizada ........................................................... 25 Figura 16 Solicitação aberta de forma automática ............................................ 26 Figura 17 Gerenciador de Artefatos atualizado com o Promover para Produção .......................................................................................................................... 27 Figura 18 Deploy em Produção ......................................................................... 27 Figura 19 Gerenciador de Artefatos atualizado com a versão de Produção ..... 28

vii GLOSSÁRIO XP Extreme Programming FTP File Transfer Protocol PDCA
Plan Do Check Act API Application Programming Interface TI Tecnologia da Informacão UI User Interface ITIL Information Technology Infrastrucuture Library

1 1 - Introdução Este capítulo apresenta, primeiramente, a motivação
para o uso de Entrega Contínua no desenvolvimento de software. Em seguida, são apresentados os objetivos da dissertação e, finalmente, é apresentada a organização estrutural da dissertação. 1.1. Problema Uma Empresa do setor de mídias sediada no Rio de Janeiro, possui 5 equipes de desenvolvimento Web que utilizam práticas e metodologias ágeis, como Scrum1, XP2 e diferentes tecnologias e ferramentas de desenvolvimento de software. Apesar da utilização dessas metodologias ágeis permitirem um ciclo menor de desenvolvimento, essas equipes só conseguem disponibilizar novas funcionalidades para os clientes mediante agendamento de uma Requisição de Mudança que deve ser previamente acordada com a Equipe de Infraestrutura, já que os times de desenvolvimento não tem acesso ao ambiente de Produção, e obedecer a janela semanal de terças e quintas. Além disso, algumas atividades críticas do processo de desenvolvimento são feitas de forma manual, como por exemplo, a atualização dos servidores do ambiente de produção, que é feita por um membro da equipe de Infraestrutura através de FTP, utilizado para transferir as novas versões do software para o servidor, e execução de comandos manuais para fazer a atualização dos mesmos. 1 Framework de desenvolvimento iterativo e incremental utilizado no gerenciamento de projetos e desenvolvimento de software ágil. 2 Metodologia ágil para equipes pequenas e médias e que irão desenvolver software com requisitos vagos e em constante mudança. Para isso, adota-se a estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de software.

2 Outras fases do processo apresentam problemas, como a execução
de testes automatizados. Os testes unitários criados pelos desenvolvedores não são executados como parte do fluxo de desenvolvimento, fazendo com que alguns problemas não sejam identificados mais cedo nesse ciclo. A implantação do software nos ambientes de teste também possui falhas, já que não é feita do mesmo modo em todos os outros ambientes, gerando problemas decorrentes da diferença entre esses ambientes. Por causa disso muitos defeitos só são observados depois que a versão já está em Produção. Dados todos esses problemas, o processo de disponibilizar novas versões em Produção para os cliente é muito custoso e suscetível a falhas. 1.2. Motivação A forma como as empresas desenvolvem software muda rapidamente – seja por necessidades do mercado, evolução de tecnologias ou até mesmo redução de custos. Todos os dias essas empresas precisam fazer mais com menos investimento, para simultaneamente manter a competitividade e reduzir os custos. (KIM et al, 2013, p.5) Considerando esse cenário, as empresas precisam cada vez mais de uma TI de alto desempenho que suporte seu negócio com entregas de software frequentes e de qualidade através de um processo de desenvolvimento cujo tempo, entre a geração da ideia e sua disponibilização para o usuário, seja o mais rápido e confiável possível, a fim de que a empresa consiga responder as mudanças de mercado e se manter competitiva.

3 Desde 2001 os princípios do Manifesto Ágil3 (2001) falavam
de entregar software funcionado com frequência, já que software que não está em produção, não está gerando valor para os clientes. Porém essa premissa nem sempre consegue ser posta em prática, já que geralmente existe muita burocracia envolvida nesse processo de entrega, causando atrasos e falhas no desenvolvimento, que culminam em software não funcionando em ambiente de Produção. Para colocar essa premissa em prática e ter uma entrega de software confiável, é necessário que o processo seja automatizado a fim de atender 3 objetivos, como Humble e Farley (2014) listam: tornar todas as partes do processo de compilar, implantar, testar e entregar a versão visíveis para todas as pessoas envolvidas a fim de promover colaboração; melhorar o feedback do processo para que problemas sejam identificados o mais cedo possível dentro do ciclo de desenvolvimento de software; e permitir que o software seja entregue em qualquer ambiente e a qualquer momento. 1.3. Objetivo Essa monografia tem como objetivo descrever como foi realizada a implementação do processo de Entrega Contínua em uma empresa nacional do setor de mídias, a qual será referenciada nessa dissertação como Empresa. Nesse estudo de caso, veremos como as fases do processo de desenvolvimento – compilar, testar e liberar o software – se encaixam no pipeline de entrega4 e quais os benefícios e dificuldades dessa abordagem. 3 Declaração de princípios que fundamentam o desenvolvimento ágil de software. 4 Representação automatizada do processo de entrega de software, desde uma mudança até sua implantação em produção.

4 1.4. Estrutura da Dissertação Esta dissertação está organizada da
seguinte forma: o primeiro capítulo descreveu a motivação e o objetivo dessa monografia. O capítulo 2 apresenta a revisão literária dos assuntos necessários para a compreensão do estudo de caso. O capítulo 3 descreve o estudo de caso realizado, na Empresa e, finalmente, o capítulo 5 encerra essa monografia apresentando as conclusões.

5 2. Revisão Literária Este capítulo apresenta os conceitos necessários
para compreensão dessa monografia. Primeiramente veremos o Manifesto Ágil cujos princípios estão presentes na Entrega Contínua. Em seguida falaremos de Scrum e Kanban, Controle de Versão, Testes Automatizados e Integração Contínua e Testes. Na última seção abordaremos o conceito de Entrega Contínua e seu principal padrão: o pipeline de Implantação. 2.1. Manifesto Ágil O Manifesto Ágil foi criado em 2001 por um grupo de profissionais de desenvolvimento que resolveu se reunir para pensar em melhores formas de entregar software. A partir de então, ficou conhecido como Desenvolvimento Ágil, qualquer abordagem de desenvolvimento que se baseasse nesse manifesto que é formado por 4 valores, apresentados na Figura 1, e 12 princípios. Figura 1 - Valores do Manifesto Ágil (2001).

6 2.1.1. Valores Os 4 valores do Manifesto Ágil (2001)
são: 1. Indivíduos e interação mais que processos e ferramentas 2. Software em funcionamento mais que documentação abrangente 3. Colaboração com o cliente mais que negociação de contratos 4. Responder a mudanças mais que seguir um plano Como pode ser observado, o foco no desenvolvimento ágil passa a ser as pessoas e o produto do trabalho delas (nesse caso o software), ao invés de burocracias como contratos e ferramentas. Outra característica marcante é a capacidade de responder a mudanças, visto que as necessidades de negócio são cada vez mais dinâmicas. Os times de desenvolvimento devem possuir a capacidade de mudar de direção sem comprometer tudo que já foi feito. 2.1.2. Princípios Além dos Valores, o Manifesto Ágil (2001) traz 12 princípios para o desenvolvimento de software que estão alinhados aos valores já citados. Entre os 12 princípios podemos citar alguns que são os alicerces para a monografia aqui apresentada: 1. Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor. 2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.

7 3. Entregar software funcionando com frequência, na escala de
semanas até meses, com preferência aos períodos mais curtos. 4. Software funcional é a medida primária de progresso. Nesses princípios citados pode-se observar que a maior prioridade é entregar software funcionado de valor ao cliente, respondendo as mudanças e com frequência. 2.2. Scrum e Kanban Conforme pode ser visto em Sutherland (2014), o Scrum é um framework de desenvolvimento cujo modelo é iterativo e incremental, ou seja, são feitas pequenas entregas ao logo do tempo e a cada nova entrega o produto, nesse caso o software, vai sendo incrementado. A entrega é baseada em timeboxes que variam de 2 até 4 semanas e que tem como produto final uma nova versão do software para ser colocada em Produção. O Scrum está diretamente ligado ao Manifesto Ágil (2001) citado anteriormente, pois valoriza software funcionando no final da iteração mais do que uma documentação extensa; consegue responder a mudanças mais facilmente, visto que o tempo de desenvolvimento é mais enxuto; e aposta na colaboração do cliente em atuar junto com o time de desenvolvimento para construir uma aplicação que atenda ao negócio. Já no Kanban o fluxo de desenvolvimento é contínuo, apenas limitando o trabalho em progresso de acordo com a capacidade do time e acompanhando o tempo de execução das tarefas para otimizá-lo sempre que possível. No caso do Kanban, como não são utilizados timeboxes, as entregas são feitas a todo o momento a partir da

8 finalização das tarefas pertinentes a uma funcionalidade, podendo ser
colocadas em Produção sempre que estiverem disponíveis, como pode ser visto em Kniberg e Skarin (2010). 2.3. Controle de Versão Sistemas de Controle de Versão ou Controle de Código são sistemas que guardam múltiplas versões de arquivos. Assim, mesmo modificando um arquivo é possível continuar tendo acesso às versões anteriores deles. Ele também proporciona a colaboração entre os membros de um time, permitindo que várias pessoas alterem um mesmo arquivo sem perder nenhum conteúdo alterado por qualquer uma das pessoas. Segundo Humble e Farley (2014), os principais objetivos do Controle de Versão são guardar a versão de cada arquivo garantindo o acesso a essas versões e permitir a colaboração em equipes distribuídas no tempo e espaço. 2.4. Testes Automatizados Os testes automatizados são scripts que verificam, como o auxílio de ferramentas, se os requisitos do sistema estão sendo atendidos. Segundo Crispin e Gregory (2009), automação de testes é uma prática muito importante em projetos ágeis. Ela permite que os times entreguem software de alta qualidade e com frequência, sem medo de quebrar o que já estava funcionando.

9 Eles são parte muito importante da Entrega Contínua, já
que são feitas mudanças frequentes das versões em Produção e é necessário que seja feita a verificação se tudo continua funcionando entre cada mudança realizada. 2.4.1. Quadrante de Testes Ágeis A disciplina Qualidade de Software tem muitas dimensões e para cada uma delas são necessárias diferentes abordagens de teste. Essas abordagens podem ser vistas no Quadrante de Testes Ágeis desenvolvido por Brian Marick. (Figura 2) Figura 2 – Quadrante de Testes Ágeis. Fonte: Marick B. Segundo esse quadrante, os testes podem ser automatizados, manuais ou com o auxílio de alguma ferramenta, podem ter foco em negócio ou tecnologia e suportar o time ou criticar o produto.

10 Os testes que suportam o time são aqueles cujo
objetivo é ajudar os desenvolvedores e analistas de teste durante o desenvolvimento a fim de validar a qualidade em relação aos requisitos e ao código da aplicação. O primeiro quadrante abrange os testes de unidade que são feitos pelos desenvolvedores para garantir o funcionamento das pequenas partes da aplicação – métodos, por exemplo – e testes de componente, visando a integração entre essas pequenas partes. É recomendado que esses testes sejam automatizados, considerando a grande quantidade de testes necessários. No segundo quadrante entram os testes que vão validar o funcionamento da aplicação segundo a visão de negócio. Quanto aos testes que criticam o produto, o foco é explorar o funcionamento da aplicação para além dos cenários pré-definidos e já testados nos quadrantes anteriores. Por isso no terceiro quadrante têm-se os testes exploratórios e de usabilidade, e no quarto quadrante os testes de performance e segurança. 2.4.2. Pirâmide de Automação de Testes O conceito da Pirâmide de Automação de Testes foi introduzido por Cohn (2009). Essa pirâmide divide os testes em três níveis: Unidade, Serviço e UI. (Figura 3)

11 Figura 3 - Pirâmide de Automação de Testes. Fonte:
Cohn (2009) Segundo essa pirâmide, nossa aplicação deve ter uma base maior de testes unitários (que possuem tempo de execução mais rápido), seguida por testes de serviço (conhecidos também como testes de integração) e um conjunto menor de testes de interface que, de toda a pirâmide, são os mais lentos e mais custosos em termos de manutenção. No estudo de caso dessa monografia, abordaremos os testes unitários e de interface. 2.5. Integração Contínua É uma prática do XP onde todo código da aplicação deve ser integrado diversas vezes ao dia para garantir que o software continue funcionando. A cada mudança feita a aplicação é compilada e os testes automatizados são executados a fim de verificar se essas mudanças influenciaram no funcionamento da aplicação. Se esse processo

12 falhar, é fundamental que os desenvolvedores parem e corrijam
os problemas imediatamente. Segundo Humble e Farley (2014): “O objetivo da integração é manter o software em um estado funcional o tempo todo.” 2.6. Entrega Contínua de Software Segundo Fowler (2013) Entrega Contínua é a disciplina de desenvolvimento de software onde ele é construído de forma que possa ser disponibilizado em produção a qualquer momento. Para que isso seja possível, é necessário utilizar Integração Contínua para que o código criado por todos os membros do time seja integrado frequentemente, que os testes automatizados em todos os níveis sejam executados como parte dessa integração e que o software seja implantado em ambientes que sejam uma cópia do ambiente de Produção para que os problemas sejam encontrados cada vez mais cedo dentro do ciclo de desenvolvimento e antes de chegar a Produção. 2.6.1. Pipeline de Implantação Como Humble e Farley (2014) citam o pipeline de implantação: “É uma implementação automatizada do processo de compilar todas as partes de uma aplicação, implantá-la em um ambiente qualquer – seja de homologação ou produção – testá-la e efetuar sua entrega final.”

13 Figura 4 – Pipeline de Implantação. Fonte: Humble e
Farley (2014) Como pode ser observado na Figura 4, o Pipeline de Implantação é formado por fases, onde cada mudança que ocorre no Controle de Versão dispara a primeira fase, criando binários e instaladores. Depois esses binários passam por uma série de testes para garantir que a aplicação funciona de acordo com os resultados esperados e, se todos os testes passarem, uma nova versão fica disponível para ser colocada no ambiente de produção. A seguir será apresentado as 4 principais etapas de um pipeline de implantação. 2.6.1.1. Estágio de Commit O Estágio de Commit é a entrada para o Pipeline de Implantação. Assim que alguma mudança é introduzida no Controle de Versão (por intermédio do comando commit), essa fase é disparada e são realizados alguns passos que podem ser observados na Figura 5.

14 Figura 5 - Estágio de Commit. Fonte: Humble e
Farley (2014) Assim que o código é atualizado, o Estágio de Commit compila e executa os testes unitários sobre esse código integrado. Se esses testes unitários (presentes no primeiro quadrante) tiverem sucesso na execução, são criados artefatos que posteriormente serão instalados nos ambientes de homologação e produção. Além disso podem ser realizadas nessa fase algumas análises de código e como saída são armazenados relatórios apresentando o resultado da execução dos testes unitários, cobertura de testes unitários e o resultado da análise estática de código. Além disso, os próprios artefatos são armazenados em um repositório de artefatos5. Essa fase fornece um feedback rápido para os desenvolvedores informando se aquela mudança que foi realizada no código pode prosseguir no pipeline ou se deve ser corrigida. 5 Controle de versão para os artefatos do projeto, como binários e relatórios de teste

15 2.6.1.2. Automação de Testes de Aceitação Os Testes de
Aceitação Automatizados são uma parte muito importante do Pipeline de Implantação, é através deles que os requisitos de negócio da aplicação são testados. Figura 6 - Estágio de Testes de Aceitação. Fonte: Humble e Farley (2014) Como pode ser observado na Figura 6, nessa fase os artefatos, que foram criados e armazenados no Estágio de Commit, são disponibilizados no ambiente de testes para que sejam executados os Testes de Aceitação Automatizados. 2.6.1.3. Automação de Testes de Capacidade Presentes no quarto quadrante de testes, os testes de capacidade são importantes para criticar o desempenho da aplicação. Mesmo que todas as fases anteriores do Pipeline de Implantação apresentem sucesso, a aplicação pode chegar

16 ao ambiente de Produção e falhar devido a grande
quantidade de acessos, por exemplo. Para essa fase é necessário utilizar alguma ferramenta de testes de capacidade e definir um baseline de valores de tempo de resposta aceitáveis de acordo com cada aplicação. 2.6.1.4. Implantação e Entrega da Versão A implantação das versões deve ser realizada da mesma forma em todos os ambientes – homologação e produção. Para isso devem-se ter scripts de implantação automatizados que recuperem um artefato (que passou em todas as fases anteriores) e o disponibilize no ambiente desejado. Além disso, é importante ter uma suíte de Smoke Tests6 que seja executada automaticamente depois de cada implantação. Segundo Humble e Farley (2014), a principal diferença entre uma implantação e uma entrega de versão é a capacidade de revertê-la. Por isso na hora de modelar o processo de entrega é importante, além de definir as fases (testes de integração, testes de aceitação, testes de capacidade, homologação e produção, entre outras), ter um processo que permita reverter as alterações para a última versão estável. 6 Subconjunto de todos os casos de testes definidos/planejados que cobre a principal funcionalidade de um componente ou sistema, para averiguar as principais funções de um programa em funcionamento.

17 3. Propostas da Solução Este capítulo apresenta o Estudo
de Caso da aplicação de Entrega Contínua em um projeto Web, desenvolvido em Grails, com o objetivo de diminuir o tempo de entrega de novas versões. 3.1. Cenário do Estudo de Caso Este Estudo de Caso foi realizado com base em um sistema Web, desenvolvido em Grails. O projeto possuía testes unitários e testes de aceitação automatizados. Porém esses testes eram executados na máquina do desenvolvedor e não havia nenhum controle se eles realmente tinham passado ou se alguma parte do processo tinha sido burlada. Além disso, os artefatos utilizados para os deploys em cada ambiente eram gerados de forma manual pelos próprios desenvolvedores e colocados nos ambientes (de teste e produção) também de forma manual pela equipe de infraestrutura. Para realizar um deploy em ambiente de produção era necessário abrir uma solicitação de deploy na ferramenta de Gestão de Mudanças e aguardar a aprovação do Comitê de Mudanças e da Equipe de Qualidade. O tempo gasto entre desenvolver uma nova funcionalidade e colocá-la em Produção podia variar entre 1 ou 3 dias.

18 3.2. Solução A solução adotada para resolver os problemas
citados acima, foi materializar as fases do processo de Entrega de Software em um pipeline de Entrega Contínua usando a ferramenta Jenkins (2015), conforme pode ser visto na Figura 7. O Jenkins (2015) é uma ferramenta de Integração Contínua que permite automatizar as tarefas necessárias ao processo de desenvolvimento de software. Figura 7 Pipeline de Implantação A seguir serão descritas como foi realizada a implantação e configuração do pipeline de Entrega Contínua segundo as fases observadas na Figura 7: Estágio de Commit, e Estágio de Aceite em Integração, Staging e Produção.

19 3.2.1. Estágio de Commit A primeira fase do Pipeline,
conhecida como Estágio de Commit, é onde a versão candidata para Produção começa a tomar forma. Nessa fase são executados os testes que compõem a base da Pirâmide de Automação mostrada no Capítulo 2. A Figura 8 exemplifica essa fase em um job do Jenkins, mostrando os resultados da execução dos testes unitários e de cobertura de testes. Figura 8 Commit Stage da Aplicação Nessa fase o código que foi alterado pelo desenvolvedor e colocado no Controle de Versão, que foi abordado no Capítulo 2, é atualizado no Jenkins para que os testes unitários sejam executados e seja coletada a Cobertura de Código. Se esses testes forem executados com sucesso, a aplicação é compilada a fim de gerar um artefato que será armazenado no Gerenciador de Artefatos. Assim, o artefato fica disponível para ser colocado no primeiro ambiente, chamando Integração ou Desenvolvimento.

20 Ao fim dessa fase, tem-se um artefato, como por
exemplo o artefato de versão 18883, observado na Figura 9, que pode ser colocado no ambiente de Integração para que sejam realizados testes de aceitação. Para saber o status dos artefatos, foi desenvolvida pela Equipe de Qualidade da Empresa uma ferramenta chamada Gerenciador de Artefatos, como pode ser verificado na Figura 9. Nessa ferramenta é possível observar todos os artefatos gerados e saber qual seu status. Como por exemplo na Figura 9, o artefato exemplo-18883.war foi criado em 05-10-2015 as 14:49, esse artefato pode ser colocado no ambiente de Integração através de um deploy. Porém ele não pode ser colocado no ambiente de Staging e Produção já que ainda não passou pelas respectivas fases de teste. Além disso a ferramenta apresenta qual a última versão que foi implantada em cada ambiente. Figura 9 Gerenciador de Artefatos Se esta fase falhar, o artefato não é gerado e é preciso que o desenvolvedor investigue o problema, commit as alterações para o Controle de Versão e reinicie a fase.

21 3.2.2. Estágio de Aceite 3.2.2.1. Deploy em Integração Nessa
fase é necessário informar qual a versão do artefato que será feito o deploy. Para fazer o deploy do artefato criado na seção anterior, nesse caso o 18883, basta informar esse número de versão no campo “Versão” do Jenkins que é exemplificado na Figura 8. Depois disso o artefato é baixado do Gerenciador de Artefatos e colocado no ambiente de Integração através de um script de Deploy para aquele servidor de Aplicação específico, como Tomcat, por exemplo. Figura 10 Deploy em Integração Depois que o deploy é executado com sucesso, o Gerenciador de Artefatos é atualizado, e a versão 18883 se encontra disponível nesse ambiente, porém como pode ser observado na Figura 11, no campo destacado, essa versão ainda não pode ir para o próximo ambiente, nesse caso Staging.

22 Figura 11 Gerenciador de Artefatos atualizado com a versão
de Integração Se esta fase falhar é necessário fazer o deploy com a última versão estável disponível. 3.2.2.1.1. Promover para Staging Essa fase é composta pelos Smoke Testes, ou seja, uma suíte de testes de aceitação automatizados com uma quantidade menor de testes que representam a parte mais importante da aplicação. Esses testes são os que estão no topo da Pirâmide de Automação apresentada no Capítulo2. Para automação desses testes foram utilizados o Selenium Webdriver (2015) e o JUnit (2015). O Selenium Webdriver é uma API que automatiza as ações do browser e o JUnit é um framework para testes unitários em Java Se o artefato passar nesses testes, ele fica disponível para o Deploy em Staging como pode ser observado no Gerenciador de Artefatos, no campo destacado, como na Figura 12.

23 Figura 12 Gerenciador de Artefatos atualizado com o Promover
para Staging Se esta fase falhar, o artefato não poderá passar para próxima fase e será descartado. Assim, o desenvolvedor terá que corrigir o problema e começar novamente o Estágio de Commit. 3.2.2.2. Deploy em Staging Essa fase é semelhante ao Deploy em Integração. É necessário informar qual a versão do artefato e então esse artefato é disponibilizado no ambiente de Staging. Para fazer o deploy do artefato criado na seção “Estágio de Commit” e que passou pela fase “Promover para Staging”, nesse caso o 18883, basta informar esse número de versão no campo “Versao” do Jenkins que é exemplificado na Figura 13.

24 Figura 13 Deploy em Staging Como pode ser visto
na Figura 14, no campo destacado, a versão do artefato em Staging é atualizada. Figura 14 Gerenciador de Artefatos atualizado com a versão de Integração Se esta fase falhar é necessário fazer o deploy com a última versão estável disponível. 3.2.2.2.1. Promover para Produção Essa fase é composta pelos Testes Regressivos, que é a suíte completa de testes de aceitação automatizados que o projeto possui e que utiliza, também o Selenium

25 Webdriver (2015) e o JUnit (2015). Além disso, nessa
fase também são executados os Testes de Capacidade automatizados, que foram citados no Capítulo 2, através do JMeter (2015), a fim de validar o tempo de resposta da aplicação. O Jmeter (2015) é uma ferramenta utilizada para testes de performance para recursos estáticos ou dinâmicos Outra parte dessa fase é a Análise de Logs automatizados, onde são sumarizados os logs de erro da aplicação a fim de levantar os erros que mais aconteceram, conforme apresentado na Figura 15. Por exemplo, ocorreram 7 erros de status 503 e 11 erros de status 404. Figura 15 Análise de Log Automatizada

26 Se o resultado de todos esses testes for positivo,
é aberta automaticamente uma Solicitação de Mudança informando a data e a hora da execução do Deploy em Produção. Como pode ser observado na Figura 16, após a abertura, é disparado um e- mail pelo próprio Jenkins (2015) com as informações sobre a mudança programada. Essa Solicitação de Mudança é necessária para que o processo esteja em conformidade com a parte de Gestão de Mudanças do ITIL (2015) , que é um conjunto de boas práticas aplicadas a infraestrutura, operações e gerenciamento de serviços de TI. Figura 16 Solicitação aberta de forma automática Por fim, o Gerenciador de Artefatos é atualizado, informando que a versão 18883 pode ser coloca em Produção, conforme apresentado na Figura 17, no campo destacado.

27 Figura 17 Gerenciador de Artefatos atualizado com o Promover
para Produção Se esta fase falhar, o artefato não poderá passar para próxima fase e será descartado. Assim, o desenvolvedor terá que corrigir o problema e começar novamente o Estágio de Commit. 3.2.2.3. Deploy em Produção Como nas outras fases de deploy, o Deploy em Produção é constituído de duas etapas: 1. Recuperar o artefato do Gerenciador de Artefatos; 2. Executar o script de deploy nos servidores de Produção. Figura 18 Deploy em Produção

28 Na Figura 18 pode ser observado que o processo
é semelhante aos outros deploys, basta informar a versão desejada e iniciar o Build. Caso o deploy seja realizado com sucesso, o Gerenciador de Artefatos é atualizado com a versão que está em Produção e informa quanto tempo levou entre o Estágio de Commit e o Deploy em Produção, no artefato utilizado nesse Estudo de Caso, o tempo foi de 2 horas, como demonstra a Figura 19, no segundo campo destacado. Como foi citado no início do estudo de caso, o tempo gasto anteriormente para fazer mudanças em ambiente de produção podia variar de 1 a 3 dias. Com a implantação de Entrega Contínua, esse tempo foi reduzido para cerca de 2 horas. Figura 19 Gerenciador de Artefatos atualizado com a versão de Produção Se essa fase falhar, basta executá-la novamente utilizando o último artefato estável disponível.

29 3.3. O processo de implantação da Entrega Contínua Implantar
o processo de Entrega Contínua não se trata apenas de ter as ferramentas e criar os pipelines. É necessário um grande comprometimento das pessoas envolvidas, tanto os desenvolvedores, analistas de teste e sysadmins7 quanto dos gestores. Essas pessoas precisam entender os benefícios que o pipeline irá trazer e que serão necessárias mudanças dentro do processo de desenvolvimento para se adequar as melhores práticas. São necessários alguns passos antes de começar a criação dos pipelines. Se o time não possui uma cobertura de testes confiável e testes automatizados em todos os níveis, o fluxo de entrega pode ser comprometido pela má qualidade no desenvolvimento. Mais importante do que apenas entregar software de forma mais rápida, é que esse software seja de qualidade. Os Testes Automatizados em todos os níveis da Pirâmide de Automação, citados no Capítulo 2, são de extrema importância para o bom funcionamento desse processo. No projeto aqui apresentado, a aplicação possuía testes automatizados em nível unitário e de UI, tendo sido apenas necessário configurar a execução dos mesmos dentro das fases do pipeline. Outro passo importante é que o time precisa mudar o conceito do que é software entregue. Muitas pessoas acreditam que a entrega do software acontece quando o desenvolvedor acaba de codificar, mas na realidade o software só está entregue quando passa a gerar valor para o cliente, ou seja, quando está no servidor de Produção, sendo utilizado pelo usuário final. Uma mudança que aconteceu no time que 7 Administrador do Sistema

30 desenvolve a aplicação foi a metodologia de trabalho. O
time que antes adotava o Scrum passou a adotar o Kanban, ou seja, ao invés de ter ciclos de entrega de 15 dias, eles passaram a entregar funcionalidades sempre que o desenvolvimento tinha sido concluído passando a ter deploys todos os dias e subindo código novo e funcional para Produção diariamente. Apesar desse processo trazer muitas vantagens a entrega de software, existem alguns pontos que podem incomodar os desenvolvedores na hora de mudar seu comportamento. Para times que não possuem um processo definido, passar a utilizar pipelines pode parecer burocrático já que ao invés de fazer o que quiser, como por exemplo colocar um artefato em Produção com os testes automatizados falhando, ele precisa seguir todos os passos do pipeline. Porém com o passar do tempo e da utilização do pipeline, esses times vão enxergando o valor de ter as fases bem definidas e que ao contrário de ser um processo burocrático, é um processo rápido e que ajuda a garantir a qualidade do software. Outro ponto importante é que esse trabalho deve ser construído em conjunto com todas as áreas envolvidas no projeto. Tanto desenvolvedores quanto sysadmins devem trabalhar juntos para pensar e construir as fases do pipeline que se adequam melhor ao negócio. Para projetos que já estão em andamento e que querem utilizar o pipeline, o foco inicial deve ser em criar os testes automatizados para toda nova funcionalidade e automatizar os passos manuais do processo, como por exemplo o deploy, para depois amarrar as fases e transformá-las em um pipeline.

31 4. Conclusão Conforme proposto, essa monografia apresentou como foi
a implementação de Entrega Contínua em um projeto Web da Empresa. Através de um trabalho conjunto entre todas as pessoas envolvidas no desenvolvimento de software, foi possível criar um pipeline de implantação automatizado que passa por todas as fases da entrega de software, executando diferentes tipos de teste automatizado e em diferentes níveis, que permitem um feedback rápido para cada ação do desenvolvedor dentro desse pipeline. Mesmo com a utilização de diferentes ferramentas e linguagens de programação por parte da empresa, o pipeline permitiu a padronização dos projetos quanto ao assunto entrega de software. Além disso, foi possível resolver outros problemas que eram enfrentados pela Empresa. As atividades, que eram realizadas de forma manual, como a atualização do ambiente de Produção, foram automatizadas e incluídas no pipeline, reduzindo os erros ocorridos nesses passos manuais. A execução de testes automatizados que antes estavam condicionada a execução por parte do desenvolvedor em sua própria máquina, também foi automatizada e incluída no pipeline, sendo executada em diferentes fases do pipeline. Os benefícios encontrados nesse estudo foram: 1. A redução do tempo de entrega das funcionalidades, que antes eram entregues de 1 a 3 dias porque dependiam de um agendamento de Requisição de Mudança que precisava ser aprovado de forma manual e obedecer uma janela de Deploy, e passaram a ser entregues em 2 horas;

32 2. O aumento da qualidade dessas entregas através da
execução de testes unitários, de aceitação e de capacidade de forma automática que validam se aquela entrega está pronta para chegar ao ambiente de Produção. No caso de os testes não apresentarem o resultado esperado, o próprio pipeline impede a continuação das fases, trazendo outro benefício que é não permitir a entrada em ambiente de Produção de funcionalidades que estejam com defeitos. Assim foi possível atender os 3 objetivos da Entrega Contínua citados por Humble e Farley (2014): 1. Todas as partes do processo de compilar, implantar, testar e entregar a versão se tornaram visíveis para todas as pessoas envolvidas, promovendo maior colaboração principalmente entre os times de desenvolvimento e infraestrutura; 2. O feedback do processo se tornou mais rápido permitindo a identificação de problemas desde o commit do desenvolvedor até os testes em ambiente de homologação; 3. O software pôde ser entregue em qualquer ambiente e a qualquer momento. Assim, a implantação de um pipeline de Entrega Contínua trouxe, além de maior rapidez nas entregas de software, também maior qualidade para as mesmas.

33 Referências Bibliográficas BECK, K. et al. Manifesto Ágil, 2001.
Disponível em: http://www.manifestoagil.com.br/principios.html Acesso em: 03 fev. 2016 COHN, M. Succeeding with Agile: Software Development Using Scrum. 1. Ed. Addison-Wesley Professional, 2009.504 p. CRISPIN, L.; GREGORY, J. Agile Testing: A Practical Guide for Testers and Agile Teams. 1. ed. Addison-Wesley Professional, 2009. FOWLER, M.; Continuous Delivery, 2013. Disponível em: http://martinfowler.com/bliki/ContinuousDelivery.html. Acesso em: 06 dez. 2015. HUMBLE, J.; FARLEY, D. Entrega Contínua: Como Entregar Software de Forma Rápida e Confiável. 1.ed. Porto Alegre: Bookman, 2014.464p. ITIL, 2015. Disponível em: http://www.itil.org.uk/index.htm. Acesso em: 17 jan. 2015 JENKINS, 2015. Disponível em: https://jenkins-ci.org/. Acesso em: 09 jan. 2015 JMETER, 2015. Disponível em: http://jmeter.apache.org/. Acesso em: 09 jan. 2015 JUNIT, 2015. Disponível em: http://junit.org/. Acesso em: 17 jan. 2015

34 KIM, G. et al. The Phoenix Project: A Novel
About IT, DevOps, and Helping Your Business Win. IT Revolution Press, 2013.376 p. KNIBERG, H.; SKARIN, M. Kanban and Scrum Making the Most of Both 1. ed. C4Media 2010. MARICK, B.; Agile testing directions: tests and examples, 2003. Disponível em http://www.exampler.com/old-blog/2003/08/22/#agile-testing-project-2. Acesso em: 09 jan. 2015. SELENIUM, 2015. Disponível em: http://www.seleniumhq.org/projects/webdriver/. Acesso em: 17 jan. 2015 SUTHERLAND, J. Scrum - A Arte de Fazer o Dobro de Trabalho na Metade do Tempo. Leya Brasil, 2014.224 p.

Monografia Poli UFRJ - Case da Implantação de um pipeline de Entrega Contínua de Software em uma Empresa de Mídias

Monografia Poli UFRJ - Case da Implantação de um pipeline de Entrega Contínua de Software em uma Empresa de Mídias

More Decks by Samanta Cicilia

Featured

Transcript