Quem um dia j\u00e1 n\u00e3o teve uma experi\u00eancia amarga com a publica\u00e7\u00e3o de seu c\u00f3digo via FTP? Seja uma publica\u00e7\u00e3o mal-sucedida, erros praticamente incontrol\u00e1veis ou resultados indesejados, divergindo entre o ambiente do Desenvolvedor e o ambiente do cliente? Seu problema pode ser o modo em que voc\u00ea faz o seu deploy.
\nO mais interessante \u00e9 que em ingl\u00eas, um dos significados da palavra ‘deploy’, diz o seguinte:<\/p>\n
(Mover tropas ‘ou equipamento’) em posi\u00e7\u00e3o para uma a\u00e7\u00e3o militar.<\/p><\/blockquote>\n
Ou seja, quando voc\u00ea posiciona seu c\u00f3digo para efetivo uso de seus clientes, **significado principal do termo**, um posicionamento incorreto pode significar um desastre completo! Imagine ainda voc\u00ea sendo um comandante de tropa tendo que posicionar seu contingente de forma totalmente manual, sozinho, sem a ajuda de outros oficiais, indicadores ou at\u00e9 ferramentas que possam lhe ajudar? Ou seja, um processo vital para o sucesso de seu projeto, afinal \u00e9 seu produto que estar\u00e1 no ar, sendo feito de forma quase que totalmente manual!<\/p>\n
Ser\u00e1 que esse cen\u00e1rio n\u00e3o ocorre hoje em seu ambiente de trabalho?<\/p>\n
Ou se ainda n\u00e3o ocorreu, vamos ent\u00e3o pensar sobre os motivos pelos quais um deploy manual pode ser um problema:<\/p>\n
Seguran\u00e7a<\/h2>\n
O protocolo FTP come\u00e7ou a ser discutido em 1971<\/a> e n\u00e3o possui qualquer preocupa\u00e7\u00e3o quanto a seguran\u00e7a<\/a> e privacidade<\/a> da forma em que os dados s\u00e3o trafegados entre os dois pontos.<\/p>\n
Isso significa que, no momento da conex\u00e3o, seu usu\u00e1rio e senha s\u00e3o enviados ao outro ponto sem qualquer encripta\u00e7\u00e3o, sendo vulner\u00e1veis a uma poss\u00edvel intercepta\u00e7\u00e3o caso seu computador ou rede estejam comprometidos com algum malware ou sniffer na rede.<\/p>\n
Outro motivo \u00e9 que n\u00e3o \u00e9 incomum nos depararmos com credenciais do FTP que possuem acesso total (root) ao ambiente de produ\u00e7\u00e3o. Portanto al\u00e9m do acesso as pastas da aplica\u00e7\u00e3o, este usu\u00e1rio pode acessar logs de sistema, informa\u00e7\u00f5es sobre dispositivos, arquivos f\u00edsicos da base de dados e at\u00e9 executar comandos arbritr\u00e1rios.<\/p>\n
Apesar do primeiro ponto ser facilmente revertido com o uso do SFTP, que voc\u00ea j\u00e1 encontra configurado na Umbler, temos o problema de ainda contarmos com um processo 90% manual de publica\u00e7\u00e3o dos arquivos.<\/p>\n
Processo manual<\/h2>\n
Por melhor qualificado ou mais integrado que seja nosso time, erros s\u00e3o comuns de acontecer e tem um impacto negativo ampliado em momentos de decis\u00e3o.
\nVeja por exemplo o seguinte cen\u00e1rio:<\/p>\nEstou usando o Filezilla para subir uma altera\u00e7\u00e3o importante (via FTP\/SFTP), as 17:29h de sexta-feira, v\u00e9spera de feriado prolongado. S\u00e3o 22 arquivos, todos eles em diret\u00f3rios diferentes e espalhados pela aplica\u00e7\u00e3o. Eis que ao iniciar o processo o chefe precisa falar comigo urgentemente sobre outro projeto que come\u00e7a na pr\u00f3xima semana.<\/p><\/blockquote>\n
O que pode acontecer aqui:<\/p>\n
\n
- Voc\u00ea pode ‘perder o fio da meada’ e ao final da conversa, refazer todo o processo;<\/li>\n
- Voc\u00ea pode sobrescrever arquivos em produ\u00e7\u00e3o que n\u00e3o deveriam ser alterados;<\/li>\n
- No caso de um erro, voc\u00ea prontamente vai ‘editar direto em produ\u00e7\u00e3o’, afinal hoje \u00e9 sexta e falta pouco pra ir embora! Com isso, o versionamento de sua aplica\u00e7\u00e3o estar\u00e1 completamente defasado;<\/li>\n
- Voc\u00ea alterou em produ\u00e7\u00e3o mas na pressa, esqueceu de avisar aos colegas de seu time de devs, que v\u00e3o ficar sabendo apenas quando for a vez deles de subir em produ\u00e7\u00e3o e encontrar a ‘surpresa’;<\/li>\n
- Sua aplica\u00e7\u00e3o estar\u00e1 indispon\u00edvel ao cliente durante esse tempo.<\/li>\n<\/ul>\n
O caos est\u00e1 literalmente instaurado, pois afinal todos est\u00e3o perdendo dinheiro. O cliente n\u00e3o pensa duas vezes e aciona o help desk, cobrando uma solu\u00e7\u00e3o para ontem. O chefe j\u00e1 avisa que tudo precisa estar funcionando para hoje e todos os chamados respondidos.<\/p>\n
Infelizmente esse cen\u00e1rio ainda \u00e9 mais comum do que podemos imaginar. \u00c9 um ambiente nocivo de trabalho cujos processos n\u00e3o est\u00e3o bem definidos e por ser algo t\u00e3o constante, acabamos por perder a ideia do quanto perdemos em tarefas t\u00e3o simples.<\/p>\n
Agora pensando num ambiente onde tudo ocorre de forma autom\u00e1tica, quais seriam os benef\u00edcios?<\/strong><\/p>\n
Configurar o deploy apenas uma vez<\/h3>\n
A maioria das ferramentas de deploy possuem o chamado ‘one-time setup’. O que significa dizer \u00e9 que ele precisa ser configurado apenas uma vez e em uma esta\u00e7\u00e3o de trabalho apenas. Voc\u00ea apenas tem o cuidado de manter os scripts no seu VCS preferido (GIT\/SVN);<\/p>\n
\u00c9 s\u00f3 um comando!<\/h3>\n
Uma vez corretamente configurado e atendendo a suas necessidades, o script de deploy roda com apenas um comando ou um clique. Inclusive se voc\u00ea trabalha com TDD, pode – e deve – integr\u00e1-los ao seu deploy.<\/p>\n
Deu problema? \u00c9 s\u00f3 fazer um rollback!<\/h3>\n
Assim como seu deploy \u00e9 realizado em um comando, o processo de reverter um app para o seu estado anterior em caso de falha \u00e9 totalmente autom\u00e1tico e sem maior dor de cabe\u00e7a.<\/p>\n
Controle\/hist\u00f3rico do que foi publicado<\/h3>\n
Voc\u00ea agora possui um controle efetivo do que ‘vai para o ar’ em cada publica\u00e7\u00e3o. Pode ainda garantir de que n\u00e3o haver\u00e1 edi\u00e7\u00e3o do c\u00f3digo-fonte em produ\u00e7\u00e3o de forma indevida ou descontrolada, por algu\u00e9m que ‘est\u00e1 com pressa em resolver logo’. O Git\/Github de sua empresa n\u00e3o mais ser\u00e1 aquele ‘disclaimer de novela’:<\/p>\n
Esta \u00e9 uma obra de fic\u00e7\u00e3o, qualquer semelhan\u00e7a com nomes, pessoas, fatos ou situa\u00e7\u00f5es da vida real ter\u00e1 sido mera coincid\u00eancia<\/p><\/blockquote>\n
O ‘dia do deploy’ n\u00e3o vai ser aquela data t\u00e3o temida<\/h3>\n
Ali\u00e1s, voc\u00ea ver\u00e1 que as atualiza\u00e7\u00f5es ser\u00e3o t\u00e3o mais tranquilas que poder\u00e3o\/dever\u00e3o ser feitas diariamente e de forma sincronizada com toda a equipe.<\/p>\n
Ok, preciso mudar! Por onde devo come\u00e7ar?<\/h2>\n
Use de forma correta seu Git\/Github!<\/h3>\n
Infelizmente muitas pessoas acabam por utilizar o Git, de uma maneira geral, apenas como um Dropbox de c\u00f3digo gratuito, limitando consideravelmente seu potencial. Adotar uma estrat\u00e9gia de fluxo no Git \u00e9 a chave para melhor uso. Exitem N formas de trabalhar com branches no git, mas uma das mais usadas \u00e9 o git-flow.<\/p>\n
O ambiente de homologa\u00e7\u00e3o deve ser igual ao de produ\u00e7\u00e3o<\/h3>\n
Tenha um ambiente de homologa\u00e7\u00e3o que reflita de forma quase que identica ao ambiente do cliente. Isso n\u00e3o necessariamente quer dizer que devo ter a mesma quantidade de dados no BD de desenvolvimento, mas as mesmas diretivas de ambiente, aplica\u00e7\u00e3o, usu\u00e1rios do sistema e estrutura de diret\u00f3rios, o que ajuda o desenvolvedor a trabalhar com um cen\u00e1rio mais pr\u00f3ximo possivel da realidade.<\/p>\n
Testes automatizados, voc\u00ea usa?<\/h3>\n
Se sim, meus parab\u00e9ns! Est\u00e1 no caminho certo. Caso contr\u00e1rio, essa \u00e9 uma boa hora para informar melhor sobre!<\/p>\n
Altera\u00e7\u00f5es dispon\u00edveis e visiveis para todos de sua equipe<\/h3>\n
Todos devem ver o que voc\u00ea publicou e imediatamente devem obter as mudan\u00e7as. Estas inclusive devem ser discutidas entre a equipe a fim de n\u00e3o impactar na rotina de trabalho dos outros colegas. Quando esse cen\u00e1rio n\u00e3o for poss\u00edvel, uma mensagem de commit mais elaborada j\u00e1 ajuda e muito.<\/p>\n
Dividir para conquistar: isole os problemas e publique aos poucos<\/h3>\n
Resumindo em uma frase: seu deploy deve refletir apenas a solu\u00e7\u00e3o de um problema, e um problema apenas! \u00c9 comum a tenta\u00e7\u00e3o de um ‘grande pacote’ que resolva todas as tarefas do dia\/semana por\u00e9m quando h\u00e1 um bug, o rollback fica mais dif\u00edcil.<\/p>\n
O que quero dizer, afinal? Que podemos – e devemos – buscar formas para automatizar cada vez mais a forma de nossos deploys. E a automa\u00e7\u00e3o<\/a> desse processo pode inclusive signifcar uma mudan\u00e7a real e eficaz, com resultados satisfat\u00f3rios em curto e m\u00e9dio prazo. Vai significar ainda a redu\u00e7\u00e3o de retrabalho, o n\u00edvel de esfor\u00e7o e principalmente a satisfa\u00e7\u00e3o com seus clientes.<\/p>\n