Trabajo en un pequeño equipo de programación apoyando a una organización más grande. Este año, nuestro gerente decidió que usaremos las tecnologías Oracle Apex para manejar la gran mayoría de los datos de nuestra compañía.

Esto estaría bien, excepto que solo tenemos un servidor Apex. Nuestro gerente ha decretado que todo sucede en esa instancia. Nuestro equipo está desarrollando aplicaciones, mientras que nuestro gerente las muestra, y nuestros clientes internos las usan, lo que por razones obvias ya está causando problemas.

Solo puedo esperar que esto empeore a medida que invertimos más en Apex, las aplicaciones se vuelven más complejas y la cantidad de usuarios crece. He oído que la mejor práctica es tener entornos de desarrollo, prueba y producción separados, pero ¿por qué es así?

La pregunta: ¿Por qué deberíamos tener entornos de desarrollo, prueba y producción separados?

¿Por qué deberíamos tener entornos de desarrollo, prueba y producción separados?

Tienes varias actividades en curso al mismo tiempo:

• desarrollo - donde los desarrolladores cometen código, cometen errores, experimentan, etc.
• Pruebas: cuando las pruebas se ejecutan, de forma manual o automática, y debido a la complejidad, pueden consumir muchos recursos.
• producción - donde se crea valor para los clientes y / o el negocio

¿Quieres que todo esto suceda en el mismo entorno? ¿Desea que el negocio se detenga porque una nueva prueba ha llevado a sus servidores a intercambiar en discos duros y están consumiendo cada núcleo del procesador? ¿Desea que sus pruebas se detengan porque un desarrollador hizo una intrincada bomba de horquilla a partir de un experimento de escala? ¿Desea un código que creía que funcionaba debido a la cuerda y la cinta adhesiva de un desarrollador en las pruebas para ejecutar en producción? ¿Desea que los desarrolladores trabajen con datos de producción potencialmente confidenciales (sé que esto no es una preocupación en todas las empresas, pero sí en muchas de ellas)?

¿Qué impide que ocurran estos problemas?

Ambientes separados.

entonces ¿qué necesitas?

Necesitas ambientes separados.

Para decirlo formalmente

Necesita entornos separados por los siguientes motivos:

• para reducir los riesgos de bloquear negocios y desarrollo de software.
• para reducir los riesgos de poner código en producción que pasó las pruebas debido a la manipulación ad-hoc de los desarrolladores.
• para reducir los riesgos de que los datos de producción caigan en las manos equivocadas (muy importante cuando las organizaciones manejan datos confidenciales, como números de identificación e información financiera y de salud) o se mezclan con datos de prueba o se destruyen.

Para su contexto, una nueva plataforma tecnológica.

Tal vez esto aún no sea realmente producción (ya que es una plataforma relativamente nueva), pero obtendrá sus entornos separados cuando el negocio comience a confiar en ellos y sean lo suficientemente sabios como para prever el riesgo o darse cuenta aprendiendo lo difícil camino.

He oído que la mejor práctica es tener entornos de desarrollo, prueba y producción separados, pero ¿por qué es así?

No es tan claro en estos días.

Muchos lugares ya no realizan pruebas manuales, por lo que no tienen datos de prueba per se. Muchos lugares más tienen tal escala, que no pueden reproducir su entorno de producción debido al costo. Y especialmente con el crecimiento explosivo de los microservicios, se vuelve desafiante mantener los entornos que cambian rápidamente lo suficientemente sincronizados como para garantizar que las pruebas en un entorno de control de calidad reproduzcan cosas con precisión para detectar errores que aparecerían en la producción.

¿Por qué deberíamos tener entornos de desarrollo, prueba y producción separados?

• Si los datos de la prueba fueran vistos por los usuarios, sería muy malo.
• Si tener sus datos de producción vistos por desarrolladores / probadores sería muy malo.
• Si no puede confiar en que sus desarrolladores no rompan las cosas mal, y no puede solucionar esa situación rápidamente.
• Si ha implementado CI automatizado de modo que la promoción del código sea rápida y fácil.

