Ambiente de Desenvolvimento e Testes

[Tinho]

Caros DBAs de plantão.

Sou analista e desenvolvedor PL/SQL e não conheço muito de administração de banco, apenas aquilo que li e um pouco da arquitetura.

No entanto, no atual cliente que estou trabalhando é recorrente o problema com o ambiente de desenvolvimento, popularmente, conhecido como "ninguém é de niguem" uma zona aberta, onde são permitidas alteração nos dados, mudança nas estruturas dos objetos. Além disso ou em decorrência disso, existem muitos objetos inválidos, lockados, dados desatualizados, etc.

Devido a complexidade do sistema, muitos dos objetos (a maioria) utiliza variáveis globais que são inicializadas no inicio do processo de execução dos mesmos, seja via jobs ou mesmo pela aplicação. Esses mesmos objetos, são desenvolvidos utilizando conceito de objeto-relacional encadeados, ou seja, dentro de uma determinada package principal, existe um infinidade de outras chamadas a outros objetos que retornam valores para objetcs types/record, que posteriormente são lidos por outras chamadas a outros objetos, e por ai vai.

Por isso, com esse cenário exposto acima, toda vez que é feita uma modificação em qualquer dos objetos, é quase impossível testar em desenvolvimento, seja debugando o objeto em questão, ou ate mesmo pela propria aplicação que trava.

Mesmo alterando os cursores gigantes que cada objeto tem, fixando "hardcode" para restringir a quantidade de linhas retornadas é extremamente lento e estressante. Ainda, caso se queira interromper o processo de debug é pior, trava a aplicação. O que as vezes resolve é desplugar o cabo de rede.

Recentemente entrei em uma discussão, alegando que precisamos das ferramentas adequadas para poder trabalhar e uma delas seria ter um ambiente de testes que funcione. Daí começam aquelas discussões redundantes e paradoxiais. De que não pode subir alterações para homologação sem testar, por outro lado os desenvolvedores argumentam não ter condições e quem de fato teria poder para mudar isso não o faz ou não o quer fazer.

Mas como falar é fácil, gostaria de saber a opinião dos DBAs se é possível manter um ambiente desenvolvimento funcionando de modo que apesar das alterações permitidas ainda seja possível efetuar testes? Ou o que causa tanta morosidade no processo de debug?

[dr_gori]

Não sou DBA, mas nas empresas que eu já trabalhei é bem comum ter diversas bases.

já vi assim:
Teste e produção.
Desenvolvimento, teste e produção.
Fábrica de software, desenvolvimento, teste e produção.
Desenvolvimento, teste, performance, pre-produção, produção.

Não é todas empresas que conseguem manter uma estrutura assim. Talvez optem pelo mais simples, afinal, infra-estrutura é cara.

Uma coisa que ajuda bastante nesses casos é a virtualização, pois facilita bastante a criação e clone de instancias.

[Tinho]

Obrigado pela contribuição dr_gori.

Talvez a virtualização realmente fosse uma alternativa viável neste caso.

Mas será que não seria possível também criar uma tablespace para cada grupo de projetos por exemplo? Exemplo:

CLIENTE A
- projeto X
- tablespace TBS_A_X -> e aqui conter todos os objetos relacionados ao projeto e que cada membro da equipe pudesse "locka-lo" e usar da maneira que fosse necessária;

E assim sucessivamente.

Por que eu fico imaginando a seguinte situação. O que aconteceria ou como o Oracle gerencia, caso eu esteja num processo de testes/debug e alguém recompila o objeto que eu estou usando com outra versão? Eu acho que o Oracle isola isso por sessão, não permitindo que as alterações reflitam no meu teste. Mas caso eu interrompa o teste e reabra o objeto para edição/alteração penso que neste caso estariam aplicadas as alterrações da ultima compilação, correto?

Att.,

[adrianoturbo]

O ideal seria ter além do ambiente de Testes ,ter o de homologação ,mas sabemos que algumas empresas não investem nisso ,o de Testes seria o mínimo ,mas muitas das vezes temos que apelar para a virtualização mesmo.
No mundo perfeito o ambiente de Testes deveria ser igual o de produção,mas muitas das vezes não é isso que acontece ,por causa das crifra$ .

[crishpg]

Tinho,
o melhor dos mundos é mesmo criar um ambiente desenvolvimento(ambiente para os programadores alterarem e testarem regras de negocio).
Ambiente de Testes(Copia da base de produção), nesse server deve ser executado testes pelos usuários das regras de negocio quando tem alguma duvida etc.
Ambiente de produção, exclusivo para uso dos aplicativos.. exemplo ERP etc, mantendo sempre um bom backup etc.
Você vai ter que explicar para seu gerente das vantagens desse tipo de estrutura, que para poder ganhar pontos referente a valores.. aderindo ao ambiente virtualizado.
qualquer coisa estamos a disposição.