¿Cómo trabajas en paquetes Oracle en un entorno colaborativo controlado por la versión?

Question

Estoy trabajando en un entorno de múltiples desarrolladores en Oracle con un paquete grande. Tenemos un patrón de promoción DEV => TST => PRD. Actualmente, todas las ediciones de paquetes se realizan directamente en TOAD y luego se compilan en el paquete DEV.

nos encontramos con dos problemas:

1. cambios concurrentes deben ser promovidos en diferentes horarios. Por ejemplo, el desarrollador A realiza un cambio que debe promocionarse mañana, mientras que el desarrollador B trabaja simultáneamente en un cambio que no se promoverá durante otras dos semanas. Cuando llega el momento de la promoción, nos encontramos comentando manualmente cosas que aún no se están promocionando y luego quitándolas después ... ¡qué asco!

2. Si dos desarrolladores realizan cambios al mismo tiempo y uno de ellos se compila, borra los cambios del otro desarrollador. No hay una fusión agradable; en su lugar, la última compilación gana.

¿Qué estrategias recomendaría para evitar esto? Estamos utilizando TFS para nuestro control de origen, pero aún no lo hemos utilizado con nuestros paquetes de Oracle.

P.S. He visto this publicar, pero no responde completamente mi pregunta.

Answer 1

Utilizamos Oracle Developer Tools for Visual Studio.NET ... se conecta a la derecha en TFS

Answer 2

lo hacemos con una base de datos Dev para cada flujo 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 3

La clave es adopte la práctica de solo implementar código desde el sistema de control de origen. No estoy familiarizado con TSF, pero debe implementar los conceptos de ramas, etiquetas, etc. La cuestión de qué implementar luego cae fuera del etiquetado de compilación y liberación en el sistema de control de origen.

consejos adicionales (para 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 la especificación de paquete, y ".pkb" para el cuerpo del paquete). Si usa un proceso de compilación automatizado que puede procesar patrones de archivos, entonces puede compilar todas las especificaciones y luego los cuerpos. Esto también minimiza las invalidaciones de objetos si solo está implementando un cuerpo de paquete.

• dedique tiempo a configurar un proceso de compilación automatizado que se desencadena desde un lanzamiento o un estado de compilación de su sistema de control de origen. Si tiene incluso un número moderado de objetos de código db, pagará poder construir el código en un sistema de referencia y compararlo con su qa o sistema de producción.

Answer 4

Puede usar las herramientas de desarrollador de Oracle para VS o puede usar el desarrollador de sql. El desarrollador de SQL se integra con Subversion y CVS y puede descargarlo gratis. Vea aquí: http://www.oracle.com/technology/products/database/sql_developer/files/what_is_sqldev.html

Answer 5

Vea my answer acerca de Tools to work with stored procedures in Oracle, in a team (que acabo de volver a etiquetar).

En pocas palabras: no modifique los procedimientos directamente con TOAD. Almacene el origen como archivos, que almacenará en el control de fuente, modifíquelo y luego ejecútelo.

Además, recomendaría que cada desarrollador trabaje en su propia copia de la base de datos (use Oracle Express, que es gratis). Puede hacerlo si almacena todos los scripts para crear la base de datos en control de fuente. Más información can be found here.

Answer 6

Para evitar 2 desarrolladores trabajando 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 primero debe verificar el paquete desde el control de la versión; nadie más puede verificar el paquete hasta que este desarrollador lo vuelva a verificar.

2) No trabaje directamente en el código del paquete en Toad o cualquier otro IDE. Usted tiene sin pista si el código que está trabajando allí es correcto o ha sido modificado por uno o más desarrolladores. Trabaje con el código en el script que ha desprotegido del control de versiones y ejecútelo en la base de datos para compilar el paquete. Mi preferencia es usar un buen editor de texto (TextPad) y SQL Plus, pero también puedes hacerlo en Toad.

3) Cuando haya terminado, compruebe la secuencia de comandos en el control de la versión. No haga copie y pegue el código fuera de la base de datos en su script (vea el punto 2 de nuevo).

El inconveniente (si es que lo es) de este enfoque controlado es que solo un desarrollador a la vez puede trabajar en un paquete. Esto no debería ser un problema importante siempre y cuando:

• Mantiene los paquetes a un tamaño razonable (en términos de QUÉ hacen, no cuántas líneas de código o cantidad de procedimientos hay en ellos). No tiene un paquete grande que contenga todo el código.
• Se recomienda a los desarrolladores que comprueben el código solo cuando estén listos para trabajar en él y que lo revisen tan pronto como hayan terminado de realizar y probar sus cambios.

Answer 7

Usamos Toad for Oracle con el proveedor TFS MSSCCI contra TFS 2008. Usamos un Custom Tool que extrae los checkins de la base de datos del control de origen y los empaqueta para su lanzamiento.

Que yo sepa Oracle Developer Tools para Visual Studio.Net no tiene ninguna integración de control de fuente real con TFS o de otra manera.

Puedes considerar Toad Extensions for Visual Studio aunque no es barato, quizás $ 4k, creo.

Otra opción es el Oracle Change Management Pack pero creo que requiere la edición Enterprise de Oracle que es mucho más cara.