Esencialmente, si el costo de tener los entornos es menor que el costo de no tener los entornos .

La razón principal (y más aparente) es que nunca desea mezclar datos de pruebas y producción. Esto puede volverse increíblemente confuso muy rápidamente tanto para los usuarios del sistema como para los desarrolladores. Cuando administre el control de calidad y las pruebas unitarias (que debería estar haciendo), debe asegurarse de que estén en un entorno totalmente segregado. Si algo explota en su entorno de desarrollo o en el control de calidad, ¡afectaría negativamente a la producción y, por lo tanto, a los usuarios activos y sus datos importantes! ¡Absolutamente no quieres que esto afecte la producción!

Esto se extiende a los servicios normales que debe utilizar en su trabajo diario, como el control de versiones. ¡No puede utilizar el control de versión correctamente si el código que está controlando está en un entorno en vivo! Sus usuarios se volverán locos, ¿qué pasa si necesita revertir o retroceder? ¿Qué pasa si cometes un error drástico quince cometidos de profundidad? ¿Cómo manejarás la ramificación?

Como mínimo, debe separar su entorno en varias instancias virtuales, pero realmente necesita hacer exactamente lo que dijo y tener instancias completamente separadas para cada entorno; idealmente desarrollo, control de calidad, puesta en escena y producción.

En última instancia, todo esto representa un enorme perjuicio no solo para su aplicación frontal (y, por lo tanto, su reputación con los usuarios), sino también para la eficiencia de su equipo.

¡Tener solo una instancia de Oracle disponible no significa lo mismo que "no hay separación entre entornos de desarrollo, prueba y producción"!

Escribiste en un comentario

Actualmente utilizamos diferentes esquemas para diferentes proyectos.

De acuerdo, al dedicar algunos proyectos solo para desarrollo y otros para pruebas, puede separar sus entornos hasta cierto punto, utilizando diferentes esquemas. Supongo que ya hiciste esto, ya que este es el único enfoque sensato que conozco cuando no se planea una separación de instancias. No puedo imaginar que su gerente esté tan loco que quiere que mezcle datos de desarrollo, datos de prueba y datos de clientes, todo en un esquema de manera arbitraria. Lo más probable es que solo quiera ahorrar dinero al no comprar un segundo servidor o invertir dinero en la licencia para una segunda instancia.

Por lo tanto, la verdadera pregunta que debe hacer es:

¿Necesitamos usar diferentes instancias y / o servidores para separar entornos de desarrollo, prueba y producción, o es suficiente la separación de esquemas?

Eso hace que la respuesta no sea tan clara como en las otras respuestas aquí. Los diferentes esquemas permiten diferentes derechos de acceso, por lo que al menos puede obtener cierto aislamiento en cierto grado dentro de una instancia de Oracle. Sin embargo, sus desarrolladores probablemente necesitarán algunos derechos administrativos dentro de "su" esquema, por lo que será más difícil asegurarse de que no tendrán acceso a los datos de producción si solo utiliza una instancia.

Además, una instancia / un servidor también significará recursos compartidos entre desarrollo, prueba y producción: administración compartida de usuario / esquema, espacio en disco compartido, CPU compartidas, ancho de banda de red compartido. Combine esto con la "ley de las abstracciones con fugas" , y quedará claro que usar solo una instancia tendrá un cierto riesgo de obtener efectos secundarios no deseados entre el entorno de desarrollo, prueba y producción.

Al final, debes decidir por ti mismo: ¿puedes trabajar eficazmente con los inconvenientes del enfoque? ¿Su aplicación no es tan intensa en recursos y sus datos de producción no son tan "secretos" que es tolerable tener un nivel reducido de separación entre desarrollo, prueba y producción que el nivel que obtendría de "tres instancias / tres servidores" ¿Acercarse? Si no puede trabajar efectivamente de esa manera, o no sin un alto riesgo de interferir en la producción de una manera en que comienza a perder clientes, tiene todos los argumentos que necesita para convencer a su gerente de que compre al menos un segundo servidor.

