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:
- O que é Deploy?
- Quais os ambientes de um Deploy?
- Como fazer um Deploy em 6 passos?
- Como funciona um Deploy na prática?
- Boas práticas de deploy para evitar dores de cabeça?
- Quais as formas de fazer um bom deploy?
- Qual a relação do DevOps com a automação de Deploy?
- Integração contínua: o que é CI (Continuous Integration)?
- 6 estratégias para fazer um deploy!
- Quais as vantagens de fazer o Deploy na Nuvem?
- Qual a melhor hora e dia para fazer deploy?
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.
Não confunda “implantar” com “implementar”
Apesar de ambos os termos terem quase a mesma escrita, eles possuem um significado oposto quando o assunto é tecnologia.
Quando você está iniciando um projeto na linguagem de programação de sua preferência, ele está, no momento, sendo implantado, já que essa palavra está relacionada a algo que está sendo iniciado, seja ela um projeto ou protótipo.
Por outro lado, quando o sistema que construímos já está sendo utilizado por clientes finais, dizemos que o projeto foi implementado com êxito, já que, quando implementamos algo, estamos colocando isso em prática, seja ele um projeto, um novo estilo de vida, etc.
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.
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!
Como funciona um Deploy na prática?
Vamos demonstrar agora como é feito o deploy de um site estático no GitHub Pages.
Inicialmente, a estrutura que será utilizada será a da imagem a seguir. Como nosso deploy será de um site em formato estático, que não terá tantas mudanças com o tempo, o ideal é armazenar os arquivos em uma única pasta, sejam eles scripts JavaScript, imagens, arquivos .php e folhas de estilo.
A primeira coisa a se fazer para subir sua aplicação no GitHub Pages é ter uma conta criada no GitHub. Caso não a tenha, basta acessar este link. Também é necessário ter o Git instalado em sua máquina. Caso não tenha, acesse o link do site oficial do Git, que fornece o passo a passo para sua instalação.
Para começar, devemos clicar em criar um repositório, clicando em New:
Depois, adicione um título e uma descrição qualquer. O repositório deverá ser público. Após isso, clicar em CREATE REPOSITORY, ao final da página:
Observação: o título do repositório aparecerá no link de acesso ao site.
Se o processo foi feito da forma correta, a próxima tela aparecerá a você, informando que o repositório foi criado com sucesso.
Após isso, basta clicar no botão direito de sua página que contém os arquivos que deseja subir no GitHub. Já com os arquivos carregados nela, clique em GIT BASH HERE:
Abrirá uma espécie de terminal a você:
Agora, vamos precisar iniciar o Git. Para isso, você deve digitar o comando:
git initE apertar Enter. Depois, para adicionar todos os arquivos da pasta, digite o comando:
git addFeito isso, você precisará “comitar” (subir) os arquivos. Para isso, digite o comando:
git commit -m “Initial commit”Ele subirá os arquivos da pasta, conforme você pode ver na imagem:
Depois, deverá ser copiado o comando que o GitHub forneceu após a criação do remoto para manter a sincronia do repositório com a sua máquina. Para isso, digite o comando:
git remote add origin…Após apertar Enter, envie os arquivos de uma vez ao repositório do GitHub digitando o comando:
git push -u origin masterSe o processo for feito da forma correta, os arquivos aparecerão no seu repositório após atualização da página.
Agora, para que o GitHub Pages entre em ação, clique em SETTINGS, à direita de seu repositório. Depois, em OPTIONS, aparecerá a opção do GitHub Pages para disponibilizar seu site nele. Para isso, você deverá escolher:
- A branch master;
- O folder/docs;
- Um tema, opcional;
- Personalização de domínio, também opcional.
Feito isso, por fim, o GitHub irá disponibilizar o link de acesso ao site:
E, assim, seu site poderá ser acessado através do link indicado.
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.
Qual a relação do DevOps com a automação de Deploy?
A relação entre DevOps e automação de Deploy é a rapidez com que os processos podem ser feitos, de forma que todos conversem a mesma língua com relação às configurações de ambiente, de portas, dentre outros.
Inicialmente, a equipe responsável pelo serviço de automação de deploy passará por um treinamento do que é o DevOps e seus principais objetivos. Por mais que os setores de desenvolvimento e operações, em algumas empresas, sejam separados, para alcançar melhores resultados, é necessário um teste de integração, uma tentativa.
Essa integração terá como foco a interação entre as equipes de desenvolvimento e de operações para que tudo flua da maneira correta, que a comunicação seja eficiente e todas as pessoas estejam alinhadas sobre como será feita a publicação de uma aplicação.
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:
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.
Multi-service
Em uma implementação de vários serviços, todos os nós em um ambiente de destino são atualizados com vários novos serviços simultaneamente. Essa estratégia é usada para serviços de aplicativo com dependências de serviço ou versão. Também pode ser utilizada se você estiver implantando fora do horário de expediente em recursos que não estão em uso.
Basic
Em uma implementação básica, todos os nós em um ambiente de destino são atualizados de forma simultânea com um novo serviço ou versão de artefato. Por causa disso, as implantações básicas não são à prova de interrupções e retardam os processos ou estratégias de reversão.
De todas as estratégias de implantação compartilhadas, essa é a mais arriscada, pois durante o deploy basic você poderá quebrar alguma parte em funcionamento de sua aplicação, quebrar algum estilo, etc.
A/B Testing
Essa estratégia de deploy funciona da seguinte forma: digamos que você esteja em dúvida em qual experiência do usuário ficará melhor em um carrinho de compras. Você, então, tem duas versões desse carrinho e quer saber qual deles tem a melhor usabilidade. Para isso, você liberará uma parte (A) para um grupo de pessoas testar e outra parte (B) para outro grupo de pessoas testar.
Dessa forma, os grupos darão a sua opinião sobre qual interface é a mais amigável em ser utilizada e, a que tiver mais votos, vence. É assim que é realizada a metodologia do teste A/B.
Quais as vantagens de fazer o Deploy na Nuvem?
Vejamos, a seguir, algumas vantagens existentes em realizar o deploy na nuvem:
- Economia de custos: principalmente porque os serviços em nuvem são baseados no uso, economizando custos relacionados a recursos ociosos ou excesso de capacidade;
- Inovação e colaboração: implantação mais fácil e rápida, flexibilidade inerente e provisionamento principalmente consumerizado significam que várias partes de sua organização podem experimentar e dimensionar rapidamente.
- Pense no futuro: os fatores a serem considerados ao pensar no uso futuro da solução são escalabilidade, extensibilidade, novos recursos e terminais. Com essas considerações, o design da solução pode precisar incorporar futuras migrações ou adoção de vários tipos de arquiteturas de nuvem.
Pense no ciclo de vida e na prontidão: as organizações adotariam a nuvem e os aplicativos que a nuvem permite de diferentes maneiras. Pode haver várias políticas, conformidade e aspectos culturais a serem considerados.
Qual a melhor hora e dia para fazer deploy?
Nunca faça deploy de sexta!
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!
