Entorno de preparación de bases de datos para personal no informático

Estoy en el proceso de proponer un entorno de preparación de bases de datos a mi departamento de TI. La idea es que una persona que no sea de TI como yo (analista de datos de obras públicas) tendría un lugar para probar soluciones, y luego implementarlas en el entorno en vivo yo mismo, o pedirle a TI que las implemente si es necesario. Hay algunas razones / escenarios en los que este entorno sería beneficioso:

1. Tengo algunos privilegios de base de datos básicos en nuestro entorno de base de datos en vivo ( create table, create view, etc.). Realizo cambios de esquema aproximadamente una vez por semana, pero me parece una locura probar e implementar estos cambios en un entorno en vivo. Existen innumerables dependencias en la base de datos, por lo que si algo sale mal, podría ser desastroso. Prefiero probar las cosas con anticipación en un entorno separado.
2. No tengo algunos de los privilegios más avanzados como create triggero create functionen la base de datos en vivo. Esto está bien, pero tengo algunos problemas que podrían resolverse mediante disparadores y / o funciones. Planeo proponer que se me otorguen estos permisos en el entorno de ensayo para poder desarrollar y probar algunas ideas, y si funcionan, proponer que TI las implemente en el entorno en vivo.
3. En general, mi departamento de TI no tiene el tiempo ni los recursos para desarrollar soluciones para mí. Es realmente así de simple. Entonces, si puedo hacer el trabajo por mí mismo, entonces es mucho más probable que mis problemas se resuelvan.

El 'entorno de preparación para el personal que no es de TI' me parece un enfoque lo suficientemente sólido, pero para ser honesto, acabo de inventar la idea. No tengo idea de cómo se hace esto típicamente en el mundo de las TI / bases de datos.

¿Existe algún tipo de práctica establecida de TI / Base de datos que se ajuste a este escenario? (¿Estoy en el camino correcto cuando propongo un entorno de preparación de bases de datos para personal que no es de TI?)

Estoy de acuerdo con la respuesta de @Marcin Gminiski de que lo ideal es tener un entorno que imite la funcionalidad disponible en su entorno de producción. Aunque mis 2 centavos al respecto se reducen a "¿Qué puede pagar?" Las restricciones presupuestarias son a menudo el asesino de un buen proceso, por lo que realmente lo que puede pagar determinará la complejidad / elegancia de su solución final.

Debido a que usted menciona que su departamento de TI carece de tiempo y de personal para organizar un entorno para usted, ¿puede usted (o más bien es su departamento / gerente) capaz de aportar fondos? La adquisición de una pequeña cantidad de fondos anuales abriría la posibilidad de mirar la nube. Los proveedores de la nube ofrecen todo lo que necesita, y algunas soluciones incluso incluyen las licencias apropiadas, que a menudo es su mayor costo en relación con Oracle. Si no está lanzando datos confidenciales en este entorno, la nube se vuelve aún más atractiva.

Hay todo tipo de opciones en la nube disponibles, pero lo guiaré hacia instancias de Oracle RDS en AWS únicamente porque ofrecen una opción de Licencia incluida , y puede desactivarla cuando no la esté utilizando para minimizar aún más los costos. Puede existir un equivalente en otros proveedores de la nube, pero muchos proveedores de la nube con los que estoy familiarizado requieren que traiga su propia licencia (BYOL) para soluciones basadas en Oracle en lugar de ofrecer una licencia inclusiva.

Nota final aquí, una instancia de AWS RDS es SOLAMENTE la base de datos, por lo que cualquier infraestructura de servidor de aplicaciones que también necesite debería ser considerada además. La nube es una gran opción si necesita un entorno rápido para probar la funcionalidad, a la vez que es un enfoque rentable; solo asegúrate de estar al tanto y apagar las cosas para que no pagues por servidores inactivos.

Por lo general, se crearía un entorno decente de al menos DEV -> TEST -> PRE-PROD -> PROD. El desarrollo normalmente tendría acceso para desarrollar en DEV, pruebas de aceptación en TEST e IT para lanzar en PRE y PROD. Si usa el control de código fuente, evitará problemas relacionados con la edición del mismo código por parte de diferentes desarrolladores al mismo tiempo.

Técnicamente, solo necesita que el esquema sea el mismo que en prod y no necesita datos de producción por debajo de pre-prod, pero si está de acuerdo con tener datos de prod fuera del entorno de prod, podría tener una restauración automática en dev / test. He hecho un trabajo similar con Visual Cron y funciona de maravilla.

Probablemente, para mantener el cumplimiento, el personal de TI tendrá que publicar los cambios en pre y prod para que, para que sea más fácil y resistente, pueda seguir la ruta de las implementaciones automatizadas.

Aquí está mi experiencia:

Originalmente, teníamos un entorno de desarrollo central llamado simserver. Los desarrolladores probarían las cosas simultáneamente y se puso complicado .

Ahora, cada desarrollador tiene un local en el simserverque implementan para probar. Una vez que dicen que está listo, lo empujan hacia el quality assurance (QA) environment. Tenemos jiracasos de prueba para cualquier cosa que deba verificarse, además, probamos nuevamente las nuevas incorporaciones (contamos con personal de control de calidad dedicado que no realiza desarrollo; solo control de calidad).

Luego lo empujan en vivo.

Hacer un local simserveres lógico y fácil. Una vez que tenga VMlistas las plantillas, los desarrolladores simplemente las implementan en su computadora personal (sin acceso al resto de la red, solo su computadora local).