Développer efficacement et en toute sécurité

Utiliser le contrôle strict d'environnement et de code source

Une utilisation stricte et attentive d'environnements distincts et de contrôle du code source est essentielle pour un processus de développement sécurisé et propre :

De nombreux clients utilisent au moins deux, et souvent trois environnements distincts ou plus. Les environnements de développement, de test, de préparation et de production sont typiques. Tirez le contrôle strict sur la promotion depuis l'environnement jusqu'à l'environnement.

Le système de contrôle des fichiers source doit garantir la cohérence des artefacts :

Métadonnées pour la création des tables
Données source et échantillon
Code ETL
Versions et niveaux de patch de PaaS

Considérez un "architecte de métadonnées" qui contrôle l'évolution des métadonnées et veille à ce que tous les développeurs utilisent les mêmes définitions. Envisagez également de désigner un "gestionnaire des versions" qui contrôle le moment de l'importation des artefacts dans n'importe quel environnement autre que l'environnement de développement, ainsi que qui connaît à tout moment les utilisateurs des environnements qui utilisent ces environnements dans leur but.

Les environnements dédiés présentent plusieurs avantages. En plus d'un environnement de production, envisagez des environnements de développement, de test et de performances. Ces environnements peuvent être mis à l'échelle en fonction des besoins.

Dans un environnement de développement :

Toutes les modifications apportées au code, y compris les modifications mineures, sont développées.
Les tests d'unité (à l'aide d'échantillons de données, souvent un sous-ensemble des données réelles pour une exécution plus rapide) sont effectués.
Le code prêt pour la promotion doit être identifié comme tel. Vous pouvez implémenter des processus pour vérifier et promouvoir automatiquement le code vers un environnement de test ou de production.

Dans un environnement QA :

Consolidation des modifications apportées dans le périphérique (seules les modifications validées pour la promotion).
La validation de la cohérence des modifications (à l'aide des mêmes métadonnées, de la même orchestration cohérente, etc.) et de ce code s'exécute correctement.
Aucune modification de code n'est autorisée.

Un environnement supplémentaire utilisé pour le test des performances peut être avantageux. Dans un environnement de performances :

Etablir une ligne de base pour les performances du code.
Modifications de code limitées autorisées par une équipe de performance uniquement, pour valider les améliorations de performance.
Identifier les goulets d'étranglement, étudier et signaler les modifications requises pour qu'elles puissent être implémentées dans le développement.
Continuez à surveiller les performances avec tous les codes certifiés par l'équipe d'assurance qualité pour identifier les dérives de performances et résoudre les problèmes.

Il est important de continuer à surveiller les performances dans l'environnement de production. La dégradation des performances est parfois un avertissement relatif à une dégradation de l'environnement. Oracle recommande notamment de contrôler les plans d'exécution à l'aide de SQL Plan Management (SPM). Les modifications du plan d'exécution en production peuvent entraîner des échecs et des chargements de table peuvent entraîner des risques de modification du plan d'exécution.

Automatisation des tâches d'administration

Les tâches d'administration manuelles prennent du temps et ajoutent un risque :

La réinitialisation manuelle de l'environnement permet d'effectuer une nouvelle tentative de chargement (en raison d'une erreur de code, d'un bug produit, d'une modification de code, etc.) repose sur les développeurs exécutant manuellement les instructions SQL.
Les processus manuels sont des erreurs et des erreurs peuvent retarder davantage les tentatives suivantes.
Les processus manuels sont lents : les développeurs doivent être prudents de la même manière que ce qu'ils font et perdent beaucoup de temps à vérifier qu'ils ont effectué le bon résultat.
Les erreurs sont coûteuses : la nécessité de corriger les erreurs (potentiellement de recharger les données effacées) peut retarder le travail de développement.
L'intégration de nouveaux développeurs est plus lente et entraîne un risque plus important car ils doivent être formés pour suivre les processus manuels.

Les tâches d'administration doivent être complètement automatisées pour que les développeurs puissent seulement définir quelques paramètres et exécuter un travail déjà validé pour effectuer les tâches correctes à chaque fois.

Envisagez d'automatiser les tâches suivantes :

Réinitialisez les données d'environnement, les variables et les paramètres à autoriser pour la nouvelle tentative de chargement.
Reconstruire les environnements : outils et patches PaaS si nécessaire, métadonnées, données et code PaaS. Cela devrait permettre d'exécuter un chargement initial de l'environnement cible.
Purger les journaux Oracle Data Integrator et les rapports de scénario (ce qui améliore les performances) : l'outil OdiPurgeLog disponible dans les packages peut être utilisé pour créer un scénario dédié et programmer des purges.
Purgez les tables intermédiaires qui ont été utilisées pour les chargements réussis.
Purgez ou localisez les fichiers chargés avec succès.
Lors de l'application de patches, utilisez les installations sans invite (processus d'application de patches d'enregistrement dans un environnement de développement, puis réexécution dans d'autres environnements).

Gérer l'application de patches

L'application de patches est importante pour conserver la mise à jour de vos systèmes avec les dernières corrections de sécurité et de bug, mais une application de patches gérée par un médiocre peut créer des vulnérabilités et provoquer des événements d'arrêt inattendus.

Oracle recommande :

Validez la personne qui figure dans votre organisation et répondra aux alertes d'Oracle sur l'application de patches.
Documentez le niveau d'application de patches de tous vos environnements. Certains services sont appliqués et mis à niveau automatiquement par Oracle, mais vous devrez peut-être appliquer les patches manuellement aux services non natifs et en particulier aux instances sur site.
Définissez des fenêtres d'application de patches. Pour l'application de patches manuelle, identifiez les fenêtres de temps qui nécessitent le moins de perturbations pour vos utilisateurs.

Suivre les meilleures pratiques relatives aux comptes utilisateur

Suivez les meilleures pratiques des comptes utilisateur pour assurer la sécurité de vos données, environnements et intégrations.

Chaque développeur doit disposer de son propre compte utilisateur Oracle Data Integrator, même s'il dispose de privilèges de superviseur. Ne partagez pas les comptes. Les comptes utilisateur séparés améliorent les communications et garantissent la responsabilité :

Les objets verrouillés indiqueront qui modifie l'objet.
La dernière mise à jour indiquera qui a modifié un objet et quand.

Lorsqu 'Oracle Data Integrator a besoin d'accéder à une base de données :

Créez un utilisateur de base de données dédié spécialement pour Oracle Data Integrator. Vous ne devez pas réutiliser le compte d'un utilisateur individuel ou un compte utilisé par un autre service.
L'utilisateur Oracle Data Integrator doit être le propriétaire du schéma intermédiaire (pour effectuer des opérations de création, de suppression, d'insertion, de mise à jour et de suppression).
L'utilisateur Oracle Data Integrator doit disposer de privilèges limités à l'utilisation réelle pour les autres schémas (sélection, insertion, mise à jour et suppression).

Utiliser les utilitaires fournis

Certains outils fonctionnent mieux que les autres : restauration avec ceux qui sont prouvés pour travailler dans votre environnement et documentez le standard de sorte que les nouveaux membres de l'équipe sachent ce qu'ils souhaitent utiliser.

Par exemple :

Génération de clé : il existe plusieurs formats pour les clés. Veillez à documenter le format de clé correct que les développeurs doivent utiliser (par exemple, vous devrez peut-être utiliser le format RSA et interdire le format OpenSSH).
Utilitaires ZIP : Tout le contenu n'est pas compressé de la même manière par différents utilitaires. Assurez-vous que vous contrôlez l'algorithme de compression utilisé pour compresser les fichiers. Oracle recommande d'utiliser 7Zip.