O crescimento da profissão de desenvolvedor e sua relação cada vez mais próxima com a administração deu origem a uma série de jargões e metodologias relacionadas ao aumento da produtividade e eficiência. Entre eles está a trinca integração contínua, entrega contínua e deploy (ou deployment) contínuo.
A diferença entre os três pode parecer confusa, mas entender melhor esses termos vai ajudar você a entrar no debate atual sobre a forma como o software é desenvolvido em dia.
Nos últimos anos, houve uma mudança de paradigma na forma de se trabalhar com software. O antigo modelo cascata, com grandes lançamentos monolíticos, está sendo substituído por uma abordagem mais ágil de pequenas entregas incrementais. Esse desenvolvimento mudou a forma de se gerenciar o ciclo de vida dos aplicativos (Application Lifecycle, ou ALM).
Neste artigo você vai entender melhor essa mudança na forma de trabalhar do desenvolvedor e o que significam os termos Integração, deploy e entrega contínua.
Entrega contínua: três princípios básicos
O ALM já representava uma mudança na forma de se pensar em relação ao Software Development Life Cycle (SDLC), que se limitava a etapas como design, produção do código, testes, etc. O ALM se estende muito após o desenvolvimento e se estende até o momento em que o software não for mais usado.
A nova mudança, do ALM para a entrega contínua, inclui três princípios básicos:
- o software deve ser sempre entregável ao consumidor final (deployable), de forma que o desenvolvedor dá prioridade a manter o deploy no lugar de adicionar novas funções. Por isso, são feitas mudanças menores e menos arriscadas, aos poucos, em vez de uma grande atualização de uma só vez;
- um loop de feedback para as etapas de build, teste e deploy expõe a prontidão do software, permitindo a qualquer pessoa das equipes de desenvolvimento, teste e produção determinar se um release imediato em qualquer ambiente pode ser aprovado;
- a automação do processo de build, teste e deploy é fundamental para que o processo seja repetível e para sustentar uma frequência mais alta desse ciclo (build-testar-deploy).
Sem linearidade: o abandono do modelo cascata
Ao contrário do que ocorria no modelo cascata do ALM, o ciclo de vida do software hoje não é mais visto como linear. Na entrega contínua, um update ou patch pode ir da equipe de desenvolvimento direto para a produção sem passar pela fase de testes.
Uma vez que os princípios que vimos acima garantem manter o software em estado de deploy, com um loop de feedback para determinar sua prontidão, pode-se transportar o código para qualquer ambiente a qualquer momento.
Essa mudança do modelo cascata (linear) para uma abordagem não-linear e mais ágil tem a vantagem de ser bem mais realista no modo que as empresas gerenciam seu software. A demanda por entregar uma alteração em qualquer ambiente “pra ontem” é tão comum quanto problemática. Os princípios ajudam a criar uma metodologia de trabalho com melhor capacidade de enfrentar essas situações.
Integração, deploy e entrega contínua: definições
Como costuma ocorrer com termos em informática e administração, as definições de termos podem mudar com o tempo e entre autores diferentes (por exemplo, “código legado”). As definições mais úteis serão aqueles que ajudam a entender esses três termos como camadas em uma cebola: cada um depende dos anteriores. Vamos a elas nos próximos tópicos.
Integração contínua
Significa que as cópias do trabalho do desenvolvedor são sincronizadas com uma mainline compartilhada várias vezes por dia. Os integrantes da equipe usam um sistema de controle de versões para integrar o trabalho constantemente. Cada mudança é construída e verificada por testes para detectar quaisquer erros o mais rapidamente possível.
Foco: construir e testar o código automaticamente
Entrega contínua
É um processo que deriva da integração vista acima, trata-se de uma metodologia para automatizar o processo de entrega. Cada mudança no software é automaticamente construída, testada e entregue à produção.
Antes da entrega final, uma pessoa, teste automatizado ou uma regra de gerência decide quando o “push” vai correr. Todas as mudanças bem-sucedidas podem ser entregues imediatamente, mas não necessariamente serão.
Foco: automatizar o processo completo de entrega do software até a produção
Deploy contínuo
É a última etapa possível em automatização de mudanças, e depende das duas etapas acima. As mudanças passam a ser entregues ao consumidor final automaticamente sempre que o produto passar pelo controle de qualidade. Isso exige a capacidade de poder transportar o resultado do processo de desenvolvimento para um ambiente de produção no qual os testes funcionais podem ser executados em larga escala.
O deploy contínuo é uma capacidade excelente para “testar as águas” do mercado e economizar dinheiro por meio de mudanças menores e menos arriscadas (como falamos acima).
Imagine que uma empresa tem uma ideia para uma nova função em um serviço. Existem duas opções básicas:
- passar vários meses desenvolvendo um grande pacote de código e então lançar no mercado, aguardando as vendas chegarem;
- implementar pequenas partes da nova função, uma por vez, sem arriscar grande quantidade de dinheiro ou tempo em nenhuma etapa.
No segundo cenário, se a mudança não fizer sucesso entre os consumidores, a empresa pode trocar o rumo imediatamente sem ter alocado muito tempo ou dinheiro.
Conclusão: integração, deploy e entrega contínua como metodologias
Integração, deploy e entrega contínua não são apenas termos da moda, como os que costumam circular em revistas e livros de negócios. Eles representam uma mudança real na forma de se trabalhar e de entregar código para chefes e clientes.
Como ocorre com muitas mudanças de paradigma, trocar comportamentos e adotar novas rotinas é um grande obstáculo. Em muitas empresas, o uso manual de scripts para fazer builds e deployments e gerenciar a infraestrutura ainda persiste, e o velho modelo cascata pode até ser chamado erroneamente de “integração contínua” em alguns casos.
Para dar suporte à entrega contínua, as atividades de build, deploy e teste devem ganhar elasticidade, ajustando-se automaticamente às mudanças no código, na base de dados e no servidor.
À medida que o paradigma da integração ganha força e acelera a frequência das atualizações, o fluxo de trabalho se distancia da metodologia tradicional em direção à automação completa. Essa cadeia automatizada será orquestrada por meio de um servidor de integração contínua, e o processo todo se tornará mais rápido, mais confiável e mais responsivo.
Fique por dentro das melhores dicas em TI, infraestrutura e marketing digital para desenvolvedores, agências digitais e revendedores. Siga a locaweb no Facebook, LinkedIn e Instagram.
