Desarrollo eficiente y seguro

Uso del entorno estricto y control de código de origen

El uso cuidadoso y estricto de entornos independientes y control de código fuente es esencial para un proceso de desarrollo seguro y limpio:

Muchos clientes utilizan al menos dos y con frecuencia tres o más entornos independientes. Los entornos de desarrollo, prueba, etapa y producción son típicos. Use el control estricto sobre la promoción del entorno al entorno.

El sistema de control de origen debe garantizar la consistencia de los artefactos:

Metadatos para la creación de tablas
Datos de ejemplo y de origen
Código ETL
Versiones de PaaS y niveles de parche

Tenga en cuenta un" paso de metadatos" que controla la evolución de los metadatos y garantiza que todos los desarrolladores utilicen las mismas definiciones. Además, considere designar un" mánager de versiones" que controle cuándo se importan los artefactos en cualquier entorno distinto del entorno dev y quién sabe en todo momento quiénes usan los entornos con qué finalidad.

Los entornos dedicados tienen varios beneficios. Además de un entorno de producción, considere entornos de desarrollo, prueba y rendimiento. Estos entornos se pueden escalar según sea necesario.

En un entorno dev:

Se desarrollan todos los cambios en el código, incluso menores.
Las pruebas de unidad (utilizando datos de ejemplo, a menudo, un subjuego de datos reales para ejecuciones más rápidas) se realizan.
El código listo para la promoción debe identificarse como tal. Puede implementar procesos para revisar y promocionar automáticamente el código a un entorno de prueba o producción.

En un entorno de QA:

Consolidación de los cambios realizados en dev (solo cambios validados para promoción).
Validación de consistencia de cambio (con los mismos metadatos, orquestación consistente, etc.) y ese código se ejecuta correctamente.
No se permiten cambios de código.

Se puede utilizar un entorno adicional para la prueba de rendimiento. En un entorno de rendimiento:

Establecer una línea base para el rendimiento del código.
Los cambios de código limitados permitidos solo por un equipo de rendimiento, para validar las mejoras de rendimiento.
Identificar cuellos de botella, investigar e informar los cambios necesarios para que se puedan implantar en el desarrollo.
Siga supervisando el rendimiento con todo el código certificado por el equipo de control de calidad para identificar problemas relacionados con el rendimiento y la dirección.

Tenga en cuenta que es importante seguir supervisando el rendimiento en el entorno de producción. La degradación del rendimiento a veces es una advertencia de una degradación del entorno. En concreto, Oracle recomienda controlar los planes de ejecución mediante la gestión de planes SQL (SPM). Los cambios en el plan de ejecución en la producción pueden causar fallos y las cargas de tabla producen riesgos en el cambio del plan de ejecución.

Automatización de tareas de administración

Las tareas de administración manuales requieren tiempo y agregan riesgo:

El restablecimiento manual del entorno para volver a intentar una carga (debido a un error de código, bug de producto, cambio de código, etc.) se basa en los desarrolladores que ejecutan sentencias SQL manualmente.
Los procesos manuales son pronósticos de error y los errores pueden retrasar la siguiente prueba.
Los procesos manuales son lentos: los desarrolladores deben tener cuidado con lo que están haciendo y perdiendo mucho tiempo comprobando que han hecho lo correcto.
Los errores son costosos: es necesario corregir los errores (que pueden volver a cargar los datos borrados) puede retrasar el trabajo de desarrollo.
La vinculación de nuevos desarrolladores es más lenta y genera un mayor riesgo porque deben estar capacitados para seguir los procesos manuales.

Las tareas de administración deben ser totalmente automatizadas para que los desarrolladores puedan definir solo unos pocos parámetros y ejecutar un trabajo que ya esté validado para realizar las tareas correctas cada vez.

Considere la automatización de las siguientes tareas:

Restablecer los datos de entorno, las variables y los parámetros que se permiten para el reintento de carga.
Reconstruir entornos: Herramientas y parches de PaaS si es necesario, metadatos, datos y código PaaS. Esto debe incluir la capacidad de ejecutar una carga inicial del entorno de destino.
Depurar registros de Oracle Data Integrator e informes de casos (que mejora el rendimiento): la herramienta OdiPurgeLog disponible en paquetes se puede utilizar para crear depuraciones de casos y programaciones dedicados.
Permite depurar las tablas de asignación de etapas utilizadas para cargas que fueron correctas.
Depurar o volver a localizar los archivos que se han cargado correctamente.
Al aplicar parches, utilice instalaciones silenciosas (registre el proceso de aplicación de parches en un entorno de desarrollo y, a continuación, realice la reproducción en otros entornos).

Gestionar Parches

Es importante que la aplicación de parches mantenga los sistemas actualizados con las últimas correcciones de seguridad y de bug, pero un registro de aplicación de parches completamente gestionado puede crear vulnerabilidades y causar eventos de tiempo de inactividad inesperados.

Oracle recomienda:

Valide quién de la organización recibirá y responderá a las alertas de Oracle sobre la aplicación de parches.
Documente el nivel de aplicación de parches de todos sus entornos. Tenga en cuenta que Oracle aplica parches a algunos servicios y los actualiza automáticamente, pero puede que necesite aplicar parches a servicios no nativos manualmente e especialmente a instancias locales.
Definir ventanas de parches. Para la aplicación de parches manual, identifique las ventanas de tiempo que son menos interrumpidas para los usuarios.

Seguir mejores prácticas de cuentas de usuario

Siga las mejores prácticas con las cuentas de usuario para garantizar la seguridad de sus datos, entornos e integraciones.

Cada desarrollador debe tener su propia cuenta de usuario de Oracle Data Integrator, incluso si se le han otorgado privilegios de supervisor. No compartir cuentas. Las cuentas de usuarios separados mejoran la comunicación y garantiza su cuenta:

Los objetos bloqueados mostrarán quién está editando el objeto.
Las últimas actualizaciones mostrarán quién modificó por última vez un objeto y cuándo.

Cuando Oracle Data Integrator necesita acceder a una base de datos:

Crear un usuario de base de datos dedicado específicamente para Oracle Data Integrator. No vuelva a utilizar una cuenta de usuario individual o una cuenta utilizada por otro servicio.
El usuario de Oracle Data Integrator debe ser el propietario del esquema temporal (utilizado para realizar operaciones de creación, borrado, inserción, actualización y supresión).
El usuario de Oracle Data Integrator debe tener privilegios limitados al uso real de otros esquemas (seleccionar, insertar, actualizar y suprimir).

Usar Utilidades de Provisionamiento

Algunas herramientas funcionan mejor que otros: se adhieren a las que se les ha demostrado trabajar en su entorno, y documentan el estándar para que los nuevos miembros del equipo sepan qué deben utilizarse.

Por ejemplo:

Generación de claves: hay varios formatos para claves. Asegúrese de documentar el formato de clave correcto que deben utilizar los desarrolladores (por ejemplo, puede que necesite el uso del formato RSA y prohibir el formato OpenSSH).
Utilidades ZIP: no todo el contenido se comprime del mismo modo mediante distintas utilidades. Asegúrese de tener control sobre el algoritmo de compresión que se utiliza para comprimir los archivos. Oracle recomienda el uso de 7Zip.