Deploy… algo que gera tanta tensão e é tão temido entre pessoas desenvolvedoras de software. Se você já fez um deploy, sabe do que estamos falando.

O deploy é conhecido por ser o momento onde tudo pode dar errado. É de onde passamos de “na minha máquina funciona” para “outras pessoas podem acessar em diferentes lugares”. Entretanto, o deploy também é o momento em que conseguimos, de fato, mostrar nosso site ou aplicação para outras pessoas na internet.

Mas não estamos aqui para te assustar, na verdade vamos te explicar tudo sobre deploys para que você consiga ter mais tranquilidade da próxima vez que for deployar. Olha só o que você vai conferir neste post:

Acompanhe o raciocínio e boa leitura!

O que é Deploy?

Deploy, em inglês, significa implantar. Portanto, um deploy é quando uma aplicação é colocada no ar, ou seja, é disponibilizada para uso, seja em um ambiente de desenvolvimento, de teste ou em produção.

Pensando nas fases do ciclo de vida de desenvolvimento de software (SDLC – Software Development Life Cycle), temos a seguinte ordem: você planeja como será determinada função do seu software, depois disso você precisa criar a interface dessa funcionalidade para que ela entre para o desenvolvimento com todos os testes necessários.

Quando estiver pronto, esse código pode ser disponibilizado para que outras pessoas o usem (aqui entra o deploy). Depois, esse sistema entrará em manutenção, formando um ciclo sem fim com o planejamento de novas funcionalidades.

ciclo de desenvolvimento de um software

Quais os ambientes de um Deploy?

Depois que o código já foi desenvolvido e está pronto, entramos na etapa de deploy. Nessa fase, não é simplesmente pegar esse código e colocar em um servidor que outras pessoas usuárias tenham acesso. Existem alguns ambientes em que um deploy deve ser feito e fases que uma aplicação deve passar antes de chegar na pessoa usuária final. Eles são: ambiente de desenvolvimento, testes e produção.

Ambientes de um deploy

Desenvolvimento

Geralmente, o ambiente de desenvolvimento está no seu computador. É o ambiente onde você desenvolve, pode testar, errar e não vai afetar nem impactar o trabalho de ninguém. Provavelmente, esse ambiente está conectado a um banco de dados local ou com dados fake, então não existe risco de perda dados importantes. Não é necessariamente um deploy, mas é o primeiro lugar onde o seu código roda.

Ambiente de teste (staging ou homologação)

Agora sim é feito o primeiro deploy (segundo, se o ambiente de desenvolvimento for em um servidor). Nesse estágio, o seu código já está mais maduro e será disponibilizado para que pessoas da sua equipe possam testá-lo. Esse é um ambiente muito parecido com o de produção (mas não exatamente igual), provavelmente está em uma intranet ou em um local onde apenas pessoas específicas possam acessá-lo. Portanto, não é totalmente público.

Produção

Depois que tudo está desenvolvido, testado e seu código está pronto, é a hora do último deploy. O ambiente de produção é basicamente um servidor no qual as pessoas que são usuárias finais têm acesso. Ou seja, é quando a sua aplicação vai para o ar!

Como fazer um Deploy? O passo a passo básico!

Vamos te mostrar quais são as etapas básicas para começar a pensar em um processo de deploy. Apenas para reforçar, existem muitas ferramentas disponíveis que podem ser usadas em cada uma dessas etapas, com suas vantagens e desvantagens. Sabemos que pode ser complicado no começo, mas pesquise e observe o que elas oferecem e qual se encaixa mais no que você está precisando. 

1 – Crie o seu projeto

O primeiro passo para fazer um deploy é ter o quê deployar, ter um código para mostrar para o mundo! Para isso, você precisa desenvolver o seu site ou aplicação, nem que seja um “Hello World” para você testar se funciona. Outra coisa a se pensar é usar um sistema para controle de versão, como o Git, por exemplo — falaremos um pouco mais dele nesse post. 

