O artigo desenvolve sobre o tema de entrega contínua, um conjunto de práticas e princípios cujo objetivo é ajudar a compilar, testar e liberar software de forma mais rápida e frequente.
Em que situação o tema é útil
Tanto o tempo da equipe de desenvolvimento quanto da equipe de testes deve ser utilizado em tarefas mais nobres do que manualmente dar build nos projetos, testar mecanicamente todas as linhas de código ou publicar versões dos sistemas nos servidores. Ao implementar a entrega contínua, a equipe automatiza todas essas tarefas com segurança e assegura mais disponibilidade para realizar tarefas importantes, tais como escrever código com qualidade e entregar funcionalidades que agreguem mais valor para o cliente.
Entrega contínua
O leitor aprenderá quais são os motivos e as justificativas para adoção da Entrega Contínua e também aprenderá a realizar sua implantação de forma correta, entendendo quais são as etapas, fases, técnicas e processos. Será exposta a origem da técnica, onde ela se encaixa dentro do contexto de desenvolvimento de software, os benefícios e qual o seu papel na diminuição do stress nas entregas de software e no aumento da satisfação do cliente com o andamento do projeto e com a equipe.
É dito que software não entregue ao cliente é inútil. Pode ser o código mais virtuoso já escrito, a técnica mais performática ou uma funcionalidade brilhantemente executada, mas ele não tem valor se o cliente não o está utilizando.
Neste sentido, tem pouco valor uma nova funcionalidade que existe somente no repositório de código-fonte e não foi atualizada ou utilizada em nenhum ambiente, quer seja homologação ou produção. Como não há nenhuma funcionalidade que o cliente interaja, podemos dizer que aquele código não agregou valor ao produto.
A entrega contínua existe para que as funcionalidades sejam liberadas continuamente e de forma segura para o cliente. Imagine que ao submeter um arquivo para o repositório de código-fonte, o ambiente de homologação seja automaticamente atualizado e o ajuste seja disponibilizado para testes sem a necessidade de intervenção manual.
Esta é a promessa da entrega contínua, do ponto de vista de desenvolvimento. A equipe está focada em criar o melhor software possível, sem gastar tempo com atividades mecânicas, como atualizar ambientes ou verificar se os testes unitários estão passando e se o build está compilando. Do ponto de vista da equipe de qualidade, a execução dos testes automatizados possibilita uma homologação automática, permitindo também a atualização mais rápida do ambiente de produção, por exemplo.
Formalmente, a entrega contínua é definida como “um conjunto de práticas e princípios com o objetivo de compilar, testar e liberar software de forma mais rápida e frequente”. Observe que a definição em si não menciona programas específicos, mas sim uma filosofia a ser seguida.
O uso do termo “liberar software” talvez mascare um pouco o seu real significado. É uma tradução livre do termo “software release” que é justamente o produto final do trabalho da equipe de desenvolvimento. A equipe trabalha para liberar o software para o cliente, daí o termo.
A entrega contínua é frequentemente citada como o primeiro princípio listado nos doze princípios por trás do manifesto ágil: “Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado”.
Neste sentido, apresentaremos mais a frente o emprego da entrega contínua nos modelos de desenvolvimento mais comuns na Engenharia de Software.
A Entrega contínua no Modelo Cascata
Considere o paradigma de desenvolvimento de software em cascata Waterfall.Nele, há uma definição bem clara sobre as fases pelas quais um projeto, desde a concepção até a implantação em produção, conforme a Figura 1.
Figura 1. Diagrama de desenvolvimento em cascata
O grande dilema em relação ao desenvolvimento em cascata é a rigidez implícita no modelo. O software é pensado como um pacote único, com uma única entrega, ao final de todo o processo. Por causa disto, toda a análise, para todo o software, é feita no iníciodo projeto; o desenvolvimento só pode começar depois que toda a análise for feita e os testes somente podem ser realizados depois que todo o software foi desenvolvido: tomando como exemplo um projeto estimado em seis meses de duração, os testes são planejados para acontecer somente antes da implantação, bem no final do ciclo de desenvolvimento, por volta do quinto mês.
Este paradigma não se beneficia completamente da entrega contínua porque os testes e a validação da qualidade do software desenvolvido somente são considerados depois que todo o desenvolvimento aconteceu. Sendo o objetivo da entrega contínua garantir, via processos automatizados, que o que foi desenvolvido também já foi testado, o paradigma de desenvolvimento em cascata não aproveita todo o potencial da mesma. Contudo, durante a fase de testes, a entrega contínua pode ser de grande ajuda para a equipe trabalhando em um projeto desses, porque agiliza o feedback entre o desenvolvimento e a equipe de testes. Explico: por exemplo, um analista de testes preenche um relatório de bug, um desenvolvedor atua na correção e a entrega contínua automaticamente atua em todos os pormenores para que esta correção esteja disponível para testes o mais rápido possível, agilizando todo este processo de feedback.
...