Necesita varios tipos de entornos e incluso varios servidores en cada entorno.

Los desarrolladores pueden actualizar el código en desarrollo. Es posible que el código ni siquiera funcione, tal vez la aplicación ni siquiera se iniciará.

Eso no afecta al control de calidad que está probando la última versión estable en su propio entorno.

Dado que tanto el desarrollo como el control de calidad están actualizando sus entornos, la producción se encuentra en la versión de lanzamiento más reciente de hace seis meses y no se ve afectada por los cambios en otros entornos.

Estos cambios que se implementan en diversos entornos pueden ser código o datos. Quizás QA necesita probar un script de base de datos diseñado para corregir algunos datos incorrectos en producción. Tal vez el script empeore el problema: restaure una copia de seguridad de la base de datos e intente nuevamente. Si eso sucediera en la producción, podría tener un problema financiero muy serio.

¿Qué sucede si tienes varias versiones? Tal vez está desarrollando la versión 2.0, pero aún necesita versiones de corrección de errores en la rama de mantenimiento 1.0. Ahora necesita múltiples entornos de desarrollo y control de calidad para asegurarse de que siempre puede desarrollar y probar cualquiera de las ramas cuando se descubre un error crítico y necesita ser reparado ayer.

Ya has notado los problemas que causa no tener entornos separados. Ahí tienes la razón fundamental para entornos separados: para eliminar los problemas causados ​​por los conflictos que surgen inevitablemente al tratar de realizar operaciones de desarrollo, prueba y producción en un solo entorno. El mismo razonamiento se aplica a darles a los desarrolladores cajas de arena individuales para trabajar, evita que los errores de un desarrollador o incluso solo los cambios incompatibles afecten a todo el equipo de desarrollo.

Este es también el mejor argumento que puede hacer a la gerencia para alejarse del entorno único: señalar los problemas que un entorno único ya está causando, mostrar la línea de tendencia y argumentar que, tarde o temprano, si las cosas continúan como están, habrá un problema. problema que costará mucho más limpiar (tanto en esfuerzo directo como en la pérdida de la confianza del cliente en la capacidad de su empresa para prestar servicios) que costará reconfigurar cosas para entornos separados.

Hay muchas fuerzas y dinámicas opuestas. Hay un costo de tener muchos servidores y el costo de tener solo uno. Creo que esta pregunta puede ser mucho más que una simple base de datos. Puede que esté malentendido, pero se relaciona con un malentendido sistémico que está ahí fuera, los costos de lo tangible frente a lo abstracto

Por lo general, los costos obvios son fáciles de entender.

Los costos abstractos son más difíciles de cuantificar y, por lo tanto, más difíciles de comprender. La deuda técnica, el costo de los errores, el costo del estrés, la carga para los desarrolladores, los efectos del cambio, las pruebas de regresión, el impacto del tiempo de inactividad, etc., son más difíciles de explicar.

Entornos diferentes Los entornos suelen estar separados por datos y / o fines. Cada entorno tiene una función diferente. La tasa de cambio en un sistema, es decir. con qué frecuencia se actualizará, qué tipo de cambios y efectos del cambio se consideran todos.

Utilizamos diferentes entornos para trivializar el cambio.

Utilizamos diferentes entornos, por lo que ofrecemos solidez y certeza del entorno que no ha cambiado.

Usamos entornos para considerar los efectos de un cambio.

Utilizamos entornos para reducir los costos relacionados con el cambio.

Probar y estabilizar un sistema cuesta mucho. Usted crea entornos para asegurar la inversión realizada en el entorno estable.

Nunca es un equipo demasiado pequeño para adherirse a patrones de proceso pragmáticos, que ahorren costos, diligentes y probados.

Usar un entorno para todo es como almacenar todas tus fotos en un disco duro, puedes hacerlo, pero te arrepentirás.

algunas personas necesitan pruebas de que he estado en muchas situaciones tratando con clientes u otras personas que no aprecian los costos de garantizar la solidez y seguir las mejores prácticas. Le sugiero que reúna algunos ejemplos de casos reales en los que los costos están claramente definidos.