2 – Infraestrutura: escolha o ambiente do seu site/aplicação!

Agora você vai escolher o ambiente para o deploy da sua aplicação — ou seja, sua infraestrutura, podendo ser um pequeno servidor, algum serviço de hospedagem, plataformas que funcionam como PaaS (Platform as a Service), ou algum serviço que suporte você deployar o seu código. 

É importante que você pesquise e escolha o ambiente mais adequado para sua realidade, pois cada um desses exemplos tem um suporte. Não esqueça que a infraestrutura escolhida precisa ter suporte às linguagens de programação que você está usando no seu projeto!

3 – Escolha, compra e configuração de domínio!

Se você estiver fazendo uma aplicação web, precisa ter um site, senão não tem como as pessoas a acessarem. Para isso, você precisa comprar um domínio. Existem diversos sites que vendem domínios, alguns com mais pontos inclusos que outros. Por isso, procure o que tenha o melhor benefício para você.

Após a compra do domínio, não esqueça de configurar o DNS (Domain Name System ou Sistema de Nomes de Domínio) com os dados do seu servidor ou serviço de hospedagem. Dessa forma seu domínio reconhecerá o seu servidor. 

4 – Configurar o ambiente de hospedagem

Nessa etapa, você precisa configurar seu ambiente de hospedagem (o mesmo que escolheu anteriormente). Você vai instalar o que for preciso, por exemplo banco de dados e outros serviços, ajustar suas configurações e outras coisas que forem necessárias para a sua aplicação. 

5 – Otimização de processos

Depois que a sua aplicação já estiver funcionando, você pode observar pontos para deixá-la ainda melhor. Por exemplo, se tem processos que estão sendo feitos de forma manual e que podem ser automatizados com algum script, configurações de cache para deixar os carregamentos ainda mais rápidos ou até mesmo se tem pontos que estão demorando demais ou que não estão sendo utilizados e que podem ser otimizados.

6 – Concluindo o processo de Deploy

Com tudo pronto, teste o funcionamento da aplicação, fazendo alguma alteração no seu código e subindo ele para produção! 

Boas práticas de deploy para evitar dores de cabeça?

Use Git

Ter um controle de versão como o Git junto com o Github pode ser importantíssimo para criar um processo de deploy mais seguro. Caso tenha qualquer problema no deploy, com o Git é muito mais fácil voltar para uma versão anterior ou até mesmo testar uma versão específica para encontrar erros.

Trabalhe com branches

Junto com o Git, trabalhar com branches também traz essa segurança. Tanto nos ambientes, mas também para desenvolvimento de tarefas e fix de bugs, por exemplo, o uso de branches vai te ajudar a ter histórico de tudo que foi feito no código e deixá-lo mais organizado — principalmente quando você escalar o time e tiver mais pessoas mexendo no mesmo código.

Use um ambiente local como seu ambiente de desenvolvimento

Usar a sua máquina para desenvolver, testar e errar deixa o desenvolvimento muito mais ágil, já que você passa a ter mais flexibilidade. O único problema é que você terá que baixar todas as dependências para subir a sua aplicação. Isso também mantém os outros ambientes (não locais) seguros de problemas

Faça um review antes de colocar em produção

Por mais que o seu código já tenha passado por testes e sido aprovado, sempre pode passar alguma coisa nas revisões. Por isso, é sempre importante uma última verificação das diferenças entre os códigos antes do deploy.

Tenha um cronograma de deploy

É importante que outras pessoas saibam e estejam preparadas para o deploy, principalmente quando existe a possibilidade de ter grandes mudanças no sistema. Caso dê algum problema ou aconteça algo, elas precisam estar prontas para corrigir. 

Considere ter grupos de usuários com permissões diferentes

Se você tem um time maior, talvez faça sentido que todo mundo possa fazer um deploy para staging, mas que apenas algumas pessoas possam fazê-lo para produção. Óbvio que isso depende muito da empresa e da cultura, mas pensar em ter permissões diferentes é uma boa prática que vale pra muita coisa, não somente para o deploy, como para o acesso aos servidores, banco de dados, entre outras aplicações. 

