Entrega Contínua de Software - Revista .net Magazine 100

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.

De que se trata o artigo

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. " [...] continue lendo...

Artigos relacionados