TCC - AUTOMATIZAÇÃO DE ENTREGA DE SOFTWARE EM AMBIENTE ÁGIL DE DESENVOLVIMENTO

1.299 visualizações

Publicada em

Software, por mais complexo que seja, não gera lucro ou valor até que esteja nas mãos de seus usuários. Para inibir riscos com perda de oportunidades no universo web, a empresa objeto do estudo de caso deste trabalho evita os longos ciclos de desenvolvimento tradicionais adotando as metodologias ágeis, fazendo uso das práticas da XP, do Scrum e do Kanban. No entanto, durante o ciclo de desenvolvimento, a execução manual de tarefas importantes do processo de desenvolvimento associa-se diretamente com o não cumprimento de prazos e a baixa qualidade do software entregue. Diante desse cenário, este trabalho realiza uma pesquisa das boas práticas de desenvolvimento de software para efetuar a entrega contínua de valor ao cliente e propõe o desenvolvimento de um sistema para realizar a automatização dos processos com o auxílio de ferramentas testadas e validadas há décadas pela comunidade open source tais como Puppet, Git, Mina, Jenkins, RSpec e Cucumber. O processo de entrega é descrito através do padrão Pipeline de Implantação, permitindo a automatização desde o desenvolvimento até a entrega do software ao usuário final. O sistema desenvolvido tem o objetivo de permitir que a equipe de desenvolvimento responda às mudanças de forma eficiente, aumente a capacidade de gerar novas versões bem-sucedidas e de liberá-las sob demanda e de implantar o seu sistema em qualquer ambiente instantaneamente, refletindo as mudanças de uma forma eficiente e com baixo custo.

Publicada em: Software
0 comentários
3 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.299
No SlideShare
0
A partir de incorporações
0
Número de incorporações
28
Ações
Compartilhamentos
0
Downloads
54
Comentários
0
Gostaram
3
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

