Migrando aplicações sem precisar migrar de emprego

Migração. Eis uma palavra que pode assustar vários developers que iniciam suas aventuras no universo devops[^1]. O que realmente isso significa? O que isso traz? E melhor, como executar uma com maestria e baixo risco de colocar tudo a perder?

Cenário

Você tem um software funcionando, porém, recentemente ficou sabendo de novas funcionabilidades que irão totalmente contra ao que você tem atualmente. Nessa hora você pensa: mas como eu irei ajustar todos os dados gerados até agora? Como migrarei contas de usuários, informações privadas e adicionar novas constraints às contas que até agora não precisavam disto? Pois é, amigo. Welcome aboard!

Eu realmente preciso migrar ?

A primeiríssima coisa necessária é: entender o real motivo em seu cenário atual. Isto é: aonde está e para onde irá o sistema com as novas features. Elas realmente confrontam seu system state atual? Algumas vezes, percebemos que a nova feature requer apenas novos dados dos quais nós (developers, devops e curiosos) não teremos como inputar para toda a base atual. Isto resulta em uma tarefa simples: criar um plano de atualização cadastral. Você pode utilizar-se de notificação por e-mail ou/e forçar um update após o login do seu cliente. Sem modificações, sem migrações. YAY!

The rockin’ plan!

Ok, infelizmente não há como executar um update via usuário. A área de operações forneceu uma planilha imensa com os dados e não temos como inserir um a um. Precisaremos migrar dados.

Tudo começou…

… com um plano! Quanto mais refinado, melhor – ou devo dizer: quanto mais refinado, menor a chance de dar tudo errado às 5am ?!

O ponto é: você precisa traçar um plano. É necessário ter começo, meio e fim. Nas primeiras linhas escritas, haverão vários vazios vertendo dúvidas e incertezas. Isto faz parte e você vai preenchendo as lacunas vazias com o passar dos dias. Conforme vai escrevendo seu plano em (uma) folha de papel, indagará uma coisa importante: o que eu farei se alguma coisa der errado?

Você não fará!

Nem sempre você terá um rollback passível de execução – e isto é normal!
Neste momento você sentirá frio, calor, suor e medo, muito medo. Perceberá que é tudo ou nada. É aí que você percebe que você precisa garantir 100% que seu plano funcione.

Automatize tudo que for possível

Parte importante do seu plano é criar tantos scripts quanto possível para realizarem a tarefa para você. O ideal é que durante a migração, você apenas rode uma sequência de comandos que farão todo o trabalho para você. Assim, a chance de esquecer alguma coisa ou fazer alguma coisa não esperada, reduz para menos de 10%.

Rubistas já começam a pensar em Rake Tasks; PHPístas começam a pensar em alguma espécie de recipe – esse é o espírito! 🙂

Defina a ordem de execução

Devo migrar as contas de usuário antes ou depois de definir as categorias dos clientes? Crio a conta deles no ambiente novo ou deveria atualizar a base existente que não contém o plano do usuário?

A ordem de execução é importante e deve ser seguida à risca. Não é possível criar a conta do cliente no novo ambiente o qual requer que todos tenham planos, correto? Logo, a definição do plano por cliente vem como premissa do primeiro item.

Anote em papel todos os steps-to-heaven que você precisará executar. Isto ajudará você a entender melhor da onde está saíndo e para onde chegará após a migração. Neste processo, você encontrará scripts faltantes e até scripts desnecessários.

Practice, Practice, Practice.

Tenho o plano, os scripts e a ordem. O que falta?

Como diria Chad Fowler em seu livro The Passionate Programmer: “você não pode chegar no trabalho para executar algo que nunca tentou antes. Você precisa praticar antes do show acontecer.”

Você precisa praticar. Praticar MUITO!

Seus scripts funcionam individualmente? E dentro do contexto de migração? Se algum falhar ou rodar pela metade, poderei rodá-lo novamente sem prejuízo aos dados já migrados? Atomicidade aqui é vital para uma migração. Você pode e deve considerar o pior cenário: Internet lenta, timeout em conexão com o servidor, etc.

Execute e reexecute os scripts por várias vezes ao longo do período pré-migração. Rode com poucos dados e com muitos dados armazenados. Acompanhe e verifique se está tudo funcionando como deveria. Não deixe de testar também no seu ambiente de staging. Melhor falhar cem vezes agora do que uma vez em produção, não é mesmo?

Momento da migração

Chegou a hora. Você acordou pontualmente às 4hs da madrugada. Parou os serviços que serão afetados e saiu atualizando os softwares de dentro pra fora, ou seja, do mais interno para o mais público dos sistema afetados pela migração. Você visualiza aquela folha com seu plano toda rabiscada e reeditada, já decorada pela sua mente e então começa a migrar.

Caso tenha executado toda a via sacra, provavelmente não terá problemas dos quais não consiga facilmente contornar – isto se houver problemas!

Ambiente migrado, paz interior reestabelecida. Moment of Glory, developer!

Para fechar, acompanhe atentamente o dia de trabalho dos seus usuários para garantir que tudo está como deveria. Se você estiver apoiado com logs ativos (Loggly, Papertrail[^2]), melhor ainda! Há a possibilidade de configurar alertas para você receber em tempo real possíveis traces com problemas enfrentados pelo seus usuários por e-mail ou Campfire[^3]!

Se você não utiliza um recurso assim, recomendo e muito que o faça o quanto antes!

Recipe para migração

Eis um resumão:

  • Verifique a necessidade da migração;
  • Defina um plano de ação;
  • Codifique scripts que farão todo o trabalho por você, faseando-os por atividade dentro da migração;
  • Crie uma ordem de execução dos scripts. Há precedência e pré-requisitos a validar;
  • Pratique muito antes de tentar em produção;
  • Execute em produção, e;
  • Acompanhe o dia dos seus usuários, prestando suporte passivo e ativamente.

[1]: devops é um desenvolvedor de software que assume papel/chapéu de operação do servidor de aplicação.
[2]: Papertrail é um SaaS que salva vidas quando o assunto é logrotate pesquisável, trackeável e alertável via e-mail, Campfire e outros.
[3]: Campfire é um SaaS para chat colaborativo muito simples e útil para se trabalhar em equipe. Uso e recomendo!

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s