Se algo quebrar, acalme-se

Acabou de fazer um deploy e tudo quebrou? Acalme-se, isso já aconteceu com grande parte das pessoas! É muito importante não fazer coisas no impulso nesse momento. Respire e pense quais opções você têm: você sabe qual o problema? Sabe resolvê-lo? Quanto tempo levaria? Ou você não tem ideia do que aconteceu, nem sabe quanto tempo pode levar para encontrar uma solução? 

Dependendo da sua resposta, você pode decidir que o melhor é fazer um fix rápido e já subir a correção ou então você pode decidir fazer um rollback (voltar para a versão anterior, que estava funcionando) e investigar o problema com mais calma. Lembre-se de uma coisa apenas: acalme-se e respire!

Quais as formas de fazer um bom deploy?

Manual

Essa é uma das formas de deploy mais populares, apesar de ser bem trabalhosa. Um exemplo de deploy manual é o FTP (Protocolo de Transferência de Arquivos), que permite que dois computadores com acesso a internet troquem arquivos. 

Alguns dos problemas desse tipo de deploy são o tempo gasto com uma atividade que poderia estar mais automatizada, a possibilidade da pessoa desenvolvedora esquecer de alguma etapa ou fazê-la pela metade, e também existe o risco de que duas pessoas façam o deploy ao mesmo tempo — o que pode dar conflitos nas trocas de arquivos. 

Também entende-se como um deploy manual quando uma pessoa desenvolvedora altera rapidinho um arquivo e faz um upload dessa alteração direto para produção.

Parcialmente automatizado

Quando deixamos um repositório do Git atrelado a um hook que atualiza o servidor e sobe o código para produção. Para isso, basta apenas um push na branch main e o código será atualizado em produção. Uma das vantagens desse método é o controle de versão e o estado de cada deploy.

Completamente automatizado

Esse é o deploy mais moderno e completo que existe! Com ele não acontece só o deploy automático das atualizações para o servidor, mas também o que chamamos de integração contínua. Tudo isso garante mais segurança, qualidade e eficiência para a sua aplicação. Existem hoje diversas ferramentas que te ajudam na automatização completa do seu deploy, como o Jenkins, Travis CI, GitLab, Azure Pipelines, Circle CI, entre outros.

Integração contínua: o que é CI (Continuous Integration)?

Integração Contínua (CI) é uma prática no desenvolvimento de software em que as pessoas desenvolvedora integram suas alterações de código a um repositório central com frequência. Dessa forma, o ambiente é criado e os testes são rodados, o que permite encontrar erros e bugs mais rapidamente. Integração Contínua acontece diversas vezes ao dia, principalmente quando temos projetos e times de desenvolvimento grandes. Olha só no esquema:

Fluxograma sobre Integração Contínua
Imagem de https://aws.amazon.com/pt/devops/continuous-integration/

3 estratégias para fazer um deploy!

Rolling

Essa é uma das estratégias mais simples e nela você vai subindo o código novo de cada serviço e substituindo a versão antiga. Esse deploy é feito gradualmente e, enquanto 100% dos serviços não estiverem com o novo código, eles terão uma parte com o código antigo e a outra parte com o código novo. Quando atingir esse 100%, aí sim a versão antiga estará desligada. 

Blue-Green

Nessa estratégia existe um load balancer, que é responsável por direcionar a request para o lugar certo; e dois ambientes idênticos, que também podem ser chamados de mirror. Ao subir uma nova versão da aplicação (green), enquanto ela estiver subindo, as requisições vão continuar indo pra versão atual (blue).

A vantagem dessa estratégia é que, após subir a nova versão, você ainda vai conseguir testar a versão green. Assim, as requisições só vão passar a ir para a versão final quando tudo estiver certo. 