TCC - AUTOMATIZAÇÃO DE ENTREGA DE SOFTWARE EM AMBIENTE ÁGIL DE DESENVOLVIMENTO

  1. 1. FUNDAÇÃO DE ASSISTÊNCIA E EDUCAÇÃO – FAESA FACULDADES INTEGRADAS ESPÍRITO-SANTENSE CURSO DE GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO LEANDRO SOUZA NUNES AUTOMATIZAÇÃO DE ENTREGA DE SOFTWARE EM AMBIENTE ÁGIL DE DESENVOLVIMENTO VITÓRIA 2014
  2. 2. LEANDRO SOUZA NUNES AUTOMATIZAÇÃO DE ENTREGA DE SOFTWARE EM AMBIENTE ÁGIL DE DESENVOLVIMENTO Trabalho de Conclusão de Curso de Graduação em Ciência da Computação apresentado às Faculdades Integradas Espírito-santenses, como requisito parcial para obtenção do título de Bacharel em Ciência da Computação, sob orientação da profa . Denise Franzotti Togneri. VITÓRIA 2014
  3. 3. LEANDRO SOUZA NUNES Trabalho de Conclusão do Curso de Graduação em Ciências da Computação apresentado às Faculdades Integradas Espírito-santenses (FAESA), como requisito parcial para obtenção do título de Bacharel em Ciência da Computação. AUTOMATIZAÇÃO DE ENTREGA DE SOFTWARE EM AMBIENTE ÁGIL DE DESENVOLVIMENTO BANCA EXAMINADORA Denise Franzotti Togneri Orientadora Eliana Cáus Sampaio Daniel Barbosa Oliveira Vitória, 10 de dezembro de 2014
  4. 4. RESUMO Software, por mais complexo que seja, não gera lucro ou valor até que esteja nas mãos de seus usuários. Para inibir riscos com perda de oportunidades no universo web, a empresa objeto do estudo de caso deste trabalho evita os longos ciclos de desenvolvimento tradicionais adotando as metodologias ágeis, fazendo uso das práticas da XP, do Scrum e do Kanban. No entanto, durante o ciclo de desenvolvimento, a execução manual de tarefas importantes do processo de desenvolvimento associa-se diretamente com o não cumprimento de prazos e a baixa qualidade do software entregue. Diante desse cenário, este trabalho realiza uma pesquisa das boas práticas de desenvolvimento de software para efetuar a entrega contínua de valor ao cliente e propõe o desenvolvimento de um sistema para realizar a automatização dos processos com o auxílio de ferramentas testadas e validadas há décadas pela comunidade open source tais como Puppet, Git, Mina, Jenkins, RSpec e Cucumber. O processo de entrega é descrito através do padrão Pipeline de Implantação, permitindo a automatização desde o desenvolvimento até a entrega do software ao usuário final. O sistema desenvolvido tem o objetivo de permitir que a equipe de desenvolvimento responda às mudanças de forma eficiente, aumente a capacidade de gerar novas versões bem-sucedidas e de liberá-las sob demanda e de implantar o seu sistema em qualquer ambiente instantaneamente, refletindo as mudanças de uma forma eficiente e com baixo custo. Palavras-chave: Entrega Contínua de Software. Provisionamento de ambientes. Integração Contínua. Metodologias Ágeis. Pipeline de Implantação.
  5. 5. LISTA DE QUADROS   QUADRO 1 – REQUISITOS NÃO FUNCIONAIS.................................................................... 55 QUADRO 2 – FERRAMENTAS UTILIZADAS........................................................................ 60 QUADRO 3 – COMPARATIVO OVENBIRD X GO X TOOL CLOUD X TRELLO......................... 64 QUADRO 4 – DICIONÁRIO DE DADOS DO SISTEMA OVENBIRD............................................ 67 QUADRO 5 – DICIONÁRIO DE DADOS DO SISTEMA OVENBIRD............................................ 68
  6. 6. LISTA DE FIGURAS FIGURA 1 – AGRUPAMENTO DAS PRÁTICAS DA XP. ......................................................... 20 FIGURA 2 – FLUXO DE PROCESSO UTILIZANDO SCRUM.................................................... 22 FIGURA 3 – EXEMPLO DE UM GRÁFICO BURNDOWN CHAT................................................ 24 FIGURA 4 – EXEMPLO DE UM QUADRO KANBAN............................................................... 25 FIGURA 5 – EXEMPLO DE UM QUADRO KANBAN EM DESENVOLVIMENTO DE SOFTWARE....... 26 FIGURA 6 – DIAGRAMA DE UM SISTEMA DE VERSÃO LOCAL............................................... 27 FIGURA 7 – DIAGRAMA DE UM SISTEMA DE VERSÃO CENTRALIZADO.................................. 28 FIGURA 8 – DIAGRAMA DE UM SISTEMA DE VERSÃO DISTRIBUÍDO...................................... 29 FIGURA 9 – QUATRO QUADRANTE DE TESTES DESCRITOS POR BRIAN MARICK. ................. 32 FIGURA 10 – CICLO DO TDD......................................................................................... 34 FIGURA 11 – PROCESSO DE INTEGRAÇÃO CONTÍNUA COM O AUXILIO DE FERRAMENTAS..... 35 FIGURA 12 - UM EXEMPLO DE MAPA DE FLUXO DE VALOR SIMPLES PARA UM PRODUTO....... 37 FIGURA 13 - MUDANÇAS SE MOVENDO POR UM PIPELINE DE IMPLANTAÇÃO. ...................... 38 FIGURA 14 – EQUIPES ENVOLVIDAS NO MOVIMENTO DEVOPS.......................................... 41 FIGURA 15 - MAPA DO FLUXO DE VALOR DA EMPRESA OBJETO DESTE ESTUDO. ................. 44 FIGURA 16 – MOVIMENTAÇÃO ATUAL DAS SOLICITAÇÕES NO QUADRO KANBAN. ................ 45 FIGURA 17 - FLUXO DO GERENCIAMENTO DO SISTEMA PELOS DESENVOLVEDORES. ........... 46 FIGURA 18 - DIAGRAMA DE CASO DE USO PRINCIPAL. .................................................... 50 FIGURA 19 - DIAGRAMA DE CASO DE USO CADASTRARGERAL......................................... 51 FIGURA 20 - DIAGRAMA DE CASO DE USO GERENCIARAMBIENTES................................... 52 FIGURA 21 - DIAGRAMA DE CASO DE USO GERENCIARSOLICITACOES............................... 53 FIGURA 22 - UTILIZAÇÃO DO PUPPET PELO SISTEMA OVENBIRD....................................... 57 FIGURA 23 - QUADRO KANBAN NO SISTEMA OVENBIRD. .................................................. 59 FIGURA 24 - FLUXO DO GERENCIAMENTO DO SISTEMA PELOS DESENVOLVEDORES APÓS A APLICAÇÃO DAS SOLUÇÕES PROPOSTAS. ................................................................ 61 FIGURA 25 – TELA DO PIPELINE DE IMPLANTAÇÃO NA FERRAMENTA GO............................ 62 FIGURA 26 – PAINEL DE INSTALAÇÃO DA TOOLS CLOUD.................................................. 63 FIGURA 27 – QUADRO DO TRELLO................................................................................. 64 FIGURA 28 – DIAGRAMA DE CLASSES DE ANÁLISE – PARTE ESTÁTICA - DO SISTEMA OVENBIRD. ........................................................................................................... 66 FIGURA 29 – DIAGRAMA DE SEQUÊNCIA INCLUIRNOVOAMBIENTE..................................... 69 FIGURA 30 – DIAGRAMA DE SEQUÊNCIA CADASTRARPROJETO......................................... 69
  7. 7. FIGURA 31 – DIAGRAMA DE SEQUÊNCIA INCLUIRSOLICITACAO. ........................................ 70 FIGURA 32 – DIAGRAMA DE SEQUÊNCIA GERARNOVAIMPLANTAÇÃO................................. 70 FIGURA 33 – DIAGRAMA DE ESTADO DE CLASSE FUNCIONALIDADE. .................................. 71 FIGURA 34 – ARQUITETURA DE QUATRO CAMADAS DO SISTEMA OVENBIRD....................... 72 FIGURA 35 – PROJETO DA ARQUITETURA WEB............................................................... 74 FIGURA 36 – PROJETO DE NAVEGAÇÃO DO ATOR GERENTEPROJETOS............................. 75 FIGURA 37 – PROJETO DE NAVEGAÇÃO DO ATOR DESENVOLVEDOR................................. 75 FIGURA 38 – PROJETO DE NAVEGAÇÃO DO ATOR QUALIDADE.......................................... 75 FIGURA 39 – COMPONENTE DO DOMÍNIO DO PROBLEMA. ................................................ 77 FIGURA 40 – COMPONENTE DE GERÊNCIA DE TAREFA.................................................... 79 FIGURA 41 – DIAGRAMA RELACIONAL DE DADOS............................................................. 81 FIGURA 42 – TELA PARA VISUALIZAÇÃO DOS USUÁRIOS CADASTRADOS. ........................... 88 FIGURA 43 – TELA PARA CADASTRO DE USUÁRIOS.......................................................... 89 FIGURA 44 – TELA PARA VISUALIZAÇÃO DOS CLIENTES CADASTRADOS. ............................ 89 FIGURA 45 – TELA PARA CADASTRO DE CLIENTE............................................................. 90 FIGURA 46 – TELA PARA CADASTRO DE ESPECIALISTA..................................................... 90 FIGURA 47 – TELA PARA CADASTRO DE PROJETO. .......................................................... 91 FIGURA 48 – TELA PARA CADASTRO DE AMBIENTE. ......................................................... 92 FIGURA 49 – TELA PARA CADASTRO DE AMBIENTE. ......................................................... 92 FIGURA 50 – TELA DO PIPELINE DE IMPLANTAÇÃO........................................................... 93 FIGURA 52 – TELA PARA CADASTRO DE SOLICITAÇÃO...................................................... 94
  8. 8. LISTA DE SIGLAS CSS – Cascading Style Sheets CI – Continuous Integration CVS – Concurrent Versions System DSL – Domain-Specific Language ERB – Embedded Ruby SSH – Secure Shell UML – Unified Modeling Language HTML – Hyper Text Markup Language HTTPS – Hypertext Transfer Protocol Secure RCS – Revision Control System SCCS – Source Code Control System SGBD – Sistema de Gerenciamento de Banco de Dados SIC – Sistema de integração Contínua SQL – Structured Query Language TDD – Test Driven Development URL – Uniform Resource Locator VCS – Version Control System XP – Extreme Programming WEB – Wolrd Wide Web
  9. 9. SUMÁRIO 1. INTRODUÇÃO ...................................................................................................... 11 1.1 O PROBLEMA................................................................................................. 12 1.2 FORMULAÇÃO DO PROBLEMA ................................................................... 13 1.3 HIPÓTESE....................................................................................................... 13 1.4 OBJETIVOS..................................................................................................... 13 1.4.1 Gerais........................................................................................................ 13 1.4.2 Específicos ................................................................................................ 14 1.5 JUSTIFICATIVA .............................................................................................. 14 1.6 METODOLOGIA.............................................................................................. 15 1.7 ORGANIZAÇÃO DA MONOGRAFIA.............................................................. 15 2 METODOLOGIAS DE DESENVOLVIMENTO EM AMBIENTE ÁGIL ................... 16 2.1 MANIFESTO ÁGIL .......................................................................................... 16 2.2 EXTREME PROGRAMMING........................................................................... 18 2.2.1 Práticas da XP........................................................................................... 18 2.2.2 Adoção da XP............................................................................................ 20 2.3 SCRUM............................................................................................................ 21 2.3.1 Papéis e responsabilidades....................................................................... 23 2.3.2 Etapas da Sprint........................................................................................ 23 2.3.3 Artefatos .................................................................................................... 24 2.4 KANBAN.......................................................................................................... 25 2.4.1 Kanban no desenvolvimento de software.................................................. 25 2.5 SISTEMA DE CONTROLE DE VERSÃO....................................................... 26 2.5.1 Sistemas de Controle de Versão Locais ................................................... 27 2.5.2 Sistemas de Controle de Versão Centralizados........................................ 28 2.5.3 Sistemas de Controle de Versão Distribuídos........................................... 29 2.6 GERÊNCIA DE CONFIGURAÇÃO ................................................................. 30 2.6.1 Provisionamento........................................................................................ 31 2.7 TESTES AUTOMATIZADOS........................................................................... 32 2.7.1 Desenvolvimento guiado por testes .......................................................... 34 2.8 INTEGRAÇÃO CONTÍNUA............................................................................. 35 2.9 PIPELINE DE IMPLANTAÇÃO ....................................................................... 36 2.9.1 Como criar um pipeline de implantação inicial .......................................... 39
  10. 10. 2.9.2 Objetivos para utilização do pipeline......................................................... 40 2.10 MOVIMENTO DevOps .................................................................................. 41 3. UMA PROPOSTA PARA AUTOMATIZAÇÃO DE ENTREGA DE SOFTWARE 43 3.1 ESTUDO DE CASO......................................................................................... 43 3.1.1 Processos relacionados ao desenvolvimento ........................................... 45 3.1.2 Dificuldades encontradas no desenvolvimento ......................................... 47 3.2 REQUISITOS FUNCIONAIS............................................................................ 49 3.2.1 Caso de uso CadastrarGeral..................................................................... 50 3.2.2 Caso de uso GerenciarAmbientes............................................................. 51 3.2.3 Caso de Uso GerenciarSolicitacoes.......................................................... 53 3.3 REQUISITOS NÃO FUNCIONAIS................................................................... 55 3.4 PROPOSTA DE SOLUÇÃO............................................................................ 56 3.4.1 Proposta de solução para a Gerência de Ambientes................................ 56 3.4.2 Proposta de solução para a Gerência de Solicitações.............................. 58 3.5 TRABALHOS CORRELATOS ........................................................................ 61 3.5.1 Go Continuous Delivery............................................................................. 62 3.5.2 Tools Cloud ............................................................................................... 62 3.5.3 Trello.......................................................................................................... 63 3.5.4 Quadro Comparativo ................................................................................. 64 4. ANÁLISE ORIENTADA A OBJETOS................................................................... 65 4.1 DIAGRAMA DE CLASSES ............................................................................. 65 4.2 DICIONÁRIO DE DADOS................................................................................ 67 4.3 DIAGRAMAS DE SEQÜÊNCIA....................................................................... 68 4.4 DIAGRAMA DE ESTADO ............................................................................... 70 5. PROJETO E IMPLEMENTAÇÃO ......................................................................... 72 5.1 PROJETO........................................................................................................ 72 5.1.1 Projeto de arquitetura................................................................................ 72 5.1.2 Projeto de interface ................................................................................... 73 5.1.2.1 Projeto de arquitetura da aplicação web............................................. 73 5.1.2.2 Projeto de navegação......................................................................... 74 5.1.3 Projeto de componente ............................................................................. 76 5.1.3.1 Componente de Domínio do Problema (CDP).................................... 76 5.1.3.2 Componente de Interação Humana (CIH) .......................................... 78
  11. 11. 5.1.3.3 Componente de Gerência de Tarefa (CGT) ....................................... 78 5.1.3.4 Componente de Gerência de Dados (CGD)....................................... 80 5.1.4 Projeto relacional de dados....................................................................... 80 5.2 IMPLEMENTAÇÃO DO PROTÓTIPO............................................................. 81 5.2.1 Tecnologias utilizadas no protótipo ........................................................... 82 5.2.1.1 Ruby e RubyOnRails .......................................................................... 82 5.2.1.2 Cucumber ........................................................................................... 82 5.2.1.3 Git ....................................................................................................... 83 5.2.1.4 Jenkins................................................................................................ 84 5.2.1.5 Mina .................................................................................................... 84 5.2.1.6 MySQL................................................................................................ 84 5.2.1.7 Nginx................................................................................................... 85 5.2.1.8 Puma................................................................................................... 85 5.2.1.9 Puppet................................................................................................. 85 5.2.1.10 RSpec ............................................................................................... 86 5.2.1.11 Vagrant ............................................................................................. 86 5.3 RESTRIÇÕES DE IMPLEMENTAÇÃO........................................................... 87 5.4 INSTALAÇÃO E FUNCIONAMENTO DO PROTÓTIPO................................. 87 5.5 INTERFACE COM O USUÁRIO...................................................................... 88 6. CONCLUSÃO E PERSPECTIVAS FUTURAS ..................................................... 95 REFERÊNCIAS......................................................................................................... 98 ANEXOS.................................................................................................................. 100
  12. 12. 11 1. INTRODUÇÃO Com a globalização e o aumento ao acesso à banda larga, o mundo vive uma interação em tempo real. Ideias, tendências, necessidades, informações, dentre outros, navegam de continente a continente em uma velocidade jamais imaginada, tendo o software como parte fundamental desse processo. Desenvolver software nesse cenário requer um processo onde uma ideia na mente do cliente vire código funcional e esteja disponível para o usuário final de maneira rápida e confiável. O tempo para efetuar o processo de entrega de software pode determinar o rumo dos negócios diante da concorrência. Desde 1980, autores como Kent Beck, Martin Fowler, Paul Duvall, Ron Jeffries e Dave Thomas, estudam práticas de desenvolvimento de software com o objetivo de poder fornecer ao mundo alternativas melhores que as tradicionais, que são altamente dirigidas por documentação. Conforme os 12 princípios do Manifesto Ágil (2001), o software em funcionamento tem maior valor do que uma documentação abrangente e software funcional é a medida primária do progresso. Software que não esteja em produção, fazendo o que deveria fazer, não tem valor algum para o negócio. Humble e Farley (2014, p. 3) fazem três perguntas que permitem ter um enfoque em aspectos do ciclo de vida de um software que, segundo eles, normalmente são vistos como secundários: O que acontece depois da identificação dos requisitos, projeto, desenvolvimento e teste das soluções? Como unir e coordenar todas essas atividades para tornar o processo tão eficiente e confiável quanto possível durante sua execução? Como fazer desenvolvedores, testadores e pessoal de operação trabalharem juntos de maneira eficiente? O objetivo da automatização de processos é tornar a entrega de software confiável, previsível, com riscos quantificáveis e bem entendidos, garantindo que quando for preciso fazer alguma modificação, o tempo para realizá-las, colocá-las em produção e em uso, seja o menor possível e, que problemas sejam encontrados cedo o bastante para que sejam fáceis de corrigir. Isso permite que todos os envolvidos possam executar tarefas (que até então são manuais) de forma eficiente e repetível, melhorando a produtividade e a quantidade das entregas de valor dentro de um ciclo
  13. 13. 12 de desenvolvimento e permitindo implantar o sistema para qualquer ambiente instantaneamente, refletindo as mudanças de uma forma eficiente e com baixo custo. 1.1 O PROBLEMA Uma empresa sediada em Vitória ES é especializada em soluções para lojas virtuais (SLV) que são o ponto de partida para o atendimento de um novo cliente. Para inibir riscos com perda de oportunidades no universo web, a empresa evita os longos ciclos de desenvolvimento tradicionais adotando as metodologias ágeis, fazendo uso das práticas da XP, do Scrum e do Kanban. No entanto, durante o ciclo de desenvolvimento a execução manual de tarefas importantes do processo de desenvolvimento associa-se diretamente com o não cumprimento de prazos e a baixa qualidade do software entregue. A forma como os processos relacionados ao desenvolvimento de software são executados pela equipe não permite o atendimento das solicitações dos clientes de maneira satisfatória. Diversos problemas ocorrem durante o desenvolvimento, tais como: os desenvolvedores codificam as funcionalidades em seus ambientes de desenvolvimento paralelamente, mas não há controle sobre as versões das ferramentas utilizadas e os testes automatizados são executados várias vezes ao dia no próprio computador do desenvolvedor, deixando-o sem poder continuar trabalhando em outras atividades por um período de 15 min a cada execução. No término do ciclo de desenvolvimento, o sistema terá uma versão disponibilizada para o usuário final em outro ambiente. O processo de levar o código do repositório até o usuário é demorado e possibilita a presença de erros se cada passo não for executado perfeitamente; Implantar novos códigos ao sistema da loja já em funcionamento é extremamente crítico e erros podem ser incluídos gerando perda financeira aos negócios. Em muitos casos, é preciso esperar a próxima madrugada para fazer a junção da funcionalidade que já está pronta.
  14. 14. 13 1.2 FORMULAÇÃO DO PROBLEMA Como coordenar atividades relacionadas com a entrega de software, tais como a integração de código, a criação de ambientes, a implantação do sistema e a validação e verificação dos requisitos, para permitir que processos complexos sejam executados de forma confiável e repetível através da colaboração de todos os envolvidos no processo de desenvolvimento? 1.3 HIPÓTESE Para apoiar a solução dos problemas levantados, uma proposta de solução é o desenvolvimento de uma ferramenta que permita a utilização de práticas de desenvolvimento de software incluídas nas metodologias ágeis, objetivando otimizar o processo de entrega de software de valor ao cliente e o desenvolvimento de software coeso mais rapidamente. O sistema proposto baseia-se no padrão Pipeline de Implantação para automatizar o fluxo do desenvolvimento de software até a sua entrega, realizando para isso, a integração de ferramentas já existentes no mercado. Dessa forma, as atividades de toda equipe de desenvolvimento seria centralizada, dando uma visão do estado atual do sistema a todos os envolvidos e fomentando as práticas do movimento DevOps 1 para criar um relacionamento colaborativo entre as equipes de desenvolvimento, qualidade, operações e o próprio cliente. 1.4 OBJETIVOS 1.4.1 Gerais Construir um software capaz de integrar ferramentas, técnicas e boas práticas que possam ajudar a implementar um padrão passível de automatização para o desenvolvimento de sistemas web, melhorando com isso o feedback de modo que os problemas sejam identificados e resolvidos o mais cedo possível, proporcionando a redução do custo de desenvolvimento e fazendo com que a entrega do software seja de maneira confiável e repetível. 1 DevOps é um movimento que busca difundir a colaboração entre os envolvidos no desenvolvimento de software e será abordado na seção 2.10.
  15. 15. 14 1.4.2 Específicos • Investigar o fluxo de desenvolvimento de software para a elaboração de uma pipeline de implantação; • Investigar a integração de ferramentas para automatizar os processos de entrega de software; • Possibilitar a comunicação entre cliente e equipe de desenvolvimento continuamente; • Permitir a integração contínua de código de forma automatizada, reduzindo o desperdício de homem-hora; • Possibilitar a execução do sistema durante o processo de desenvolvimento em ambientes similares ao servidor de hospedagem; • Realizar o gerenciamento de configurações e dependências; • Desenvolver um sistema online para que todos os envolvidos possam efetuar suas atividades de forma simples, rápida e confiável. 1.5 JUSTIFICATIVA Software escrito que não é entregue ao cliente não tem valor algum, mesmo que seja uma aplicação das mais complexas que se pode codificar. A automação de implantações permite que novas entregas sejam feitas ou revertidas com o apertar de um botão. Práticas tais como utilizar o mesmo processo de implantação em cada ambiente e automatizar a gestão de ambientes, de dados e da infraestrutura são projetadas para garantir que o processo de entrega seja excessivamente testado, que a possibilidade de erro humano seja minimizada e que quaisquer problemas (sejam funcionais, não funcionais ou de configuração) sejam descobertos muitos antes de uma entrega (HUMBLE; FARLEY, 2014, p. 422). Com o desenvolvimento de um software para a integração de ferramentas, automatizam-se os processos de forma que todos os envolvidos possam executar tarefas (que até então são manuais) com facilidade, aumentando a produtividade e a quantidade de entregas de valor dentro de um ciclo, sendo possível instalar o sistema em qualquer ambiente instantaneamente, refletindo as mudanças para a equipe de testes e o cliente de uma forma eficiente e com baixo custo.
  16. 16. 15 1.6 METODOLOGIA Inicialmente será feita uma revisão bibliográfica sobre as práticas de desenvolvimento inclusas nas metodologias ágeis, e do pipeline de implantação para mapear os processos relacionados com a entrega de software. Em sequência, um estudo sobre as ferramentas de apoio será realizado, efetuando a integração entre elas. Com isso, serão levantados os requisitos, documentando-os através de casos de uso para modelar a ferramenta proposta. A análise e o projeto serão feitos utilizando-se o paradigma da orientação a objetos e seu protótipo será construído utilizando-se a linguagem de programação Ruby. 1.7 ORGANIZAÇÃO DA MONOGRAFIA Este trabalho contém, além desta Introdução, mais 5 capítulos. O capítulo 2 – METODOLOGIAS DE DESENVOLVIMENTO EM AMBIENTE ÁGIL – apresenta uma visão geral das metodologias ágeis e das práticas de desenvolvimento essenciais para o desenvolvimento deste trabalho. O capítulo 3 – PROPOSTA PARA AUTOMATIZAÇÃO DE ENTREGA DE SOFTWARE – apresenta o estudo de caso e descreve os requisitos funcionais da ferramenta a ser contruída através de casos de uso. O capítulo 4 – ANÁLISE ORIENTADA A OBJETOS – apresenta a análise orientada a objetos da ferramenta proposta. O capítulo 5 – PROJETO E IMPLEMENTAÇÃO – mostra como será projetada e implementada a ferramenta proposta. O capítulo 6 – CONCLUSÃO PERSPECTIVAS FUTURAS – onde são apresentadas as conclusões e perspectivas futuras do trabalho.
  17. 17. 16 2 METODOLOGIAS DE DESENVOLVIMENTO EM AMBIENTE ÁGIL Este capítulo contextualiza o surgimento das metodologias ágeis utilizadas em ambiente de desenvolvimento de software, abordando suas principais características e princípios que proporcionaram sua adoção por diversas empresas nos últimos anos. Um conjunto de boas práticas de desenvolvimento testadas e validadas por diversos autores são analisadas, com o objetivo de permitir efetuar a entrega de software com maior qualidade em um curto período e promover a comunicação com um ciclo de feedback constante entre todos os interessados. 2.1 MANIFESTO ÁGIL Em 2001, 17 pensadores de desenvolvimento de software, dentre eles: Martin Fowler, Kent Beck, Kent Schwaber, Ron Jeffries e Dave Thomas, se reuniram para que cada um explicasse como desenvolviam seus projetos de software, tendo como objetivo, fornecer ao mundo uma alternativa às metodologias pesadas e altamente dirigidas por documentação (LOPES, 2012, p. 16). Segundo Pressman (2006, p. 58), em essência, os métodos ágeis foram desenvolvidos em um esforço para vencer as fraquezas percebidas e reais da Engenharia de Software convencional. Embora cada envolvido tivesse suas próprias práticas e teorias sobre como fazer um projeto de software ter sucesso, cada qual com as suas particularidades, todos concordavam que, em suas experiências prévias, um pequeno conjunto de princípios sempre parecia ter sido respeitado quando os projetos davam certo. Com base nesses princípios surgiu o Manifesto Ágil (2001). Ele valoriza a importância da interação entre os envolvidos e a entrega de software de valor ao cliente a curto prazo. Os quatro valores defendidos pelo manifesto ágil são: • Indivíduos e interações mais que processos e ferramentas; • Software em funcionamento mais que documentação abrangente; • Colaboração com o cliente mais que negociação de contratos; • Responder a mudanças mais que seguir um plano.
  18. 18. 17 Os processos ágeis de desenvolvimento de software compartilham um conjunto de premissas fundamentais que diferem daquelas adotadas pelos processos tradicionais de desenvolvimento. Fowler (2005) descreve que a maioria dos projetos de software conta com três suposições chave que são justamente o que o processo ágil de desenvolvimento visa atender: • É difícil prever antecipadamente quais requisitos de software vão persistir e quais serão modificados e como as prioridades do cliente serão modificadas durante o desenvolvimento do projeto. • Para muitos tipos de software, o projeto e a construção são intercalados, ou seja, as duas atividades devem ser realizadas juntas de modo que os modelos de projeto sejam comprovados à medida que são criados. É difícil prever o quanto de projeto é necessário antes que a construção seja usada para comprovar o projeto. • Análise, projeto, construção e testes não são tão previsíveis (do ponto de vista do planejamento) como gostaríamos. Pressman (2006, p. 61) levanta uma questão importante a partir das suposições: como criar um processo que possa gerenciar a imprevisibilidade? A resposta, como afirma Pressman, está na adaptabilidade do processo (as modificações rápidas do projeto e das condições técnicas). Um processo ágil, portando, deve ser adaptável. A implementação de metodologias ágeis proporciona o desenvolvimento cooperativo, que se baseia mais nas pessoas e suas iterações em vez de grandes esforços de planejamento e processo rígidos. Essas iterações permitem a visualização contínua do desenvolvimento e o direcionamento do projeto para atender seu propósito. Existem diversas metodologias ágeis de processo tais como a Extreme Programming (XP), o Scrum e o Kanban que serão apresentadas a seguir.
  19. 19. 18 2.2 EXTREME PROGRAMMING A XP foi uma das primeiras metodologias ágeis que revolucionou a forma como software era desenvolvido (SATO, 2013, p. 116), diferenciando da forma tradicional de desenvolvimento de software. Foi proposta por Kent Beck e publicada em seu livro Extreme Programming Explained em 1999. Kent Beck definiu os valores, princípios e práticas da metodologia, direcionando seus objetivos para a alta qualidade no desenvolvimento de software, adaptando-os a requisitos vagos ou em constante mudança. A XP engloba práticas de engenharia ágil alinhadas de tal forma a criar uma interdependência entre elas, sendo diretamente ligadas à qualidade do software, tais práticas como: refatoração, desenvolvimento guiado por testes, propriedade coletiva de código, design incremental, programação em pares, padrões de código e integração contínua. Segundo Teles (2006), a XP se baseia em cinco valores fundamentais para guiar o desenvolvimento: Comunicação, simplicidade, feedback, coragem e respeito. 2.2.1 Práticas da XP Práticas em XP representam aquilo que as equipes XP estão fazendo diariamente e sua aplicação depende do contexto. Segundo Teles (2004, p. 28), as práticas XP podem ser representadas da seguinte forma: • Jogo de Planejamento: nesta prática existe uma grande interação entre o cliente e a equipe, visando assegurar que se esteja trabalhando naquilo que é o mais importante para o cliente. Os programadores estimam o esforço necessário para implementar as histórias possibilitando conhecer o custo da implementação e o cliente decide sobre o escopo e a duração das iterações; • Releases Curtos: um incremento simples e funcional é gerado rapidamente de modo que o cliente já possa utilizar o software e se beneficiar dele. Desta forma, é possível gerar um fluxo contínuo de valor, incorporar mudanças e corrigir o produto em tempo hábil; • Metáfora: é elaborada uma descrição para permitir que todos os envolvidos no projeto consigam explicar como o sistema funciona. Ela auxilia os
  20. 20. 19 envolvidos a compreender os elementos básicos do sistema e seus relacionamentos, criando um vocabulário comum para o projeto; • Projeto Simples: o sistema deve ser projetado da forma mais simples, de modo a atender às necessidades da funcionalidade que se está implementando; • Desenvolvimento Guiado por Testes: o desenvolvimento do software de qualidade leva à necessidade de ter diversos mecanismos de validação para assegurar que esteja correto. A XP também utiliza a técnica de desenvolvimento guiado por testes (Test Driven Development ou TDD), sendo descrita com mais detalhes na seção 2.7. • Refatoração: é o ato de alterar um código sem afetar a funcionalidade que ele implementa. Isso permite a melhoria do sistema através da remoção de duplicações de código, otimização da comunicação, simplificação e flexibilidade; • Programação em Par: dois programadores escrevem o código em um único computador, permitindo uma revisão permanente, feedbacks e uma implementação mais simples e eficaz; • Código Coletivo: qualquer programador pode alterar qualquer parte do código em qualquer lugar do sistema a qualquer momento; • Integração Contínua: uma nova funcionalidade pode afetar outras que já estejam implementadas. Para garantir que o sistema esteja sempre funcionando, a prática de integração contínua (Continuous Integration ou CI) conduz os desenvolvedores a integrarem seus códigos com o restante do sistema diversas vezes ao dia. Essa prática será abordada na seção 2.8; • Cliente Presente: a XP trabalha com a premissa que o cliente deve conduzir o desenvolvimento a partir do feedback que recebe do sistema. Um usuário deve participar ativamente no processo de desenvolvimento junto à equipe de programadores. A sua presença viabiliza a simplicidade do processo em diversos aspectos, especialmente na comunicação; • Código Padronizado: os programadores escrevem todo o código de acordo com regras que enfatizam a comunicação durante a codificação. Antes do início do projeto deve ser definido um padrão que deverá ser seguido por toda a equipe de programadores.
  21. 21. 20 • Ritmo Sustentável: a qualidade do design, do código, das metáforas e do sistema é determinada pela qualidade dos desenvolvedores e a capacidade que eles têm de se manter atentos, criativos e dispostos a solucionar problemas. A XP recomenda que os desenvolvedores trabalhem oito horas por dia, que estejam descansados a cada manha de modo a utilizar a mente na sua plenitude. A Figura 1 permite uma visualização do agrupamento das práticas aplicadas com a adoção da XP onde as práticas no círculo vermelho estão relacionadas com os requisitos, no círculo verde, são práticas relacionadas com a qualidade do sistema desenvolvido e no círculo azul, prática relacionadas com o desenvolvimento, a codificação do sistemas. Figura 1 – Agrupamento das práticas da XP. Fonte: http://www.hiflex.com.br/v1/2014/07/scrum-sustenta-se-sozinho 2.2.2 Adoção da XP Segundo Teles (2004, p. 21), a XP é uma metodologia ágil voltada para projetos cujos requisitos são vagos e mudam com frequência, desenvolvimento de sistemas orientados a objetos, equipes pequenas, preferencialmente até 12 desenvolvedores e desenvolvimento incremental (ou iterativo), onde o sistema começa a ser
  22. 22. 21 implementado logo no início do projeto e vai ganhando novas funcionalidades ao longo do tempo. Segundo Astels, Miller e Novak (2002, p. 181), a melhor maneira de adotar a XP é utilizá-la em organizações recém-formadas, quando ainda não existe um modo pré- concebido de desenvolvimento de software. São necessários desenvolvedores experientes, porque eles entendem como entregar projetos e podem ajudar os novatos a entenderem esse importante princípio. Mas essa não é a única maneira: algumas organizações levam a XP para suas equipes que entra em operação de forma transparente. Os desenvolvedores já podem estar utilizando as práticas da XP no processo existente e eles simplesmente mudam sua forma de pensar sobre desenvolvimento de software que suporte a XP. A barreira cultural precisa ser vencida e os benefícios que a XP poderá trazer precisam ficar evidentes. Astels, Miller e Novak (2002, p. 182), descrevem que uma outra maneira de adotar a XP é experimentá-la na sua forma básica e ir descobrindo maneiras de adaptá-la e melhorá-la para que os seus princípios possam complementar o processo existente. 2.3 SCRUM O Scrum teve sua definição em 1995 por Ken Schwaber, com o objetivo de consolidá-lo como um método de desenvolvimento de software. No entanto, o termo Scrum foi utilizado pela primeira vez para o desenvolvimento de software por Jeff Sutherland em 1991. Segundo Schwaber K. (2004), citado por Varaschim (2009, p. 2), o Scrum é um modelo aberto e de forma alguma é previsível. Ele oferece um conjunto de práticas que tem como objetivo manter o gerenciamento do projeto visível aos usuários do modelo. A metodologia não detalha o que deve ser feito e não resolve os problemas da empresa. O objetivo do Scrum é dar visibilidade a estes problemas e servir como guia na resolução dos mesmos. De acordo com Pressman (2006, p. 69), a metodologia Scrum é utilizada para guiar as atividades de desenvolvimento dentro de um processo que incorpora as atividades de requisitos, análise, projeto, evolução e entrega. A Figura 2 ilustra o fluxo de processo utilizando Scrum.
  23. 23. 22 Figura 2 – Fluxo de processo utilizando Scrum. Fonte: http://calvinx.com/2014/05/22/why-scrum-why-agile-development/ Varaschim (2009, p. 3) descreve o ciclo de desenvolvimento onde a primeira etapa dentro da Sprint é a reunião de planejamento (Sprint Planning). Nela, o time (Scrum Team), em conjunto com o cliente (Product Owner), definem o que será implementado na iteração (Sprint Backlog), sendo responsabilidade do cliente realizar a priorização do trabalho a ser feito. A próxima etapa é a de execução, onde o time detalha as tarefas necessárias para implementar o que foi solicitado pelo cliente e posteriormente inicia a execução das mesmas. Durante a Sprint o time realiza reuniões diárias (Daily Meeting) com não mais de 15 minutos, para averiguar o acompanhamento do progresso do desenvolvimento, usando para isto, o BurnDown Chart, um gráfico usado para o acompanhamento das tarefas a realizar, em andamento e já realizadas. Ao final do Sprint é realizada uma reunião para a validação da entrega (Sprint Review), onde o cliente e quem mais tiver interesse no produto podem verificar se o objetivo da Sprint foi atingido. Logo após, é realizada uma reunião apenas pelo time (Sprint Retrospective), onde a Sprint é avaliada sob a perspectiva de processo, time ou produto. Relatam quais foram os acertos e os erros com o objetivo de melhorar o processo de trabalho. Ao invés de um grande grupo gastando um monte de tempo construindo uma grande coisa, tem-se uma equipe pequena gastando um tempo curto construindo uma pequena coisa, mas integrando regularmente para ver o todo (KNINGERG; SKARIN,
  24. 24. 23 2009, p. 24). Empresas com projetos que possuem altas taxas de mudanças se beneficiarão com as práticas do Scrum. A seguir serão descritos resumidamente os papéis, as etapas da Sprint e os artefatos que compõem o Scrum. 2.3.1 Papéis e responsabilidades Os papéis e responsabilidades associados ao Scrum são: • Scrum Master: atua como facilitador do Daily Meeting e torna-se responsável por remover quaisquer obstáculos que sejam levantados pela equipe durante essas reuniões; • Scrum Team: é a equipe de desenvolvimento. É responsável por atingir os objetivos da Sprint, mostrando os resultados do trabalho para o cliente; • Product Owner: é o cliente de um time Scrum, sendo responsável pelo retorno do investimento de um produto. A responsabilidade pela qualidade do produto é do time, que tem o dever de verificar se suas práticas de desenvolvimento são compatíveis com as necessidades de qualidade e disponibilidade da aplicação. 2.3.2 Etapas da Sprint Segundo Ken Schwaber citado por Varaschim (2009, p. 5), a Sprint é definida como um ciclo de desenvolvimento curto em que o time foca em atingir o objetivo proposto pelo Product Owner e ao término, tem-se uma nova versão do sistema. Durante este período o time realiza diversas atividades: • Sprint Planning: é a primeira atividade dentro de uma Sprint; é uma reunião na qual estão presentes o Product Owner, o Scrum Master e todo o Scrum Team, bem como qualquer pessoa interessada que esteja representando a gerência ou o cliente. Coletivamente, o Scrum Team e o Product Owner definem um objetivo para a Sprint, que é uma breve descrição daquilo que se tentará alcançar. O Sprint Planning geralmente é feito em um dia, mas de acordo com o tamanho da Sprint, este tempo pode variar; • Daily Meeting: reunião diária realizada pela equipe a cada dia da Sprint, que tem como objetivo disseminar conhecimento sobre o que foi feito no dia
  25. 25. 24 anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia; • Sprint Review: realizada ao final de cada Sprint para que o Scrum Team mostre o que foi alcançado e o Product Owner verifica se as condições estabelecidas foram satisfeitas. • Sprint Restrospective: ocorre ao final de uma Sprint e tem como principal foco o time. Serve para identificar o que funcionou bem, o que pode ser melhorado e que ações serão tomadas para melhorar. 2.3.3 Artefatos Os artefatos gerados pelo SCRUM são (VARASCHIM, 2009, p. 9): • Product Backlog: é a lista que contem as funcionalidades de negócio, os requisitos técnicos e os erros encontrados no sistema que precisam ser corrigidos; • Sprint Backlog: é gerado a partir das estórias retiradas do Product Backlog e que serão implementadas durante a Sprint; • Burndown Chat: a equipe monitora seu progresso a partir da informação das tarefas realizadas no dia anterior atualizando um Burndown Chart, como mostra a Figura 3. O gráfico indica a completude de tarefas do Sprint e seu andamento em comparação com o número de tarefas planejadas. O eixo horizontal mostra o período em dias corridos; o eixo vertical mostra a quantidade de trabalho que precisa ser feita no início de cada Sprint. Figura 3 – Exemplo de um gráfico Burndown Chat. Fonte: http://www.brq.com/metodologias-ageis/
  26. 26. 25 Além do Burndown, pode-se utilizar para o acompanhamento de tarefas um quadro visual onde as tarefas são divididas em “a realizar”, “em andamento” e “já realizadas”. O Kanban será abordado na próxima seção. 2.4 KANBAN Kanban é um termo de origem japonesa e significa literalmente “cartão”. É um sinal visual com conceitos relacionados com cartões (post-it e outros) para indicar o andamento do fluxo de produção em empresas de fabricação em série. Tipicamente usa-se um quadro em branco com post-its (Quadro Kanban), próximo ao estoque de peças no setor de produção, conforme Figura 4. Figura 4 – Exemplo de um quadro Kanban. Fonte: http://www.viso.com.br/produto/kanban-kanb-03-C149000.html A transparência que isso gera também contribui para a mudança cultural. O Kanban expõe gargalos, filas, variabilidade e desperdício, tudo que impacta o desempenho da organização em termos de quantidade de trabalho de valor entregue e o tempo de ciclo (tempo médio para executar um item) necessário para entregá-lo. Segundo Anderson D. citado por Kningerg e Skarin (2009, p. 11), os primeiros estudos de caso mostraram que o Kanban muda o comportamento e incentiva uma maior colaboração no trabalho. A utilização de um sistema Kanban permite um controle detalhado de produção com informações sobre quando, quanto e o que produzir (AGUIAR; PEINADO, 2007, p. 138). 2.4.1 Kanban no desenvolvimento de software Segundo Anderson D. citado por Kningerg e Skarin (2009, p. 10), o Kanban é uma abordagem para introduzir mudanças em um ciclo de desenvolvimento de software
  27. 27. 26 ou metodologia de gerenciamento de projetos. O entendimento do processo se dá ao mapear o fluxo de valor conforme a Figura 5 e ao concordar em limitar as atividades em andamento (Work-In-Progress ou WIP). Atualmente, o Kanban é muitas vezes usado em conjunto com o Scrum, porque são duas metodologias usadas no desenvolvimento ágil de software. Figura 5 – Exemplo de um quadro Kanban em desenvolvimento de software. Fonte: http://tatihelo.wordpress.com/2011/10/03/kanban/ Kningerg e Skarin (2009, p. 11) descrevem a seguinte forma de implantar o Kanban: • Visualize o fluxo de trabalho. Divida o trabalho em partes, escreva cada item em um cartão e coloque na parede e use colunas nomeadas para ilustrar onde cada item está no fluxo de trabalho; • Limite o trabalho em progresso (WIP). Associe limites explícitos para quantos itens podem estar em progresso a cada estado do fluxo de trabalho; • Acompanhe o tempo de execução da tarefa. Otimize o processo para tornar o tempo de execução o menor e mais previsível possível. 2.5 SISTEMA DE CONTROLE DE VERSÃO Sistemas de controle de versão (VCS – version control system) são um mecanismo de guardar múltiplas versões de arquivos, de modo que, quando se modifica um deles, ainda é possível ter acesso às versões anteriores (HUMBLE; FARLEY, 2013, p. 32). Para Chacon e Straub (2014, p. 13), sistemas de controle de versão são sistemas que registram as mudanças feitas em um arquivo ou em um conjunto de arquivos ao longo do tempo de forma que se possa recuperar versões específicas.
  28. 28. 27 Um VCS permite reverter arquivos ou um projeto inteiro para um estado anterior, comparar mudanças feitas ao decorrer do tempo, ver quem foi o último a modificar algo que pode estar causando problemas, saber quem e quando um erro foi introduzido. Segundo Humble e Farley (2014, p. 33), ele tem basicamente dois objetivos. Em primeiro lugar, ele deve guardar cada versão de cada arquivo armazenado nele e garantir acesso a ela. Em segundo lugar, ele permite que equipes distribuídas no tempo e no espaço colaborem. Existem três maneiras de efetuar o gerenciamento de versões, que serão apresentadas a seguir. 2.5.1 Sistemas de Controle de Versão Locais Alguns programadores desenvolveram há muito tempo VCSs locais que armazenavam todas as alterações dos arquivos, conforme o diagrama da Figura 6. Figura 6 – Diagrama de um sistema de versão local. Fonte: http://git-scm.com/book/pt-br/v1/Primeiros-passos-Sobre-Controle-de-Versão. Basicamente, essa ferramenta mantém conjuntos de patches (ou seja, as diferenças entre os arquivos) entre cada mudança em um formato especial; a partir daí qualquer arquivo em qualquer ponto na linha do tempo pode ser recriado ao juntar- se todos os patches.
  29. 29. 28 2.5.2 Sistemas de Controle de Versão Centralizados Quando se trabalha em conjunto com outros desenvolvedores surge a necessidade de compartilhar o que está sendo criado. Para lidar com isso, foram desenvolvidos Sistemas de Controle de Versão Centralizados (CVCS - Centralized Version Control System). Esses sistemas, como por exemplo o CVS, Subversion e Perforce, possuem um único servidor central que contém todos os arquivos versionados e vários clientes que podem resgatar (check-out) os arquivos do servidor. A Figura 7 apresenta o diagrama desse sistema. Figura 7 – Diagrama de um sistema de versão centralizado. Fonte: http://git-scm.com/book/pt-br/v1/Primeiros-passos-Sobre-Controle-de-Versão O diagrama demonstra algumas vantagens, especialmente sobre VCSs locais. Por exemplo: todos podem ter conhecimento razoável sobre o que os outros desenvolvedores estão fazendo no projeto; Administradores têm controle específico sobre quem faz o quê; e é bem mais fácil administrar um CVCS do que lidar com bancos de dados locais em cada cliente. Uma desvantagem é que o servidor central é um ponto único de falha. Se ele ficar fora do ar por uma hora, ninguém pode trabalhar em conjunto ou salvar novas versões dos arquivos durante esse período.
  30. 30. 29 2.5.3 Sistemas de Controle de Versão Distribuídos Em um Sistema de Controle de Versão Distribuído (DVCS - Distributed Version Control System), os clientes não apenas fazem cópias das últimas versões dos arquivos mas eles são cópias completas do repositório. Assim, se um servidor falhar, qualquer um dos repositórios com os desenvolvedores podem ser copiados de volta para o servidor para restaurá-lo. Cada check-out é na prática um backup completo de todos os dados, conforme a Figura 8. Figura 8 – Diagrama de um sistema de versão distribuído. Fonte: http://git-scm.com/book/pt-br/v1/Primeiros-passos-Sobre-Controle-de-Versão Muitos desses sistemas lidam muito bem com o aspecto de ter vários repositórios remotos com os quais se pode colaborar, permitindo que se trabalhe em conjunto com diferentes grupos de pessoas, de diversas maneiras, simultaneamente no mesmo projeto. Isso permite estabelecer diferentes tipos de fluxo de trabalho que não são possíveis em sistemas centralizados, como por exemplo o uso de modelos hierárquicos.
  31. 31. 30 2.6 GERÊNCIA DE CONFIGURAÇÃO A estratégia de gerência de configuração determina a forma de como o time de desenvolvimento colabora pois ela registra a evolução de seus sistemas e aplicações. Entende-se por configuração o estado em que um sistema se encontra em um determinado momento. As configurações variam com o tempo de acordo com as atualizações e correções do ambiente e do sistema. Segundo Humble e Farley (2014, p. 280), neste contexto o ambiente é um conjunto de recursos que a aplicação precisa para funcionar. A gerência de configurações trata os elementos como um todo, incluindo o hardware necessário para a manutenção do sistema e permite organizar todos os elementos de forma a saber em qual estado o sistema se encontrava nos momentos chave do desenvolvimento. Conforme Humble e Farley (2014, p. 31), utilizar um sistema de controle de versão é apenas o primeiro passo para gerência de configuração, uma vez que é preciso dar uma resposta afirmativa as seguintes questões: (1) é possível reproduzir exatamente qualquer um dos ambientes? (2) É possível efetuar mudanças incrementais nesses itens individuais e implantá-las em quaisquer dos ambientes ou em todos eles? (3) É possível identificar facilmente quais foram as mudanças ocorridas para um ambiente específico e rastreá-las para ver quando, por que e para quem as mudanças foram feitas? (4) É possível satisfazer todos os requisitos de conformidade à regulamentação aos quais se está sujeito? (5) qualquer membro da equipe pode facilmente obter a informação de que precisa e fazer as mudanças que precisam ser feitas? Cada uma dessas perguntas corresponde a uma das atividades realizadas pela gerência de configuração para permitir manter a consistência e a integridade do software com as especificações. Diante disso, é importante guardar toda a informação requerida para recriar os ambientes no controle de versão; isso inclui arquivos de DNS, scripts de banco de dados, arquivos de compilação e implantação, documentação, bibliotecas e arquivos de configuração para a aplicação e todas as ferramentas relacionadas, e assim por diante, de modo que um novo membro da equipe possa começar do zero a partir de um único ponto.
  32. 32. 31 2.6.1 Provisionamento No caso dos servidores de redes de computadores, o processo de provisionamento é um conjunto de passos executáveis que podem ser aplicados em uma imagem inicial do sistema operacional para se ter tudo configurado corretamente (TAVARES, 2013). Esse conjunto de passos traz como benefícios a repetibilidade de gerar um estado adequado do ambiente e uma documentação executável dos procedimentos para configuração. Martin Fowler chama os servidores que dependem da ação humana de tentativa e erro para provisionar de SnowflakeServer 2 , Essas máquinas geralmente não possuem backup e, se houver alguma falha de disco, muito trabalho é exigido para colocar o projeto rodando em um computador novo. Para Humble e Farley (2014, p. 290), o provisionamento de servidores começa quando a nova máquina é colocada em um datacenter, ligada à alimentação e à rede; a partir deste ponto, praticamente todo o restante do seu ciclo de vida pode ser feito remotamente por meio de automação. Hoje, existe uma série de ferramentas para provisionar uma máquina, cada uma delas com seus diferentes benefícios e peculiaridades. Dentre as mais populares, destacam-se: • Chef (http://www.opscode.com/chef); • Puppet (http://puppetlabs.com/puppet); • Ansible (http://www.ansibleworks.com/tech/); • Salt (http://saltstack.com/). Todas elas estão contribuindo para a evolução da comunidade DevOps (veja seção 2.10), e, apesar de competirem entre si, seu maior adversário ainda é a falta de uso pelas empresas. Sato (2013, p.60) relata uma característica importante que essas ferramentas especializadas possuem, a idempotência. A idempotência permite executar o código diversas vezes seguidas e as ferramentas só mudarão o que for necessário. Se um 2 Acesse http://martinfowler.com/bliki/SnowflakeServer.html para mais detalhes sobre Snowflake Server.
  33. 33. 32 pacote estiver instalado, ele não será reinstalado. Se um serviço está iniciado, ele não será reiniciado. Diferentemente dos scripts proprietários que só funcionam para instalar e configurar o servidor pela primeira vez. 2.7 TESTES AUTOMATIZADOS Muitos projetos contam com apenas testes manuais para a verificação da conformidade dos seus requisitos funcionais e não funcionais. Desenvolver software é uma atividade complexa que envolve manipular uma grande quantidade de elementos abstratos (TELES, 2004, p. 104). Enquanto codificam, desenvolvedores tendem a verificar o programa, mas é comum aparecer erros devido a situações completamente imprevistas ou devido a erros de lógica, falta de atenção, interpretação incorreta de requisitos e, como consequência, a ocorrência de defeitos é uma realidade, sendo difícil ou impossível evitar que aconteçam durante o projeto. Existem diversos tipos de teste que podem ser automatizados para garantir a entrega de software com alta qualidade. Conforme Sato (2013, p.120), não existe uma classificação ou terminologia amplamente aceita na indústria, mas a comunidade ágil geralmente se refere aos quatro quadrantes da Figura 9, descritos por Brian Marick. Figura 9 – Quatro quadrante de testes descritos por Brian Marick. Fonte: Entrega Contínua: Como entregar software de forma rápida e confiável Na figura de Brian Marick, observa-se um agrupamento dos tipos de testes, sendo que no lado esquerdo estão os testes que suportam a programação. Estes testes se preocupam em avaliar a qualidade interna do sistema e são executados com
  34. 34. 33 bastante frequência pelos desenvolvedores para obter feedback sobre as mudanças introduzidas. No lado superior, estão os testes que são escritos do ponto de vista do negócio, com uma linguagem que faz sentido para um especialista de domínio. No lado inferior estão os testes voltados à tecnologia, escritos do ponto de vista técnico e com termos que farão sentido para os programadores. No lado direito existe testes que exigem a criatividade ou exploração e são geralmente manuais, como os testes exploratórios. Há também um conjunto de testes passíveis de automatização que, conforme Humble e Farley (2014, p. 91), em muitos projetos são ignorados ou não há uma preocupação em validá-los. O conjunto de testes também atua como um conjunto de testes de regressão, não testando apenas os requisitos funcionais do sistema, mas também a capacidade, a segurança e outros requisitos não funcionais estabelecidos, sendo possível garantir que quaisquer problema que comprometa o cumprimento desses requisitos possam ser identificados logo, quando o custo para corrigi-los é baixo. Conforme Humble e Farley (2014, p. 83), os testes automatizados devem ser escritos em colaboração entre os testadores e os desenvolvedores desde o início do projeto, antes que os desenvolvedores iniciem seus trabalhos, para que o conjunto de testes forme uma especificação executável do comportamento do sistema. Com os testes validam-se não somente se há um erro de lógica no código mas também se os requisitos estão bem definidos para que possam entregar aquilo que é esperado (LOPES, 2012, p.63). Os testes manuais também são essenciais para adicionar qualidade como demonstrações, testes de usabilidade e testes exploratórios, eles devem ser realizados continuamente ao longo do projeto. Os testes automatizados permitem que a máquina faça o que ela é boa, a repetição, enquanto os humanos façam o que eles são bons, explorar. Para a tarefa de escrita dos testes automatizados, a XP traz em suas práticas como descrito na seção 2.2.3, a prática de desenvolvimento guiado por testes, que é muito difundida na comunidade de desenvolvimento de software e descrita na próxima seção.
  35. 35. 34 2.7.1 Desenvolvimento guiado por testes Desde a década de 90, quando Kent Beck escreveu a primeira biblioteca de testes, o SUnit, em Smalltalk, existe a ideia de automatizar a tarefa de testes que muitas vezes era efetuada manualmente. Como as práticas da XP ganharam notoriedade no decorrer dos anos, o TDD ganhou ainda mais atenção, introduzindo o conceito de que os desenvolvedores devam escrever os testes para as funcionalidades antes de codificá-las. Conforme Braúna (2013, p. 4), isso permite um melhor entendimento das necessidades do cliente, cria uma preocupação com as interfaces externas dos métodos e classes e permite contar com um conjunto de testes que podem ser executados a qualquer momento para validar o sistema. O ciclo aplicado à prática do TDD envolve três passos, conforme a Figura 10. Figura 10 – Ciclo do TDD Fonte: http://www.lagerweij.com/2014/04/04/outside-in-whatevers-at-the-core/ Os passos são: • A escrita do teste se dá antes da codificação da funcionalidade, sendo que no primeiro momento, o que é esperado é que o teste não passe; • O próximo passo é codificar uma solução para que o teste tenha sucesso ao ser executado. Nesse momento, a primeira solução encontrada pode ser utilizada para atingir o objetivo; • No passo de refatoração, deve ser feita uma análise no código criado para verificar se existe uma solução mais otimizada que atinja o mesmo objetivo.
  36. 36. 35 2.8 INTEGRAÇÃO CONTÍNUA Em um ambiente de desenvolvimento, o software é dividido de modo que cada desenvolvedor fique responsável por uma parte dele. Dessa forma, é necessário integrar todas as partes para que o sistema funcione. Quanto mais longo for o tempo entre uma integração e outra, mais a equipe encontrará dificuldades para fazer o sistema rodar e os testes funcionarem (TELES, 2004, P. 176). Para Fowler (2006), Integração Contínua (IC) é uma prática de desenvolvimento de software onde os desenvolvedores integram seu trabalho pelo menos uma vez por dia, podendo haver múltiplas integrações por dia. Assim que o desenvolvedor termina sua tarefa, ele executa todos os testes para garantir que suas mudanças funcionam isoladamente, atualizam o seu código com as alterações mais recentes que estão no repositório de código e repetem todo o processo de testes, visando certificar que suas mudanças funcionam com o código que já está compartilhado. Só então é possível integrar o seu código ao repositório de código central. Apesar de diminuir as chances de introduzir defeitos no sistema, esse ritual exige que o desenvolvedor tenha a disciplina de fazer isso a cada alteração. Um servidor de integração contínua, conforme a Figura 11, permite o monitoramento do repositório constantemente. A cada alteração validada com sucesso no ambiente de desenvolvimento, é possível efetuar o check-in no repositório de código, fazendo com que o sistema de integração contínua execute uma sequência de verificações, como os testes automatizados, mantendo todos os membros do time atualizados com o estado atual do projeto. Figura 11 – Processo de integração contínua com o auxilio de ferramentas.
  37. 37. 36 Cada alteração que tenha sido validada com sucesso pelo processo de integração contínua vira uma versão candidata a ir para produção e fica disponível no repositório de artefatos. Essa prática permite descobrir eventuais defeitos o mais rapidamente possível, acelerando a correção e diminuindo a probabilidade de que pequenos erros se transformem em grandes dores de cabeça no futuro. 2.9 PIPELINE DE IMPLANTAÇÃO A Integração Contínua abordada na seção anterior concentra-se principalmente no time de desenvolvimento; ela precede o início de vários processos manuais, tais como os testes exploratórios e a implantação do sistema. Conforme Humble e Farley (2014, p. 105), há muitos gargalos no processo de entrega de software e é comum ver coisas tais como equipe de operações esperando por documentação ou correções, testadores esperando por versões “boas” de software, equipes de desenvolvimento recebendo informações sobre defeitos depois de já estarem trabalhando há semanas em outras funcionalidades e a descoberta, já no fim do processo de desenvolvimento, de que a arquitetura da aplicação não suporta os requisitos não funcionais do sistema. Nesse cenário, a equipe enfrenta um processo de feedback longo, deixando o sistema impossibilitado de ir para produção. O processo como um todo, de levar a funcionalidade da mente do cliente até o usuário final, pode ser tratado com uma visão mais holística, de ponta a ponta do processo de entrega e modelado através de um fluxo de valor, mostrando uma história dos processos executado por uma organização. O objetivo do fluxo de valor é mapear uma solicitação do cliente, do momento em que ela chega até que esteja disponível em produção (POPPERDIECK, 2011, p. 41). Conforme a Figura 12, todos os passos para atender à solicitação e o tempo médio em cada passo pode ser modelado, dando uma visão no tempo das atividades que agregam valor ao processo e o tempo gasto em espera de outras atividades. Essa espera entre um passo e outro pode se dar por exemplo, pelo tempo que se leva para configurar e implantar o sistema em um ambiente. Em um processo iterativo, a etapa de desenvolvimento incluiria vários ciclos compostos de testes e demonstrações e todo o processo seria repetido várias vezes.
  38. 38. 37 Figura 12 - Um exemplo de mapa de fluxo de valor simples para um produto Fonte: Entrega Contínua: Como entregar software de forma rápida e confiável As alterações efetuadas no sistema dependem de vários indivíduos, ou até mesmo de várias equipes até a sua entrega. Após a codificação, é preciso compilar o código gerando uma nova versão do sistema, fazer com que esse resultado seja validado em cada estágio de teste, implantado em ambientes para testes exploratórios e liberado em produção. O pipeline de implantação modela esse processo, e sua inversão em uma ferramenta de integração contínua e gerência de versões é o que permite que uma equipe veja e controle o processo de cada mudança à medida que ela se move em direção a entrega ao usuário final (HUMBLE; FARLEY, 2014, p. 107). Com os aspectos tratados nas seções anteriores e com a automatização, o processo de entrega pode ser efetuado e executado regularmente e, portanto, testado regularmente, agilizando o processo de feedback e reduzindo o risco de uma nova versão em produção. Duvall (2012) define o pipeline de implantação como um processo no qual diversos tipos de tarefas são executadas com base no sucesso da tarefa anterior. Para Humble e Farley (2014, p. 106) o pipeline de implantação é uma manifestação automatizada do processo de levar o software do controle de versão até os usuários. Cada mudança passa de forma consistente no percurso de entrega através da automação. A parte gerenciada pelo pipeline de implantação no mapa de fluxo de valor é a parte que vai do desenvolvimento até a entrega da versão. O fato de ser possível a automatização, não restringe a interação humana. A possibilidade de implantar o sistema com o apertar de um botão encoraja testadores, desenvolvedores, analista e usuários para seu uso frequente. A automatização torna passos complexos e suscetíveis a erros em passos repetíveis e confiáveis.
  39. 39. 38 Para chegar a este estágio, é necessário automatizar o processo de compilação, automatizar um conjunto de testes que provam os critérios do sistema e automatizar a implantação em ambientes de teste, aceitação e produção. Humble e Farley (2013, p. 109) explicam como essas mudanças se movem pelo pipeline de implantação através de um diagrama de sequência, como mostrado na Figura 13. A entrada do pipeline inicia-se com o check-in no sistema de controle de versão que aciona o sistema de integração contínua criando uma nova instância do pipeline, uma nova versão (versão candidata a ir para produção) que irá passar por uma sequência de testes para provar que é possível uma entrega de versão. Cada estágio de teste avalia a versão candidata de uma perspectiva diferente e a cada teste que ela passa, aumenta a confiança em sua implementação, o que significa que os ambientes do percurso se tornam progressivamente mais similares ao de produção. O objetivo desse processo é eliminar as versões candidatas que não estejam prontas para produção o quanto antes e obter feedback sobre a falha o mais rápido possível (HUMBLE; FARLEY, 2014, p. 108). Figura 13 - Mudanças se movendo por um pipeline de implantação. Fonte: Entrega Contínua: Como entregar software de forma rápida e confiável Com a adoção dessa abordagem, não é permitido efetuar implantação do sistema em produção sem que a versão seja apropriadamente testada e regressões são
  40. 40. 39 evitadas ao se fazer correções. As correções passam pelo mesmo processo que quaisquer mudanças. Quando a versão candidata passa pelo estágio de teste de aceitação automatizado, ela se torna algo útil e interessante não sendo mais prioridade da equipe de desenvolvimento. É preferível que os estágios de implantação para os ambientes de aceitação e produção não executem automaticamente. Os testadores devem ser capazes de ver quais versões candidatas passaram com sucesso e implantar o sistema em um ambiente configurado com um simples apertar de botão. 2.9.1 Como criar um pipeline de implantação inicial Essa seção descreve uma estratégia para se chegar a um pipeline de implantação conforme apresentado por Humble e Farley (2014, p. 133). Deve-se ter em mente que, independente do estágio do projeto, a implementação do pipeline deve ser de maneira incremental. Ë necessário ter uma visão dos processos necessários para permitir a entrega, isso pode ser efetuado através do mapa de fluxo de valor conforme visto no início deste capítulo. Com a participação de todos os envolvidos é possível descrever todos os passos, obter estimativas do tempo decorrido e do tempo gasto nas atividades que agregam valor. Modelar um pipeline de implantação exige entender seus processos de entrega e balancear o nível de feedback que você quer receber (SATO, 2013, p. 182). Projetos anteriores podem servir de base se estiver trabalhando em um novo projeto. Pode-se iniciar com um fluxo básico, um estágio para compilar a aplicação e rodar os testes unitários, um estágio para executar os testes de aceitação e um estágio para implantar o sistema em um ambiente similar ao de produção. O primeiro estágio é executado sempre que se faz check-in no repositório de código, os testes de aceitação devem utilizar o mesmo código resultante da etapa anterior e começar automaticamente depois que a compilação e os testes unitários tiverem sidos executados com sucesso. Os estágios de implantação utilizam as versões que passaram com sucesso pelos testes de aceitação e devem poder ser executados com o acionar de um botão. Na prática de entrega contínua, conforme (SATO, 2013,
  41. 41. 40 p. 181), a decisão de levar uma versão para produção é de negócio e normalmente requer pessoas com autorização. 2.9.2 Objetivos para utilização do pipeline O objetivo é ter o processo de entrega completamente automatizado para inibir risco de negócio associados a cada entrega do sistema em produção. Fowler (2013) acrescenta dizendo que o pipeline é para detectar quaisquer mudanças que levem os problemas para produção e para permitir a colaboração entre os envolvidos, possibilitando a visibilidade de todo o fluxo de mudanças juntamente com uma trilha de auditoria completa. Com a entrega sendo um resultado natural do pipeline de implantação, é possível obter: • Um plano de entrega criado e mantido por todos os envolvidos, incluindo desenvolvedores, testadores, operações, infraestrutura e suporte; • Minimização dos efeitos de erros cometidos por pessoas por meio da máxima automação do processo possível, começando com os estágios mais sujeitos a erros; • Ensaiar os procedimentos em ambientes similares ao de produção, de modo que seja possível depurar o sistema e a tecnologia que o suporta; • Ter a capacidade de executar um rollback3 de uma entrega se as coisas não acontecerem de acordo com o plano; • Ter uma estratégia de migração de dados e configuração de produção como parte do processo de rollback. Para que se consiga obter todos os benefícios do pipeline, Humble e Farley (2014, p. 113) descrevem um conjunto de práticas, tais como: • Compile seus códigos somente uma vez; • Faça a implantação da mesma maneira para cada ambiente; • Implante em uma cópia do ambiente de produção; • Cada mudança deve ser propagada pelo pipeline instantaneamente; 3 Rollback é uma ação que desfaz a ação corrente, fazendo com que todas as modificações realizadas até o momento sejam rejeitadas. Para mais informações acesse: http://pgdocptbr.sourceforge.net/pg82/sql-rollback.html
  42. 42. 41 • Se qualquer parte do pipeline falhar, pare o processo e corrija o problema antes de continuar qualquer coisa. Possibilitar que qualquer indivíduo (com permissão) envolvido no processo de entrega implante uma versão do sistema em um ambiente no momento que deseja, é um dos resultados adquiridos com a criação do pipeline. Para auxiliar nessa tarefa, existe no mercado um conjunto de ferramentas classificadas como ferramentas para automação de implementação, dentre elas, destacam-se: Capistrano, Mina, ControlTier, Glu e RunDeck. 2.10 MOVIMENTO DevOps Em 2009 durante a conferência Velocity da O’Reilly, John Allspan e Paul Hammond apresentaram 10+ Deploys Per Day4 , demonstrando como a Flickr5 efetuava 10 implantações por dia e através da convergência de outros movimentos adjacentes como: o movimento infraestrutura como código de Mark Burgess e Luke Kanies e o movimento de administração do sistema ágil de Patrick Debois, deu-se origem ao movimento DevOps. O movimento busca difundir em todo mundo a colaboração entre todos os envolvidos na entrega do software, particularmente as equipes de desenvolvimento, de testes e de operações, conforme a Figura 14. Figura 14 – Equipes envolvidas no movimento DevOps. Fonte: http://en.wikipedia.org/wiki/DevOps Essa colaboração permite otimizar o fluxo do processo de desenvolvimento, reduzindo o custo de criação de novas versões e possibilitando uma entrega 4 Acesse o video em: https://www.youtube.com/watch?v=LdOe18KhtT4 5 www.flickr.com
  43. 43. 42 confiável de software. Com a adoção do movimento DevOps, consegue-se criar um relacionamento colaborativo entre desenvolvimento e operações; ampliar as taxas de implementações; e aumentar a confiabilidade, a resiliência e a segurança do ambiente de produção. Uma premissa simples do DevOps é a aplicação de melhores práticas e padrões do desenvolvimento para as operações e vice-versa (DUVALL, 2012). Para Hashimoto (2013), DevOps serve para criar um ciclo de feedback rápido e reduzir o custo de criação de novas versões de produtos, ao mesmo tempo que melhora a estabilidade geral dos sistemas. A implementação na empresa não é instantânea, pode-se quebrar em uma série de pequenas mudanças.
  44. 44. 43 3. UMA PROPOSTA PARA AUTOMATIZAÇÃO DE ENTREGA DE SOFTWARE Este capítulo apresenta o estudo de caso realizado em um ambiente ágil de desenvolvimento de software, abordando as dificuldades relacionadas ao processo de entrega. Através desse estudo de caso será apresentado à proposta de solução, os requisitos funcionais que devem ser atendidos e os trabalhos correlatos. 3.1 ESTUDO DE CASO A empresa objeto deste estudo de caso está sediada em Vitória ES e possui mais de 5 anos de atuação no mercado de desenvolvimento de software. É especializada em soluções para lojas virtuais e possui cerca de 20 colaboradores, sendo que sete deles formam uma equipe dedicada exclusivamente para seu Sistema de Loja Virtual (SLV). Essa equipe, é composta de 3 desenvolvedores, 1 gerente de projetos, 2 suporte/qualidade e 1 comercial, que atendem lojistas de várias regiões do país no mercado de comércio eletrônico. O SLV da empresa é o ponto de partida para o atendimento de um novo cliente. Esse sistema possui mais de 30 implantações em produção, ou seja, mais de 30 clientes que o utiliza para vender seus produtos através da internet. Para inibir riscos com perda de oportunidades no universo web, onde as informações trafegam de continente a continente em frações de segundos, a empresa evita os longos ciclos de desenvolvimento tradicionais adotando as metodologias ágeis, fazendo uso das práticas da XP, do Scrum e do Kanban. Dessa forma, uma nova versão do sistema é entregue a cada 10 dias de desenvolvimento, no término de cada Sprint. Para cada solicitação de um cliente, existe uma sequência de procedimentos pré- definidos que são executados até a conclusão do atendimento. Esses processos foram especificados em um mapa de fluxo de valor conforme a Figura 15. Entende- se como fluxo de valor o processo de levar uma necessidade da mente do cliente até as mãos de seus usuários finais (HUMBLE; FARLEY, 2014, p. 107). Esse mapa é executado sempre que há uma nova solicitação, seja de clientes novos ou de clientes já existentes e é composto das seguintes atividades:
  45. 45. 44 • Quando uma solicitação é gerada pelo cliente, o responsável pelo comercial realiza um contato com o lojista para que seja feita a especificação de como a loja deverá funcionar, conforme o ramo de atuação da loja; • Comercial, gerente de projetos e desenvolvedores analisam os requisitos da solicitação definindo um orçamento; • Com o orçamento aprovado, o gerente de projetos em conjunto com os desenvolvedores, realizam uma estimativa de esforço conforme a complexidade dos requisitos para mensurar quantas Sprints essa nova demanda irá ocupar no cronograma. Várias Sprints podem ser agendadas até o atendimento de todos os requisitos; • No período de desenvolvimento, onde o tempo total é determinado de acordo com a quantidade de Sprints necessárias para atender as solicitações, várias atividades são executadas conforme descrito na seção 3.1.1; • No final de cada Sprint, é criada uma nova versão do SLV para o cliente e as funcionalidades são implantadas em seu ambiente de produção. Figura 15 - Mapa do fluxo de valor da empresa objeto deste estudo. Na execução desse processo, um desenvolvedor é alocado para desenvolver as solicitações de um determinado cliente. As solicitações menores, as que não ocupam uma Sprint, são alocadas a um desenvolvedor em uma Sprint chamada de suporte, deixando o cronograma sempre com 3 Sprints ocorrendo paralelamente. Para manter a competitividade frente aos concorrentes, a empresa constantemente precisa efetuar atualizações no SLV para introdução de novas funcionalidades, atualização de tecnologia ou otimização de código, de forma a proporcionar uma melhor experiência de compras aos usuários. Sendo assim, Sprints para a atualização do SLV são adicionadas ao cronograma.
  46. 46. 45 Devido às dificuldades dos processos de desenvolvimento, conforme seção 3.1.2, a quantidade de entregas de software de valor no final de uma Sprint é baixo, sendo preciso o agendamento de várias Sprints e, sendo assim, a estimativa de tempo para o atendimento das solicitações de um cliente é elevada. Gasta-se aproximadamente cerca de 45 dias para a disponibilização de uma nova loja com poucas customizações. O fluxo de atendimento a pequenas solicitações gira em torno de 30 dias, deixando os clientes insatisfeitos com o atendimento. 3.1.1 Processos relacionados ao desenvolvimento Durante uma Sprint, um conjunto de tarefas necessárias para o desenvolvimento de software são executadas pela equipe. O conjunto de solicitações a serem desenvolvidas nesse período são gerenciadas manualmente fazendo uso do quadro do Kanban, No quadro, o fluxo é efetuado conforme a Figura 16. Figura 16 – Movimentação atual das solicitações no quadro Kanban. As solicitações ficam disponíveis na coluna A Fazer. Quando o desenvolvedor inicia a codificação, ele move a solicitação que irá trabalhar para a coluna Fazendo e quando termina, a move para coluna Verificação. Nessa coluna, a equipe de qualidade tem a visualização das solicitações que já estão disponíveis para serem testadas no ambiente de aceitação. Um desenvolvedor disponibiliza a solicitação no ambiente de aceitação para que a equipe de qualidade realize os testes. Quando os testes terminam, a solicitação é movida para a coluna Concluído e, então, um desenvolvedor efetua a implantação no ambiente de produção e arquiva a solicitação, retirando-a do quadro. Para a codificação das solicitações, cada desenvolvedor configura seu ambiente de desenvolvimento com as dependências necessárias para o funcionamento do SLV. Ao efetuar alterações no SLV, o desenvolvedor efetua o gerenciamento de versão de código utilizando a ferramenta Git e escreve um conjunto de testes automatizados com a utilização da ferramenta RSpec, apresentada na seção
  47. 47. 46 5.2.1.10. Esses testes são executados em seu ambiente de desenvolvimento para certificar de que não foram inseridos defeitos no sistema. Os testes também são executados quando se faz o check-out do repositório, verificando que as alterações de outro desenvolvedor não afetaram o que foi codificado. Devido a codificação ser em computadores separados, é necessário efetuar a junção do código produzido ao repositório de código fonte, permitindo que outros desenvolvedores utilizem o que foi produzido. O gerenciamento dos sistemas por cada desenvolvedor pode ser visualizado na Figura 17, onde o ambiente de desenvolvimento é o computador pessoal de cada um. Os ambientes das lojas virtuais são acessados pelos desenvolvedores para a realização de configurações e atualizações manualmente. O processo de implantar a loja é efetuado através do acesso ao servidor e efetuado o check-out do código fonte no repositório e reiniciado os serviços necessários, também de forma manual. Figura 17 - Fluxo do gerenciamento do sistema pelos desenvolvedores. Para um novo cliente, o início do desenvolvimento possui uma etapa adicional chamada de Setup do Sistema, que é composta das seguintes tarefas: • Configurar o ambiente de aceitação onde o sistema será disponibilizado para que sejam efetuados os testes exploratórios, possibilitando ao cliente validar suas solicitações;
  48. 48. 47 • Configurar o ambiente de produção onde a futura loja virtual ficará disponível para os usuários finais, • Implantar a versão padrão do sistema de loja virtual nos dois ambientes, ou seja, implantar a versão inicial do sistema sem nenhuma customização. O sistema é instalado inúmeras vezes no ambiente de aceitação para que a equipe de qualidade e o próprio cliente efetuem testes e validem as solicitações no decorrer da Sprint. No término da Sprint, a nova versão do SLV é implantada em seu ambiente de produção. Na atualização do SLV, os testes e validações são efetuados somente pela equipe de qualidade, porém, no término, as atualizações são implantadas no ambiente de produção de cada cliente. 3.1.2 Dificuldades encontradas no desenvolvimento O principal problema enfrentado pelos profissionais da área de desenvolvimento de software é como fazer para transformar uma boa ideia em um sistema e entregá-lo aos usuários o quanto antes (HUMBLE; FARLEY, 2014, p. 3). Com demonstrado na seção 3.1, há uma grande utilização do SLV. Os clientes estão sempre solicitando atualizações e melhorias para acompanhar as novas tendências do mercado, fazendo com que a empresa receba uma grande demanda de manutenções mensais. Os novos clientes chegam à empresa com um cronograma para o futuro lançamento do seu e-commerce, porém, eles acabam frustrados ao saber que o lançamento de sua loja virtual só poderá ser realizado em um prazo bem maior daquele planejado. De acordo com a análise efetuada pela equipe, concluiu-se que o gargalo se dá devido a muitos processos manuais que existem no desenvolvimento. Muitas tarefas são executadas manualmente sem um nível de qualidade que impeça a inclusão de defeitos no sistema.
  49. 49. 48 Durante o ciclo de desenvolvimento, diversos problemas ocorrem, tais como: • Os desenvolvedores codificam as funcionalidades em seus ambientes de desenvolvimento sem o controle sobre as versões das ferramentas utilizadas e a compatibilidade com o ambiente de produção; • Para aumentar a qualidade, a empresa faz uso de técnicas e conceitos do TDD, onde testes são escritos para posteriormente codificar os requisitos. Cada desenvolvedor executa os testes em seu próprio ambiente de desenvolvimento várias vezes ao dia, sempre que está desenvolvendo uma nova funcionalidade e quando faz o check-out no repositório. Cada vez que este processo é executado, é preciso esperar aproximadamente 15 minutos, desestimulando uma cobertura mais eficaz de testes e deixando o desenvolvedor impossibilitado de continuar trabalhando em outras atividades; • O código produzido paralelamente pelos desenvolvedores não é adicionado constantemente ao código principal, permanecendo em seu ambiente de desenvolvimento até que determinada tarefa seja finalizada. O custo da correção de defeitos é elevado devido ao ciclo de feedback ser longo. Trabalhar em paralelo exige mais comunicação e coordenação entre os membros da equipe, pois quanto mais tempo eles ficarem sem integrar suas mudanças, maior o risco de criarem conflitos (SATO, 2013, p. 126); • Muitas solicitações são desenvolvidas e o controle de qual versão de um componente que cada cliente está utilizando não é eficiente; defeitos são gerados quando componentes incompatíveis são adicionados a uma determinada loja; • Atualizações nos ambientes são efetuadas manualmente alterando o seu estado. São executados vários passos separados e atômicos sendo que é necessário fazer julgamentos a cada passo do processo, o que o torna sujeito a erro humano; • O processo de entrega é manual e demorado, é preciso copiar arquivos de configurações para o ambiente que a loja será implantada, possibilitando a presença de erros se cada passo não for executado perfeitamente; • Na fase de setup da plataforma, é preciso disponibilizar o ambiente de aceitação e o de produção. A instalação dos softwares que a plataforma depende e suas configurações são feitas manualmente, sem nenhum controle
  50. 50. 49 de qualidade e em caso de erro, não é possível fazer um auditoria para descobrir o motivo; • Implantar novos códigos ao sistema da loja em operação é extremamente crítico. Em muitos casos, é preciso esperar o momento de menor acesso, geralmente pela madrugada para implantar a nova versão. Um sistema não gera lucro ou valor até que esteja nas mão de seus usuários (HUMBLE; FARLEY, 2014, p. 14). 3.2 REQUISITOS FUNCIONAIS Conforme a descrição da seção 3.1.2, fica visível que um dos pontos desafiadores do projeto está na utilização de ferramentas capazes de automatizar diversas tarefas incluídas no processo de desenvolvimento e de prover uma forma simplificada de utilização pelos envolvidos. Com base em reuniões e discussões realizadas entre a equipe responsável pelo SLV, das observações feitas dos processo executados diariamente e da pesquisa de ferramentas utilizadas no mercado, foram levantados os requisitos para a iniciação de um sistema. Esses requisitos foram documentados através de Diagrama de Casos de Uso. Conforme Ramos (2006, p.32), o diagrama de casos de uso descreve a relação entre atores e casos de uso de um determinado sistema, permitindo uma visão global de alto nível, sendo fundamental a definição correta da sua fronteira. Um dos seus objetivos é apresentar, de forma geral, as funções e serviços que o sistema oferecerá, sem se preocupar em como estas serão implementadas. Os atores que interagem com o sistema são: • Desenvolvedor: ator responsável por gerenciar as solicitações, cadastrando e movendo-as pelo quadro Kanban de acordo com o desenvolvimento e pelo gerenciamento dos ambientes onde o SLV é disponibilizado, cadastrando as informações necessárias para acesso e executando a instalação automatizada. • GerenteProjetos: ator responsável por gerenciar as solicitações dos clientes, criando projetos, cadastrando e priorizando as solicitações conforme o cronograma de desenvolvimento. Responsável pelo cadastro de informações
  51. 51. 50 dos usuários habilitados a utilizar o sistema e pelo cadastro das informações de cada cliente. Também é responsável gerencia dos ambientes e pela decisão de atualização de uma loja com uma nova versão disponível; • Qualidade: ator responsável por verificar o atendimento das solicitações através de testes exploratórios. Possui acesso as solicitações para disponibilizá-las em ambiente de aceitação à medida que novas versões ficam disponíveis; • SIC: este ator é o sistema de integração contínua responsável por efetuar o monitoramento do repositório de código fonte e, ao perceber que uma alteração foi efetuada pelo ator Desenvolvedor, executar todos os testes automatizados, fornecendo feedback ao responsável pelo desenvolvimento da funcionalidade. Este sistema está agrupado em três subsistemas, os quais estão denominados: GerenciarSolicitacoes, GerenciarAmbientes e CadastrarGeral e serão descritos a seguir de forma sucinta. A Figura 18 apresenta o Diagrama de Casos de Uso principal do sistema proposto. A descrição completa é apresentada no Anexo A. Figura 18 - Diagrama de Caso de Uso Principal. 3.2.1 Caso de uso CadastrarGeral No caso de uso CadastrarGeral o gerente de projetos irá cadastrar todos os usuários envolvidos na entrega de software, permitindo o acesso aos projetos e seus
  52. 52. 51 ambientes. Nesse caso de uso também serão cadastradas as informações dos clientes. Um cliente poderá ter mais que um SLV ativo. Consultas aos clientes cadastrados poderão ser realizadas por todos os atores no caso de uso GerenciarSolicitacoes. Este caso de uso é decomposto nos casos de uso apresentados na Figura 19. Figura 19 - Diagrama de Caso de Uso CadastrarGeral. a) CadastrarUsuarios: caso de uso utilizado para gerenciar as informações dos membros da equipe responsável pelo sistema de SLV, tais como o nome, e- mail, descrição e data de inclusão. b) CadastrarClientes: caso de uso utilizado para gerenciar as informações dos clientes como o nome da empresa, telefone, e-mail e razão social; e dos especialistas de domínio que participam do projeto, tais como o nome, telefone, e-mail e descrição. 3.2.2 Caso de uso GerenciarAmbientes O caso de uso GerenciarAmbientes pode ser executado pelos atores GerenteProjetos e Desenvolvedor e é destinado ao controle das informações de configurações para a criação dos ambientes para implantação do SLV. Desenvolvedores com conhecimentos técnicos de configurações de servidor e sistema operacional controlam essas informações; os demais desenvolvedores podem contribuir nas atualizações das configurações, de acordo com as mudanças que são efetuadas no sistema. Este caso de uso é decomposto nos casos de uso CadastrarAmbiente, InstalarPuppet e ProvisionarAmbiente, os quais são apresentados na Figura 20.
  53. 53. 52 Figura 20 - Diagrama de Caso de Uso GerenciarAmbientes. a) CadastrarAmbiente: caso de uso utilizado pelo desenvolvedor ou pelo gerente de projetos com conhecimentos em configurações de servidores e sistemas operacionais para controlar os dados de acesso e configurações dos pacotes que deverão ser instalados em um Cloud Hosting. Para criar um novo ambiente, os atores deverão selecionar para qual o projeto o ambiente pertence e o tipo do ambiente (produção ou aceitação), o endereço IP do servidor, usuário e senha de acesso ao ambiente, a URL de acesso ao ambiente e a descrição. b) InstalarPuppet: este caso de uso será executado após o caso de uso CadastrarAmbiente, sendo responsável por (1) verificar se as informações cadastradas do novo ambiente tais como endereço IP, login e senha estão válidas (através da execução de um comando Unix ping); (2) instalar e ativar no nó6 correspondente ao endereço IP a ferramenta Puppet Client e (3) habilitar o botão de provisionamento de ambiente. c) ProvisionarAmbiente: caso de uso que será executado após o caso de uso InstalarPuppet ou a partir de uma lista de ambientes já cadastrados. As atores Desenvolvedor ou GerenteProjetos poderão executar o caso de uso ProvisionarAmbiente, clicando no botão correspondente. Neste momento, será enviada uma solicitação de serviço para a ferramenta Puppet Client que executará os scripts de instalação de pacotes no sistema operacional tais como nginx, mysql, redis, memcached e monit utilizados no ambiente de destino. A execução do caso de uso ProvisionarAmbiente deixa o ambiente em um estado apropriado para implantação do SLV. 6 No contexto atual, nó é um servidor disponível por um Cloud Hosting.
  54. 54. 53 3.2.3 Caso de Uso GerenciarSolicitacoes O gerenciamento das funcionalidades que serão customizadas no SLV, desde a sua entrada até o momento em que são entregues conforme o quadro Kanban da Figura 23 na seção 3.4.2, será apoiado pelo caso de uso GerenciarSolicitacoes. Nele, o gerente de projetos irá cadastrar o projeto e as solicitações (correção de defeitos, novas funcionalidades ou customizações) a serem atendidas. Os desenvolvedores, à medida que codificam, moverão as funcionalidades até a etapa de verificação automatizada e o SIC efetuará, então, a execução das etapas de testes automatizados, certificando-se que a nova versão é candidata a ir para produção. A equipe de qualidade poderá visualizar qual versão está disponível para testes e disponibilizá-la em ambiente de aceitação para demonstrações junto ao cliente. No término, o gerente de projetos poderá decidir qual versão deverá ser implantada em ambiente de produção. Este caso de uso é decomposto nos casos de uso apresentados na Figura 21. Figura 21 - Diagrama de caso de uso GerenciarSolicitacoes.
  55. 55. 54 a) CadastrarProjeto: caso de uso executado pelo ator GerenteProjetos para incluir um novo projeto no sistema conforme fechamento de contrato pelo comercial. No projeto será incluído todas as solicitações que serão atendidas. b) CadastrarSolicitacao: caso de uso é executado pelos atores Desenvolvedor e GerenteProjetos, sendo responsável pelo gerenciamento das solicitações que deverão ser desenvolvidas para a loja virtual, conforme a reunião de planejamento apresentada na seção 3.1. As informações de nome e descrição são inseridas e a solicitação permanece na coluna Solicitações do quadro Kanban. c) AgruparSolicitacoesSprint: caso de uso executado pelo ator GerenteProjetos para agrupar na coluna A Fazer do quadro Kanban as solicitações que serão atendidas na próxima Sprint. Os usuários que atenderão cada uma das solicitações são registrados, o status da solicitação é atualizado e as respectivas datas previstas para o início e para o fim do desenvolvimento são agendadas. d) IniciarDesenvolvimento: caso de uso executado pelos atores GerenteProjetos e Desenvolvedor para mover a solicitação que o desenvolvimento será iniciado, da coluna A Fazer para a coluna Fazendo do quadro Kanban, atualizando o seu status. e) EnviarParaVerificacao: caso de uso executado pelos atores GerenteProjetos ou Desenvolvedor para mover a solicitação da coluna Fazendo para a coluna Teste Unit. do quadro Kanban. Quando os atores finalizam a solicitação, eles enviam o código fonte para o repositório manualmente através da utilização da ferramenta Git. Nesse processo, o Git efetua a compactação dos arquivos alterados e gera um identificador único no formato SHA17 que é cadastrado na solicitação, permitindo dessa forma, que o SIC faça a movimentação da solicitação entre as colunas Teste Unit, Teste Integ. e Teste aceit. do quadro Kanban, atualizando do status de acordo com que as etapas de testes sejam executadas com sucesso. f) ExecutarTestesAutomatizados: caso de uso executado pelo ator SIC. O SIC estará monitorando o repositório de código em um intervalo pré-determinado. 7 Em criptografia, SHA-1 é uma função hash de criptografia projetado pela Agência dos Estados Unidos de Segurança Nacional. Veja mais em: http://en.wikipedia.org/wiki/SHA-1.
  56. 56. 55 Quando for detectado alguma alteração no repositório. O SIC executa então, os processos de testes automatizados. g) DisponibilizarVersaoEmAceitacao: caso de uso executado por todos os autores, exceto o SIC, para disponibilizar a versão que passou no processo de testes automatizados e está na coluna Aceitação do quadro Kanban, para o ambiente de aceitação. Neste ambiente, a equipe de qualidade realiza demonstrações do SLV para o clientes. h) ImplantarVersaoEmProducao: caso de uso executado por todos os autores, exceto o SIC, para disponibilizar a versão que foi validada com sucesso no item anterior no ambiente de produção. 3.3 REQUISITOS NÃO FUNCIONAIS Segundo Humble e Farley (2014, p. 249), os requisitos não funcionais são o equivalente em software ao construtor de pontes que tenta garantir que as vigas escolhidas são fortes o suficientes para suportar o tráfego e as condições meteorológicas esperadas. Esses requisitos são reais e precisam ser considerados, estão associados com o estado do sistema e não expressam nenhuma função realizada pelo sistema. O Quadro 1 apresenta os requisitos não funcionais para o sistema proposto. Quadro 1 – Requisitos não funcionais. TÍTULO DESCRIÇÃO 1 Segurança O sistema deve garantir a segurança dos dados contidos no sistema. 2 Navegabilidade Deve possuir uma navegabilidade fácil e intuitiva para facilitar a utilização diária. 3 Multiacesso O sistema deve possuir acesso a múltiplos usuários conectados simultaneamente e executando tarefas distintas ou não. 4 Performance O sistema deve atender aos requisitos de forma eficiente para possibilitar um ciclo de feedbacks curtos. 5 Integração O sistema deve efetuar a integração com as ferramentas utilizadas de forma a facilitar a utilização por todos os envolvidos.
  57. 57. 56 3.4 PROPOSTA DE SOLUÇÃO Esse trabalho propõe o desenvolvimento do sistema Ovenbird, baseado no padrão pipeline de implantação apresentado na seção 2.9. O objetivo do Ovenbird é gerenciar a transição das solicitações pelos vários estágios de desenvolvimento até o momento da entrega ao usuário final, através de uma interface amigável que abstraia a complexidade das ferramenta disponíveis no mercado e facilite, dessa forma, a utilização por qualquer membro da equipe responsável pelo SLV. O Ovenbird destina-se a gestão de atividades de Desenvolvimento, Entrega/Revisão e Nova Versão do mapa de fluxo de valor da Figura 15, visando tratar da gerência de ambientes e gerência de entrega. O Ovenbird é um sistema Web que será implantado em um Cloud Hosting para atender à necessidade da execução de processos de forma paralela ao desenvolvimento e, para permitir o acesso dos membros da equipe que estiverem fora das instalações da empresa. A utilização do Ovenbird inicia-se com o cadastro das informações de todos os interessados na entrega do SLV; a equipe responsável pelo sistema e o cliente. Um cliente poderá adquirir mais de um SLV. Cada loja virtual será representada no Ovenbird como um projeto, devidamente associado a um cliente. Um projeto é composto pelos ambientes para implantação e das solicitações que deverão ser desenvolvidas. As propostas de solução para a gestão destes dois ambientes são descritas nas próximas seções. 3.4.1 Proposta de solução para a Gerência de Ambientes Os processos de disponibilizar os ambientes na fase de setup (seção 3.1.1) e de efetuar atualizações, serão executados através de uma ferramenta de automação de infraestrutura, conforme apresentado na seção 2.6.1, para permitir que o processo de estabelecer ou restabelecer um estado do ambiente (apropriado para implantação), seja uma tarefa previsível e com o tempo conhecido.

×