Quem um dia já não teve uma experiência amarga com a publicação de seu código via FTP? Seja uma publicação mal-sucedida, erros praticamente incontroláveis ou resultados indesejados, divergindo entre o ambiente do Desenvolvedor e o ambiente do cliente? Seu problema pode ser o modo em que você faz o seu deploy.
O mais interessante é que em inglês, um dos significados da palavra ‘deploy’, diz o seguinte:

(Mover tropas ‘ou equipamento’) em posição para uma ação militar.

Ou seja, quando você posiciona seu código para efetivo uso de seus clientes, **significado principal do termo**, um posicionamento incorreto pode significar um desastre completo! Imagine ainda você sendo um comandante de tropa tendo que posicionar seu contingente de forma totalmente manual, sozinho, sem a ajuda de outros oficiais, indicadores ou até ferramentas que possam lhe ajudar? Ou seja, um processo vital para o sucesso de seu projeto, afinal é seu produto que estará no ar, sendo feito de forma quase que totalmente manual!

Será que esse cenário não ocorre hoje em seu ambiente de trabalho?

Ou se ainda não ocorreu, vamos então pensar sobre os motivos pelos quais um deploy manual pode ser um problema:

Segurança

O protocolo FTP começou a ser discutido em 1971 e não possui qualquer preocupação quanto a segurança e privacidade da forma em que os dados são trafegados entre os dois pontos.

Isso significa que, no momento da conexão, seu usuário e senha são enviados ao outro ponto sem qualquer encriptação, sendo vulneráveis a uma possível interceptação caso seu computador ou rede estejam comprometidos com algum malware ou sniffer na rede.

Outro motivo é que não é incomum nos depararmos com credenciais do FTP que possuem acesso total (root) ao ambiente de produção. Portanto além do acesso as pastas da aplicação, este usuário pode acessar logs de sistema, informações sobre dispositivos, arquivos físicos da base de dados e até executar comandos arbritrários.

Apesar do primeiro ponto ser facilmente revertido com o uso do SFTP, que você já encontra configurado na Umbler, temos o problema de ainda contarmos com um processo 90% manual de publicação dos arquivos.

Processo manual

Por melhor qualificado ou mais integrado que seja nosso time, erros são comuns de acontecer e tem um impacto negativo ampliado em momentos de decisão.
Veja por exemplo o seguinte cenário:

Estou usando o Filezilla para subir uma alteração importante (via FTP/SFTP), as 17:29h de sexta-feira, véspera de feriado prolongado. São 22 arquivos, todos eles em diretórios diferentes e espalhados pela aplicação. Eis que ao iniciar o processo o chefe precisa falar comigo urgentemente sobre outro projeto que começa na próxima semana.

O que pode acontecer aqui:

• Você pode ‘perder o fio da meada’ e ao final da conversa, refazer todo o processo;
• Você pode sobrescrever arquivos em produção que não deveriam ser alterados;
• No caso de um erro, você prontamente vai ‘editar direto em produção’, afinal hoje é sexta e falta pouco pra ir embora! Com isso, o versionamento de sua aplicação estará completamente defasado;
• Você alterou em produção mas na pressa, esqueceu de avisar aos colegas de seu time de devs, que vão ficar sabendo apenas quando for a vez deles de subir em produção e encontrar a ‘surpresa’;
• Sua aplicação estará indisponível ao cliente durante esse tempo.

O caos está literalmente instaurado, pois afinal todos estão perdendo dinheiro. O cliente não pensa duas vezes e aciona o help desk, cobrando uma solução para ontem. O chefe já avisa que tudo precisa estar funcionando para hoje e todos os chamados respondidos.

Infelizmente esse cenário ainda é mais comum do que podemos imaginar. É um ambiente nocivo de trabalho cujos processos não estão bem definidos e por ser algo tão constante, acabamos por perder a ideia do quanto perdemos em tarefas tão simples.

Agora pensando num ambiente onde tudo ocorre de forma automática, quais seriam os benefícios?

Configurar o deploy apenas uma vez

A maioria das ferramentas de deploy possuem o chamado ‘one-time setup’. O que significa dizer é que ele precisa ser configurado apenas uma vez e em uma estação de trabalho apenas. Você apenas tem o cuidado de manter os scripts no seu VCS preferido (GIT/SVN);

É só um comando!

Uma vez corretamente configurado e atendendo a suas necessidades, o script de deploy roda com apenas um comando ou um clique. Inclusive se você trabalha com TDD, pode – e deve – integrá-los ao seu deploy.

Deu problema? É só fazer um rollback!

Assim como seu deploy é realizado em um comando, o processo de reverter um app para o seu estado anterior em caso de falha é totalmente automático e sem maior dor de cabeça.

Controle/histórico do que foi publicado

Você agora possui um controle efetivo do que ‘vai para o ar’ em cada publicação. Pode ainda garantir de que não haverá edição do código-fonte em produção de forma indevida ou descontrolada, por alguém que ‘está com pressa em resolver logo’. O Git/Github de sua empresa não mais será aquele ‘disclaimer de novela’:

Esta é uma obra de ficção, qualquer semelhança com nomes, pessoas, fatos ou situações da vida real terá sido mera coincidência

O ‘dia do deploy’ não vai ser aquela data tão temida

Aliás, você verá que as atualizações serão tão mais tranquilas que poderão/deverão ser feitas diariamente e de forma sincronizada com toda a equipe.

Ok, preciso mudar! Por onde devo começar?

Use de forma correta seu Git/Github!

Infelizmente muitas pessoas acabam por utilizar o Git, de uma maneira geral, apenas como um Dropbox de código gratuito, limitando consideravelmente seu potencial. Adotar uma estratégia de fluxo no Git é a chave para melhor uso. Exitem N formas de trabalhar com branches no git, mas uma das mais usadas é o git-flow.

O ambiente de homologação deve ser igual ao de produção

Tenha um ambiente de homologação que reflita de forma quase que identica ao ambiente do cliente. Isso não necessariamente quer dizer que devo ter a mesma quantidade de dados no BD de desenvolvimento, mas as mesmas diretivas de ambiente, aplicação, usuários do sistema e estrutura de diretórios, o que ajuda o desenvolvedor a trabalhar com um cenário mais próximo possivel da realidade.

Testes automatizados, você usa?

Se sim, meus parabéns! Está no caminho certo. Caso contrário, essa é uma boa hora para informar melhor sobre!

Alterações disponíveis e visiveis para todos de sua equipe

Todos devem ver o que você publicou e imediatamente devem obter as mudanças. Estas inclusive devem ser discutidas entre a equipe a fim de não impactar na rotina de trabalho dos outros colegas. Quando esse cenário não for possível, uma mensagem de commit mais elaborada já ajuda e muito.

Dividir para conquistar: isole os problemas e publique aos poucos

Resumindo em uma frase: seu deploy deve refletir apenas a solução de um problema, e um problema apenas! É comum a tentação de um ‘grande pacote’ que resolva todas as tarefas do dia/semana porém quando há um bug, o rollback fica mais difícil.

O que quero dizer, afinal? Que podemos – e devemos – buscar formas para automatizar cada vez mais a forma de nossos deploys. E a automação desse processo pode inclusive signifcar uma mudança real e eficaz, com resultados satisfatórios em curto e médio prazo. Vai significar ainda a redução de retrabalho, o nível de esforço e principalmente a satisfação com seus clientes.

E como a Umbler pensa no bem-estar do time de Jedis de sua empresa, disponibiliza o Deploy automágico via Git/Github de forma rápida e simples.