Além de conseguir realizar testes em produção, essa estratégia permite que o seu sistema tenha o mínimo de indisponibilidade, já que a troca entre a versão blue pra green é muito rápida. Uma desvantagem é quanto aos recursos que você terá que alocar, que é maior pela necessidade de ter um mirror

Canary

Essa é uma das estratégias mais complexas, que consiste em você colocar o seu novo código em produção apenas para uma parcela das pessoas usuárias. Você pode determinar que apenas uma porcentagem vai acessar ou também que apenas pessoas do sexo feminino e com mais de 20 anos vão acessar. A parte mais interessante dessa estratégia é conseguir testar na prática, sentir qual a reação das pessoas e se o sistema tem algum bug antes de liberar para todo mundo. 

Qual a melhor hora e dia para fazer deploy?

Nunca faça deploy de sexta! 

Meme sobre fazer deploy na Sexta-Feira
“Faça deploy na sexta-feira, eles disseram… Vai ficar tudo bem, eles disseram…”

Você já deve ter ouvido piadas, memes e brincadeiras sobre o famoso deploy de sexta. Inclusive, existe até um site que te diz se você deveria deployar hoje.

Qual o problema de deployar na sexta? Na verdade, o problema não está no dia da semana, mas sim em fazer um deploy em um momento em que as pessoas já estão cansadas e querendo ir para casa, por exemplo às 17h. Se o deploy apresentar alguma falha, quem vai verificar? E se não tiverem pessoas de plantão e o problema só for percebido na segunda? Serão 2 dias com uma aplicação que não está em sua melhor versão no ar! Esse é o real problema, não é a sexta-feira. 

Agora, outra situação muito diferente é se tiverem pessoas para dar suporte após o deploy, se você tiver um sistema de alertas caso tenha problemas, se alguém conseguir fazer um rollback de forma simples. Aí não há problema algum em deployar às sextas. Mas fora isso, quando é o melhor momento de fazer um deploy?

Quando há uma menor quantidade de usuários ativos

Qual é o momento em que o seu sistema tem a menor quantidade de pessoas online? Esse provavelmente será o melhor dia e horário. Assim, em um cenário pessimista, em que aconteça algum tipo de problema, o número de pessoas impactadas será menor

Com pessoas de plantão

Esse é um outro motivo para você se preocupar na hora de fazer o seu deploy. Você ou outra pessoa estarão acordadas ou monitorando o sistema após seu deploy? Em algumas empresas, existe o conceito de plantão (ou qualquer outro nome que indique uma pessoa responsável por monitorar caso o sistema dê problema) que traz mais segurança para o pós-deploy.

Em qualquer dia e horário

Você provavelmente não precisará se importar tanto assim com o dia e horário do seu deploy se o seu sistema tem um bom acompanhamento, sistema de alarmes e é muito bem testado, além de ter contado com um processo de desenvolvimento que minimiza o número de bugs ou se há uma forma simples e rápida de fazer rollback. 

Existem empresas que fazem muitos deploys por dia e às vezes até deploys simultâneos, então não existe essa preocupação do momento certo para um deploy. Cada caso é um caso e devem ser analisadas várias coisas antes de decisões serem tomadas.

Espero que agora o deploy não pareça mais um bicho de sete cabeças pra você! O deploy é algo totalmente necessário e que você vai esbarrar por vários dias se você for uma pessoa desenvolvedora. Ele é a fase final do desenvolvimento de uma nova funcionalidade ou até mesmo de colocar um projeto inteiro no ar, portanto também é uma grande conquista! 

O mais indicado é que você comece da forma simples e vá incrementando até ter um deploy automatizado e que traga segurança para você e o seu time. Todo primeiro deploy vai causar ansiedade e uma certa insegurança, mas quanto mais automatizado e coberto com testes o seu sistema estiver, mais esse sentimento vai embora. Assim, você poderá ficar feliz em ver uma nova funcionalidade ou correção de bug indo para o ar! 

Gostou desse conteúdo? Então não deixe de ver o nosso post sobre testes automatizados — algo super importante em um processo de deploy!

0 Shares:
Você também pode gostar