Como você trabalha em pacotes Oracle em um ambiente colaborativo, controlado por versão?

Question

Eu estou trabalhando em um ambiente multi-desenvolvedor no Oracle com um grande pacote. Temos um DEV => TST => PRD padrão promoção. Atualmente, todas as edições do pacote são feitas diretamente no SAPO e, em seguida, compilado no pacote DEV.

Nós executado em dois problemas:

1. mudanças simultâneas devem ser promovidos em diferentes horários. Por exemplo, desenvolvedor A faz uma mudança que precisa ser promovido amanhã, enquanto desenvolvedor B está simultaneamente a trabalhar em uma mudança que não será promovido por mais duas semanas. Quando chega a hora da promoção, nos encontramos manualmente comentando coisas que não está sendo ainda promovido e, em seguida, descomentando-lo depois ... eca !!!

2. Se dois desenvolvedores estão fazendo mudanças ao mesmo tempo exato e um deles compila, ele apaga as alterações do outro desenvolvedor. Não é uma boa fusão; em vez das últimas vitórias de compilação.

Que estratégias você recomendaria para contornar este problema? Estamos usando TFS para nossa de controle de origem, mas ainda não têm utilizado esta com nossos pacotes Oracle.

PS Eu vi desta postagem , mas não responde totalmente à minha pergunta.

Answer 1

da Oracle Developer Tools para Visual Studio.NET ... plugs para a direita em TFS

Answer 2

A chave é adotar uma prática de apenas a implantação de códigos do sistema de controle de origem. Eu não estou familiarizado com a TSF, mas ele deve implementar os conceitos de branches, tags, etc. A questão do que para implantar, em seguida, cai fora da compilação e liberação de marcação no sistema de controle de origem.

Dicas adicionais (para Oracle):

• Ele funciona melhor se você dividir a especificação pacote e corpo em diferentes arquivos que usam um padrão de arquivo consistente para cada (por exemplo, ".pks" para esp pacote, e ".pkb" para o corpo do pacote). Se você usar um processo de criação automatizado que pode processar padrões de arquivos, então você pode construir todas as especificações e, em seguida, os corpos. Isto também minimiza invalidations objeto se você está apenas a implantação de um corpo de pacote.

• colocar o tempo para configurar um processo de compilação automatizada que é conduzido a partir de uma versão ou estado construção de seu sistema de controle de origem. Se você tem mesmo um número moderado de código db objetos ele vai pagar para ser capaz de construir o código em um sistema de referência e compará-lo ao seu qa ou produção do sistema.

Answer 3

Consulte minha resposta sobre para trabalhar com armazenados procedimentos no Oracle, em uma equipe (que acabo retagged).

A linha inferior: não modifique os procedimentos diretamente com SAPO. Armazenar a fonte como arquivos, que você vai armazenar no controle de origem, modificar, em seguida, executar.

Além disso, eu recomendo que cada desenvolvedor trabalha em sua própria cópia do banco de dados (uso Oracle Express, que é gratuito). Você pode fazer isso se você armazenar todos os scripts para criar o banco de dados no controle de origem. Mais visão pode ser encontrada aqui .

Answer 4

Para evitar 2 desenvolvedores trabalhando no mesmo pacote, ao mesmo tempo:

1) Use o seu sistema de controle de versão como a fonte do código de pacote. Para trabalhar em um pacote, o desenvolvedor deve primeiro verificar o pacote de controle de versão; ninguém mais pode verificar o pacote até que este desenvolvedor verifica-lo novamente.

2) Não trabalhar diretamente sobre o código de pacote em Toad ou qualquer outro IDE. Você tem nenhum indício se o código que você está trabalhando lá está correta ou foi modificado por um ou mais outros desenvolvedores. O trabalho sobre o código no script de ter verificado a partir de controle de versão, e executar esse no banco de dados para compilar o pacote. Minha preferência é usar um editor de texto agradável (TextPad) e SQL Plus, mas você pode fazer isso em Toad também.

3) Quando terminar, verifique a volta script em controle de versão. NÃO copiar e colar o código do banco de dados em seu roteiro (ver ponto 2 novamente).

A desvantagem (se for um) desta abordagem controlada é que apenas um desenvolvedor de cada vez pode trabalhar em um pacote. Isto não deve ser um grande problema, desde que:

• Você mantém pacotes para baixo para um tamanho razoável (em termos do que eles fazem, e não como muitas linhas de código ou número de procedimentos neles). Não tem um pacote grande que contém todo o código.
• Os desenvolvedores são encorajados a verificar código só quando estiver pronto para trabalhar sobre ela, e para verificá-lo de volta tão logo eles têm tomada acabado e testar suas alterações.

Answer 5

fazemos isso com um banco de dados Dev para cada fluxo e rótulos para as diferentes correntes.

O nosso Oráculo de licenciamento nos dá dev ilimitado / instâncias de teste, mas somos um ISV, você pode ter uma opção de licenciamento diferente

Answer 6

Você pode usar as ferramentas de desenvolvimento Oracle para VS ou você pode usar desenvolvedor sql. integra desenvolvedor SQL com Subversion e CVS e você pode baixá-lo gratuitamente. Veja aqui: http://www.oracle.com/technology /products/database/sql_developer/files/what_is_sqldev.html

Answer 7

Nós usamos Toad for Oracle com o provedor TFS MSSCCI contra TFS 2008. Nós usamos um Custom Tool esse banco de dados puxa checkins de controle de origem e pacotes para lançamento.

A meu conhecimento Ferramentas Oracle Developer para Visual Studio.Net não tem qualquer integração de controle de origem real com TFS ou de outra forma.

Você pode considerar Toad extensões para o Visual Studio embora não seja barato, talvez $ 4k eu acho.

Outra opção é o a Oracle Mudança Management Pack mas acredito que exige a edição Enterprise do Oracle, que é muito mais caro.