Por mais de uma vez eu tive que adicionar certas funcionalidades em sistemas que ja estavam em produção. É uma tarefa arriscada pois o serviço não pode parar por algum erro que vc esta introduzindo, ainda mais se este mesmo sistema estiver funcionando sem problemas nos ultimos meses ou anos.
Aprendi um truque bem interessante que, pensando bem, é um tanto obvio: ao adicionar uma funcionalidade onde boa parte do codigo ficou inalterada, pode fazer sentido desabilitar esta nova funcionalidade na configuração. Dessa forma se a porção nova de codigo produzir algum problema é possivel – teoricamente – minimizar os problemas desabilitando temporariamente esta feature.
Nem sempre isto faz sentido, porém não se trata de esconder a sujeita para debaixo do tapete: é de se esperar uma intensa bateria de testes de regressão alem de testes sobre o codigo novo. Conseguimos ter certeza da situação ao olhar os relatorios de cobertura de código, por exemplo. Esta é mais uma tecnica para evitar problemas em algo ja estabelecido.
Imagine que, no ambiente de produção, a nova feature desenvolve um memory leak, ou a escalabilidade dela não é a esperada? Desabilitar na configuração é menos traumatico do que um rollback na aplicação, mas ainda assim é traumatico. Agora, se vc desabilita e o problema continua isso ja dá pistas de que existe um problema em outro lugar – por exemplo na propria porção de código legado.
E vc, como adiciona funcionalidade a um sistema em produção?
Geralmente eu não consigo fazer uma bateria de testes decente. Normalmente uma funcionalidade é pedida na parte da manhã e deve estar pronta à tarde, ou seja, se fizer M, vai ter que trabalhar depois do expediente =\
Pac, ter a possibilidade de “desligar” certas funcionalidades de um sistema é sempre um grande adendo. No caso você lembrou de uma situação onde a funcionalidade pode denegrir a capacidade geral do sistema. Mas existem outros casos, não menos nobres, em que é saudável ter essa capacidade.
Em uma realidade onde você faz subidas frequentes, as vezes a cada item implementado, uma funcionalidade pode estar pronta antes de precisar ser usada. Dar a capacidade ao cliente de habilitar ou não uma funcionalidade baseado na sua vontade é extremamente importante.
muanis
Já fiz isso, e é sempre muito arriscado. Aliás, uma parte muito chata de fazer é quanto a nova funcionalidade exige ‘refatoração’ no banco de dados. O que eu faço é subir um ambiente de testes, testar n vezes, e ainda assim faço a alteração com ansiedade, não tem jeito (eu acho).
@muanis realmente, algumas funcionalidades podem ter data para entrar no ar e isso não precisa impedir a subida do sistema para produção. Ainda mais se vc pensar que uma determinada feature pode ser desativada em um futuro próximo – algo que foge do escopo de uma interface administrativa, por exemplo.
@mayck nesses ambientes onde tudo é ‘pra ontem’ vc lidar com testes, prazo e escopo é um desafio, normalmente um deles vai pro saco se tivermos q trabalhar 8 horas por dia. Porem vc pode criar o habito de desenvolver algum tipo de teste de forma gradual: se vc identifica uma area critica do que vc esta fazendo ou se as regras de negocio estão bem separadas de outras funcionalidades vc tem pontos bem nobres para testar da forma que vc achar melhor.
As vezes um shell script que rode alguns GETs e POSTs através de um curl no mundo unix (ver http://curl.haxx.se/docs/httpscripting.html – funciona no windows via cygwin), por exemplo, fazendo um parsing da resposta na mão através de um grep, podem evitar dores de cabeça no futuro. Ou vc pode fazer algo mais elaborado como usar um Selenium, mas depende, novamente, da situação.
@walter dependendo do sistema isso fica bem emocionante !