¿Cómo funciona el trabajo en paquetes de Oracle en un entorno de colaboración, la versión de ambiente controlado?

Question

Estoy trabajando en un entorno con varios programadores en Oracle con un paquete grande.Tenemos un DEV => TST => PRD promoción patrón.En la actualidad, todos los paquetes de las ediciones se realizan directamente en SAPO y luego compilado en el DEV paquete.

Nos encontramos con dos problemas:

1. Los cambios simultáneos deben ser promovidos en diferentes horarios.Por ejemplo, Un desarrollador hace un cambio que debe promoverse la mañana, mientras que el desarrollador B está funcionando simultáneamente en un cambio que no será promovido por otras dos semanas.Cuando se trata de la promoción de la época, nos encontramos manualmente comentando cosas que no está siendo promovida sin embargo y, a continuación, eliminar el comentario después...puaj!!!

2. Si dos desarrolladores están haciendo cambios en el mismo tiempo exacto y uno de ellos se compila, se borra el otro promotor de cambios.No hay una buena combinación;en lugar de la última compilación gana.

¿Qué estrategias recomendaría usted para conseguir alrededor de esto?Estamos utilizando TFS para nuestro control de código fuente pero que todavía no han utilizado esta con nuestros paquetes de Oracle.

P. S. He visto este la publicación, pero eso no responde a mi pregunta.

Answer 1

de Oracle Developer Tools para Visual Studio.NET ... se conecta a la derecha en TFS

Answer 2

La clave es adoptar una práctica de solamente el despliegue de código desde el sistema de control de origen. No estoy familiarizado con TSF, pero debe poner en práctica los conceptos de ramas, etiquetas, etc. La cuestión de qué desplazar luego cae fuera de la acumulación y liberación de marcado en el sistema de control de código fuente.

consejos adicionales (por Oracle):

• funciona mejor si se divide la especificación del paquete y el cuerpo en diferentes archivos que utilizan un patrón consistente para cada archivo (por ejemplo, ".pks" para especificaciones paquete, y ".pkb" para el cuerpo del paquete). Si se utiliza un proceso de construcción automatizado que puede procesar patrones de archivo entonces se puede construir todas las especificaciones y luego los cuerpos. Esto también minimiza invalidaciones objeto si sólo implementa un cuerpo del paquete.

• poner el tiempo en configurar un proceso de construcción automatizado que es impulsado desde una versión o construir el estado de su sistema de control de código fuente. Si usted tiene incluso un número moderado de código de objetos DB va a pagar para ser capaces de construir el código en un sistema de referencia y compararla con el control de calidad o sistema de producción.

Answer 3

mi respuesta sobre Herramientas para trabajar con almacenada procedimientos en Oracle, en un equipo (que acabo de reetiquetado).

En pocas palabras: no modificar los procedimientos directamente con SAPO. Almacenar la fuente como archivos, que se almacenará en el control de código fuente, modificar luego ejecutar.

Además, lo recomiendo encarecidamente que cada desarrollador trabaja en su propia copia de la base de datos (Oracle utilizar Express, que es gratuito). Usted puede hacer eso si almacena todas las secuencias de comandos para crear la base de datos de control de código fuente. Una visión más clara se puede encontrar aquí .

Answer 4

Para evitar 2 desarrolladores que trabajan en el mismo paquete al mismo tiempo:

1) el Uso de su sistema de control de versiones como la fuente del código de paquete.Para trabajar en un paquete, el desarrollador debe primero retirar el paquete de control de versiones;nadie puede comprobar el paquete hasta que este desarrollador comprueba de nuevo.

2) no trabajan directamente en el código de paquete en Sapo o cualquier otro IDE.Usted tiene ni idea si el código que está trabajando no es correcto o ha sido modificado por uno o más de otros desarrolladores.El trabajo sobre el código de la secuencia de comandos que ha desprotegido a partir de la versión de control y de ejecución que en la base de datos para compilar el paquete.Mi preferencia es usar un buen editor de texto (TextPad) y SQL Plus, pero usted puede hacer esto en Sapo demasiado.

3) Cuando haya terminado, compruebe la secuencia de comandos de nuevo en el control de versiones. No copie y pegue el código de la base de datos en su archivo de comandos (ver punto 2).

El inconveniente (si es uno) de esta controlado enfoque es que sólo un desarrollador en un momento se puede trabajar en un paquete.Esto no debería ser un gran problema, siempre y cuando:

• Mantener los paquetes a un tamaño razonable (en términos de LO que hacen, no de cuántas líneas de código o número de procedimientos en ellos).No tiene un gran paquete que contiene todo el código.
• Se anima a los desarrolladores a retirar código sólo cuando esté listo para trabajar en él, y a la verificación de nuevo tan pronto como se ha terminado de construir y probar sus cambios.

Answer 5

lo hacemos con una base de datos para cada flujo de Dev, y etiquetas para las diferentes corrientes.

Nuestra licencias Oracle nos da dev ilimitada / instancias de prueba, pero estamos un ISV, usted puede tener una opción de licencia diferente

Answer 6

Puede utilizar las herramientas de desarrollo de Oracle para VS o puede utilizar desarrollador sql. desarrollador de SQL integra con Subversion y CVS y se puede descargar de forma gratuita. Ver aquí: http://www.oracle.com/technology /products/database/sql_developer/files/what_is_sqldev.html

Answer 7

Utilizamos Toad para Oracle con el proveedor de TFS MSSCCI contra TFS 2008. Utilizamos un Herramienta personalizada que tira de la base de datos confirmaciones de control de código fuente y los paquetes para su liberación.

A mi conocimiento de Oracle Developer Tools para Visual Studio.Net no tiene ningún tipo de integración de control de origen real con TFS o de otra manera.

Extensiones del sapo para Visual Studio aunque no es barato, tal vez $ 4k Creo.

Otra opción es la Oracle Cambio del módulo de administración pero creen que requiere la edición Enterprise de Oracle que es mucho más caro.