Introdução
Há uma prática difundida em projetos de software no mundo todo, o uso de diversos ambientes para a construção de sistemas. Em resumo funciona assim, o sistema é construído num *Ambiente de Desenvolvimento*, passa para um *Ambiente de Homologação* e finalmente vai pra *Produção*.
Um ambiente pode ser entendido como um local físico no computador (uma pasta ou computador) mais um conjunto de softwares auxiliares para execução do produto(software). Nesse ambiente é que fica os aplicativos necessários para que aplicação seja executada. Por exemplo: um projeto web feito em asp, normalmente utiliza os seguinte aplicativos: o servidor web IIS, um SGBD qualquer e os arquivos .asp; num projeto web para Java necessita de um container web, um SGBD, a JVM e os códigos(.class, .jsp). O importante é notar que estes aplicativos devem estar em todos ambientes e com as mesmas versões, para que o desenvolvimento seja eficaz, executável e testável em todos ambientes. A replicação de estrutura entre os ambientes.
Ambiente de Desenvolvimento
Quando se desenvolve (código mesmo) ou dá manutenção nas aplicações de uma empresa usa-se o ambiente de desenvolvimento. Nesse ambiente é que fica o código em desenvolvimento que pode ser testado também, ou seja, gerá código executável (não exe, mas no sentido de código funcional).
Existem vários elementos que fazem parte desse ambiente um deles é o...
Source Code Control: São ferramentas que agilizam o processo de unificar o local onde os códigos ficam, os mais conhecidos são: CVS, SVN e Source Control (MS).
E neste ambiente que os *diversos desenvolvedores constroem o código* e "comitam" ( o ato de jogar o código no servidor de código ) e testam. Obviamente a ferramenta mais utilizada neste local é um IDE (VS2008, Eclipse, Netbeans, DephiSuite ...) e o sistema de versionamento de códigos.
Ambiente de Homologação
O sistema vem pra esse ambiente quando já o mesmo já foi produzido e testado no ambiente de desenvolvimento. Esse ambiente pode ser entendido como *ambiente de testes finais*, antes de ir para o usuário gestor do sistema.
É comum neste ambiente *encontrar falhas*, criar um lista com check-list sobre os erros encontrados e repassar-los aos desenvolvedores, para *fix* (outro termo usado para designar o conserto de alguma falha).
O importante é notar que neste ambiente é *ótimo se os testadores forem externos ao desenvolvimento*, ou seja, outra equipe mesmo irá homologar (o ato de certificar que o software está bom para ir para prateleira) o software, usar a mesma pessoa que desenvolve para homologar pode induzir a falhas terríveis.
Algumas empresas de código fechado, neste ambiente não há como ver o código fonte.
Produção
Aqui o produto já está na mão do usuário final, já está em uso oficial, importante notar aqui se todos os comentários de DEBUG foram limpados do código, se todos os dados fictícios de testes foram removidos, se as senhas para acesso ao SGBD foram trocadas, enfim *aqui é sistema final*.
Versões e nomenclaturas
Quando estamos a procura de um software nos preocupamos com várias coisas como qualidade, quem produziu se o mesmo é grátis, de código fonte, pago...
Muitas vezes nos deparamos com produtos com alguns sufixos como M, B, RV, RC...
Para o entendimento dessas diversas siglas utilizaremos um exemplo simples um sistema de gestão de RH, conhecido como OpenRh.
Se tiver:
*OpenRh.1.0.0.1A * - Significa que o software ainda é Alfa. (testes internos com os testadores da empresa)
*OpenRh.1.0.0.1B* - Significa que o software ainda é Beta. (testes externos com os usuários finais)
*OpenRh.1.0.0.1RC* - Significa que o software é o Release Candidate. (Provável versão final, uma após a B)
*OpenRh.1.0.0.1* - Significa que o software é o final. (Também conhecido como de produção ou ainda stable)
ps: as vezes utiliza-se algumas nomenclaturas como .final ou .stable para definir que o software já está pronto para o mercado.
Para entusiastas ainda há a possibilidade de adquirir software enquanto estão em ambiente de desenvolvimento.
*OpenRh 2.0.0M1* - Significa que o software que teve alguma mudança significativa e assim foi feito um Marco esse marco normalmente é numerado logo pode se ter M1 M2 M3... (Milestone)
*OpenRh 2.0.0R301* - Significa que o software está na revisão 301 no repositório de códigos, aqui a cada commit o usuário (mais fanático) pode testar software feito no dia.
Obviamente esses nomes podem sofrer algumas alterações mas o sentido continua o mesmo.
Ps: Também há o .src que é exatamente o código fonte do projeto em questão.
Conclusão
A principio parece mais burocracia ao desenvolvimento de sistema, todavia as grandes empresas tem notado em experiências sólidas que o uso de diversos ambientes reduzem e muito a quantidade de erros que os sistemas poderiam ter ao serem lançados.
Questões gerenciais ficam bem facilitas com o uso de diversos ambientes. O uso de um repositório de código hoje é essencial, necessário. Seguir boas práticas que grandes empresas seguem pode tornar seus problemas mais gerenciáveis, estar preparado para mudança é o rumo da T.I.
Texto: Autor desconhecido.
Nenhum comentário:
Postar um comentário