DevSecOps

25 abr, 2019

Do FTP ao Continuous Deployment – Implantando projetos nos dias atuais

Publicidade

Assim como equipamentos e softwares, a implementação de projetos sofre modernizações com o passar do tempo. O que antes se escorava no uso de protocolos de transferência, como o FTP, hoje passa por automações dentro de técnicas como o Continuous Deployment.

Parece grego para você? Neste artigo, vamos abordar alguns termos relacionados ao universo da implementação de projetos.

O Legado do FTP

File Transfer Protocol por muito tempo foi a técnica mais utilizada para se transferir arquivos em um projeto. Entretanto, a utilização deste protocolo já é algo ultrapassado no mundo da computação/desenvolvimento.

A ideia de precisar – manualmente – transferir os arquivos via um servidor FTP é algo que torna o seu projeto dependente da atuação humana. Logo, seu projeto estará mais suscetível a falhas e atrasos.

Apesar de ainda ser utilizado por alguns desenvolvedores, o uso de programas como o FileZilla vem dando lugar a outras técnicas mais modernas e seguras para a implementação de projetos.

Continuous Delivery

Continuous Delivery é o nome dado a uma técnica de engenharia informática que consiste em testar, preparar e implementar uma alteração de código. No fim de cada alteração é necessário uma validação humana, antes que as mudanças sejam efetivadas.

Continuous Deployment

De forma similar ao Continuous Delivery, o Continuous Deployment é uma técnica que permite alterações de códigos, mas, neste caso, a implementação acontece de forma automática, ou seja, sem validação humana.

Inclusive, o sistema se torna capaz de fazer um recuo automático para reparar erros que bloqueiam.

Diferença entre Continuous Delivery e Continuous Deployment

A principal diferença entre essas duas técnicas está na hora de fazer a implementação em produção. Geralmente, os desenvolvedores que fazem Continuous Deployment configuram um analisador de erros que é capaz de tomar automaticamente a decisão de reverter o processo, o que não é muito comum no Continuous Delivery.

Por que automatizar?

Se por um lado isso é menos visível em estruturas pequenas, o início da produção pode levar muito tempo em grandes estruturas. Algumas pessoas falam em mobilizar uma equipe por várias horas. Se isso tem um custo considerável, também pode ser um freio para produções regulares.

Logo, é melhor automatizar a entrega de modificações, com o objetivo de poder aumentar o ritmo de produção de forma que a necessidade de equipes seja descartada. É aqui onde entram o Continuous Deployment e Continuous Delivery.

Hoje em dia existem milhares de testes (unitários, funcionais, de qualidade do código, etc.), que permitem garantir ao máximo a automação. Alguns vão automatizar eventuais rollbacks na produção, com base nos logs de erros.

Para quem está acostumado com esse ambiente, algumas empresas que dependem de um sistema mais complexo podem exigir manipulações mais perigosas. Os erros podem acontecer, dada a complexidade do sistema, e as falhas humanas podem ser evitadas com a automatização.

Desta forma, deduzimos que os objetivos principais são:

Automatização de entregas com um conceito de desencadear todo o processo em um só click. O risco de falha humana que possivelmente ocorreria é eliminado.

Entregas frequentes, visto que a automatização permite realizar esse processo com um click.

A integração contínua para reforçar implementações

Como observado no esquema acima, a realização de inúmeros testes se torna fator obrigatório dessas técnicas de engenharia. Por isso, vale especificar alguns testes importantes:

Testes unitários

Realizar testes unitários em cada uma das funções será uma questão de segurança suplementar. Realizar TDD (Test Driven Development) também dá segurança de não se esquecer de implementar testes unitários, uma vez que a ideia é escrevê-los antes mesmo das funções.

Testes de cenário

Alguns ainda incluem testes de cenário e a técnica do BDD (Behavior Driver Development) para testar cenários mais funcionais.

Esses dois tipos de teste são testes de regressão. Eles permitem saber se qualquer coisa foi impactada a cada tentativa de implementação.

Além dos testes unitários e de cenário, existem também os testes funcionais, de carga, de qualidade de código, etc.

Um ambiente único para o Continuous Deployment

Um bom Continuous Delivery deve ser realizado em um único ambiente. Em outras palavras, os ambientes de desenvolvimento, testes e produção devem ser idênticos.

Se tornar os ambientes idênticos for um desafio, ferramentas como o Docker permitem que você se aproxime mais dessa filosofia do que antes. De certa forma, será indispensável a utilização desse tipo de ferramenta para realizar seriamente esse tipo de técnica de engenharia.

Conclusão

A internet é um ambiente em constante transformação – o que pode ser útil hoje, pode cair por terra no dia seguinte, e isso está fora do nosso controle.

O melhor a se fazer é se adaptar a essas mudanças e usufruir dos benefícios que surgem com as inovações, como é o caso do Continuous Deployment no campo de implementação de projetos.