Artigo: Dicas sobre promoçao de código entre ambientes

Ultimamente tenho trabalhado muito com a questão de ambientes e principalmente a promoção de código. Se por um lado nós progamadores não somos promovidos com tanta velocidade, o código no entanto, muitas vezes é promovido mais rápido do que deve. (piadinha de TI sempre é complicado, mas essa ficou engraçadinha vai, voce pelo menos pensou: putz não acredito que ele escreveu isso). O código sai da nossa maquina para um ambiente de homologacao (QA) e em seguida para a produção. Em alguns lugares há outros ambientes envolvidos. Cada ambiente é um ecossistema diferente , com configuracoes, permissões, softwares, componentes , enfim tudo pode ser diferente e mesmo assim o código "tem" que rodar e se moldar ao ambiente onde está. Bem esse tem sido o foco dos meus estudos ultimamente.

Relacionado a isso tenho usado um elemento que muita gente não conhece ou conhece mas não aproveita todo o seu poder. Eu, por exemplo, começei a dar mais atenção a isso há não muito tempo atrás.

Bem todos voces ja viram que ao lado do "Play" para rodar a aplicacão no Visual Studio.NET , há uma combo onde você define se voce vai rodar em modo Debug ou Release, também conhecido como Solution Configurations. Podemos tirar vantagem disso ao invés de lotar nosso código com chaves do web config. Basicamente o modo em que estamos compilando define quem estará utilizando a aplicação. Basicamente existem dois perfis macro de pessoas que podem ter algum tipo de contato com aplicação: aqueles que estão construindo a aplicação e aqueles que utilizam a aplicação. Nao confunda com perfil de usuário, que são as formas de um usuário acessar, mas são todos usuários finais do sistema. Porém, um desenvolvedor constrói a aplicação mas precisa testar como se fosse um usuário em muitos casos. Algumas vezes é possivel criar um usuário no banco de dados e dar algumas permissões e fazer o desenvolvedor utilizar essa conta e a aplicação se comportará exatamente como um usuário final. Mas quando a complexidade do ambiente aumenta fazer isso fica complicado. Por exemplo, imagine que voce tem um relatório que só pode ser acessado por usuários do grupo gerência do Active Directory. Um desenvolvedor programa essa funcionalidade que verifica o grupo do usuário logado na master page e o outro programador faz o relatório usando a master page. Como nosso pobre amigo que está programando o relatório poderá testar o seu código se ele não consegue mais acessar a página? Podemos resolver isso de várias formas, algumas bonitas outras nem tanto. Um solução que eu considero bonita é usar o recurso de Debug/release para diferenciar quem está pilotando a aplicação. Funciona assim: se estou rodando em debug mode significa que eu sou um desenvolvedor entao a aplicação não precisa verificar se eu faço parte do grupo de gerência ou não. Uma vez meu relatório pronto, eu posso rodar em release mode, que significa como a aplicação irá se comportar para os usuários. Eu acho que dessa forma o processo de desenvolvimento fica mais produtivo do que adicionar uma chave do tipo "emDesenvolvimento=true" no web.config e ficar chaveando por ele. Lembre-se: web.config também é gente, ops, quer dizer, web.config também é código , sujeito a source control, versionamento,e você corre o risco de não poder dar check out porque alguem deu lock no arquivo, etc.

Para essa mágica de Debug/Release funcionar é necessário colocar uma diretiva de compilação no código onde voce quer haja um comportamento diferente dependendo do mode em que está a aplicação esta rodando. Vejamos um exemplo de uma função que verifica se o usuário faz parte do role "gerencia" utilizando o conceito de compile mode.

public bool VerificaAcessoGerencia()

{

#if DEBUG


return true;


#else

return this.User.IsInRole("gerencia");

#endif

}

Basicamente estamos verificando se a aplicação está rodando em Debug mode. Se estiver, vamos sempre retornar true, caso contrário vamos fazer o que realmente deve ser feito, procurar pela role "gerencia" na coleção de roles do usuário logado.

Muita atenção agora para alguns detalhes:

- Na hora de publicar o seu código para outro ambiente, certifique-se de que voce compilou em Release mode, do contrário voce estará levando lógica errada para ambiente errado e vai ser complicado de descobrir (ou melhor, de lembrar) o que está causando todo o transtorno.

- Se voce está utilizando blocos de código completamente diferentes ou utilizando essa diretiva descontroladamente, compulsivamente , cuidado voce pode estar querendo resolver outros problemas que não tem nada haver com ambientes ou compilation mode. Use o bom senso para essas decisões.

É possivel criar outras modos de compilação, (novas solution configurations), o que eu considero um próximo passo, mas apenas para ambientes mais complexos, por exemplo, se voce precisar testar o código de forma diferente em cada servidor numa arquitetura de load balance. Acredito que somente debug/release cobre 95% dos casos.

Utilizando esse recuros fica para o web.config apenas as diferenças entre os ambientes (path de arquivos em prod e QA, por exemplo), deixando para o compilation mode toda essa questão de diferenciar a maneira como o sistema se comporta. Isso vai auxiliar o desenvolvedor nos testes, otimizar o processo de desenvolvimento e trazer mais qualidade ao seu build.

Este artigo foi publicado no site Linha de código confira: http://www.linhadecodigo.com.br/Artigo.aspx?id=1724

Até a próxima!