sábado, 29 de março de 2014
Depois de quase uma década de trabalho, eu finalmente acho que é hora de publicar o meu projeto mais longo: o sistema de RPG Morpheus. Muito sangue, suor e lágrimas rolaram para chegar nesse modesto arquivo de quarenta páginas. E eu deixei o arquivo disponível para download de graça!
Eu não vou enrolar muito mais aqui, porque já arranjei um falatório danado na página dele. Só uma coisa, quem são sabe o que é RPG, dá uma olhada aqui.
terça-feira, 4 de março de 2014
Testar novos recursos em ambientes de produção é uma prática ruim no desenvolvimento Web, mas tem horas que não tem jeito. Em algum momento a funcionalidade irá para o servidor de produção, e por mais testada que ela já tenha sido, problemas acontecem. Por isso, eu proponho utilizar cookies inseridos manualmente para declarar que um modo experimental está ativo, e impedir que o recurso novo rode quando o cookie não estiver presente.
Para impedir que um sistema que está em uso fique instável por conta de novos desenvolvimentos, é considerado uma boa prática utilizar três instalações diferentes (os tais ambientes): desenvolvimento, testes e produção:
O ambiente de desenvolvimento é utilizado apenas pelos programadores. Ele pode rodar qualquer versão, a qualquer momento, e é populado com dados apenas para testes. Ele é o ambiente mais instável dos três.
Quando o código já está mais maduro, ele é enviado para o ambiente de testes. Este ambiente é utilizado pela equipe de testes para garantir a qualidade do sistema. Tipicamente, o código neste ambiente parece estar pronto, mas provavelmente não está.
Eventualmente o código é considerado estável, e pode ser implantado no ambiente de produção. Esta instalação está em uso pelos clientes, e por conta disso deve ser manuseada com cuidado. Manutenções devem ser bem pensadas, e apenas código estável deve ser inserido aqui.
Existem dois tipos de código que tipicamente são implantados em servidores de produção: atualizações e correções de emergência. As atualizações, mesmo quando corrigem algum defeito, devem seguir o fluxo completo entre os ambientes, sendo criadas no ambiente de desenvolvimento, validadas no ambiente de testes e só então implantadas para produção. Elas podem tranquilamente seguir as boas práticas de desenvolvimento, e se der tudo certo, o código que irá para produção não precisará de nenhum ajuste.
Com as correções de emergência não é bem assim. Existem situações onde correções de emergência devem ser implantadas o quanto antes (afinal, ela são de emergência), e o fluxo de implantação é lento demais para isso. Nesses casos, os desenvolvedores costumam fazer testes rápidos no servidor de desenvolvimento, e implantar códigos bem instáveis direto no ambiente de produção, pulando o de testes.
Sejam atualizações, sejam correções de emergência, código novo em ambientes de produção deve ser manuseado com cuidado. O ideal é que apenas os desenvolvedores tenham acesso à execução do novo código; os clientes devem continuar utilizando o sistema antigo. O problema é que estamos falando de dois tipos de usuários, tendo visões diferentes de um mesmo ambiente. Como o sistema poderia diferenciar entre as duas situações, agindo de acordo para cada uma?
A solução que estou propondo consiste em criar um modo de operação experimental, acessível apenas para o desenvolvedor. Os clientes irão continuar tendo acesso ao sistema original. Portanto, o sistema deve diferenciar entre dois modos:
Uma implementação do modo experimental deve ser muito simples, para não sobrecarregar o trabalho dos desenvolvedores quando eles estiverem codificando correções emergenciais. Felizmente, basta um if ... else e um cookie para dar conta do recado.
se o cookie experimental está ativo
execute versão experimental do recurso
senão
execute versão padrão do recurso
O tal cookie deve ser definido apenas manualmente. Assim, garante-se que o cliente não irá ter acesso a um recurso experimental por engano. Quando o desenvolvedor estiver satisfeito basta deixar apenas a versão nova do recurso. Ele também pode remover o cookie do seu navegador, se quiser.
O nome e o conteúdo do cookie ficam por conta da situação. Verificar se um cookie modo_exp existe ignorando o seu valor, é a solução mais simples. Alternativamente, o cookie pode possuir valores booleanos, e nesse caso o sistema deveria testar o conteúdo do cookie, considerando que se ele não existe então o modo padrão deve ser seguido.
Ofuscar a existência do modo experimental é simples, bastar dar um nome bem estranho para o cookie. Uma string aleatória fica bem escondida a princípio. No entanto, se o recurso oferece algum risco de segurança, é melhor utilizar uma senha para o modo experimental. Basta codificar a senha utilizando o algoritmo SHA1. Para verificar se o modo experimental está ativo, codifique o conteúdo do cookie usando SHA1, e compare com a versão codificada senha. Se bater, então é seguro liberar o recurso. Não se esqueça de definir a senha como o conteúdo do cookie!
Modos experimentais com cookies são uma forma simples e rápida de testar novos recursos em ambiente de produção. Esta estratégia não substitui os ambientes de desenvolvimento e de teste, e por isso deve ser utilizada com cuidado, apenas quando necessário.
Esta solução é um quebra-galho. Uma vez confirmado que o recurso novo está pronto retire todos os códigos que implementam o modo experimental. Deixe apenas o recurso novo, ou então em pouco tempo o código estará repleto de ramificações experimentais, mesmo quando nenhum experimento estiver em curso!
Gostou? Odiou? Comente!
