Partie 1 : Début de l’intégration continue pour la base de données
Qu’est-ce que CI/CD ?
Intégration continue (CI) et livraison/déploiement continu (CD) sont un ensemble de principes ou de méthodologies qui permettent aux équipes de développement de fournir du code plus rapidement, de manière plus fiable et avec moins de bogues par rapport au développement logiciel traditionnel tel que le modèle en cascade. Les équipes qui utilisent CI/CD adhèrent également généralement à une version de la méthodologie Agile, travaillant sur des fonctionnalités plus petites dans le cadre d’une exigence globale plus large dans les sprints plutôt que sur des tâches monolithiques s’étalant sur des mois ou des années.
Nous avons aussi l’émergence de DevOps (opérations de développement) car la méthodologie Agile est entrée en collision avec la possibilité de créer rapidement une infrastructure en tant que code dans le cloud. Alors que ces équipes examinaient leur nouveau paysage de développement, il est devenu évident qu’elles ne pouvaient plus travailler dans le vide, vivant dans leur propre monde comme elles l’avaient fait dans le passé. Alors que les rôles professionnels traditionnels s’estompaient et que plus de travail était effectué par moins de personnes, l’ordre devait sortir du chaos de cette nouvelle complexité.
Alors, qu’est-ce que CI/CD ? Que fait-il pour aider avec ce gâchis de développeurs, d’opérations et de parties prenantes qui ont besoin d’intégrer des fonctionnalités et des fonctions dans leur logiciel ? Pour y répondre, commençons par le CI de CI/CD, Intégration Continue.
L’intégration continue nous offre la possibilité d’avoir plusieurs équipes de développement et d’exploitation travaillant simultanément sur différentes fonctionnalités sur un même projet sans se chevaucher. Bien que cette prémisse semble trop belle pour être vraie, il y a une certaine vérité à avoir ici.
Pour avoir un fil conducteur auquel nous pouvons toujours nous référer, cet ensemble de messages utilisera un exemple commun avec du vrai code derrière pour illustrer les concepts et les processus dont nous parlerons. Alors, allons droit au but avec un exemple auquel nous pouvons nous référer au fur et à mesure que nous construisons notre processus de développement.
Voici notre scénario : nous avons une équipe de développeurs travaillant sur une application qui suit les arbres locaux dans une communauté via une interface Web sur le site Web de la ville. Un citoyen peut accéder à cette application et saisir les informations d’un arbre historique qu’il trouve dans la ville. Maintenant, cette équipe utilise également la méthodologie Agile et c’est l’heure du prochain sprint. Nous avons quelques fonctionnalités dont nous avons besoin pour entrer, principalement la possibilité de voir ces arbres sur une carte et la possibilité de télécharger une image avec le formulaire d’entrée d’arbre. Les tâches sont assignées aux développeurs et le sprint démarre.
Processus d’intégration continue
Lorsque les tâches sont distribuées, chaque développeur copiera le code de la dernière version dans un référentiel et créera sa propre copie ou branche. Cette dernière version du code est une copie exacte du code actuellement déployé et exécuté en production. Chaque développeur recevra également une base de données de développement personnel, plus à ce sujet plus tard. Au fur et à mesure que les développeurs terminent les tâches qui leur ont été assignées, ils valident leur branche de code dans le référentiel. Avant de créer une demande d’extraction/fusion, ils vérifient la branche principale actuelle du code dans le référentiel pour toute modification apportée par d’autres développeurs fusionnant des branches de code propres.
S’ils sont trouvés, ils retireront ces modifications et valideront à nouveau leur code. L’un de ces changements peut avoir affecté leur code de manière négative et le processus de génération qui se produit lorsqu’une demande d’extraction/fusion se produit le détectera. Une revue de code est planifié et s’il est accepté, le développeur peut maintenant créer la demande d’extraction/la fusionner dans la branche principale. Il existe également un processus de génération qui se produit à chaque fois que le code est fusionné dans main pour détecter les bogues ou problèmes susceptibles d’apparaître ou les problèmes que le code d’autres développeurs peut avoir causés. Si tel est le cas, les problèmes sont résolus, une demande d’extraction/fusion est créée et des tests automatisés se produisent à nouveau. Une fois que le test revient propre, le code peut être fusionné dans la branche principale.
Résumé des points
- Démarrer le sprint
- Extraire le code du principal
- Créer une succursale locale
- Travail sur les tickets/fonctionnalités
- Rechercher des mises à jour sur l’écran principal
- Branche d’engagement
- Créer une demande de fusion
- Examen du code
- Fusionner dans la version principale/actuelle
Quels avantages tirons-nous de ce processus ?
Tout d’abord, comme nous pouvons le voir tout au long de ce processus, nous pouvons détecter les problèmes avant qu’ils n’entrent en production. En exécutant des tests automatisés sur les modifications de code, nous pouvons simuler ce qui va se passer au moment du déploiement et éliminer les surprises. Cela conduit à de meilleures versions, à une plus grande confiance dans l’équipe de développement de la part des parties prenantes et des utilisateurs finaux, ainsi qu’à un niveau de code plus élevé de la part de nos développeurs.
La responsabilité est un autre avantage. Nous pouvons voir à travers les validations de code, les fusions et les examens exactement ce qui est mis dans notre référentiel de code et par qui. Nous pouvons détecter tous les problèmes ou piratages de la chaîne d’approvisionnement du code, car chaque fichier et chaque ligne de code peuvent être examinés lors d’une fusion. Les référentiels de code modernes suivent également ces changements avec qui et quand, de sorte qu’un enregistrement historique est toujours présent.
Apatride vs avec état
Intégration continue fonctionne très bien avec les fichiers et les déploiements sans état ; des fichiers statiques tels que des classes Java ou JavaScript combinés à un déploiement de conteneur sans état ; avec le nouveau et dehors avec l’ancien. Il est très facile de créer un nouveau déploiement dans un conteneur Docker avec le dernier code et de remplacer l’ancien conteneur si vous travaillez avec des fichiers sans état.
Nous le voyons avec les modèles de déploiement bleu-vert. Dans ce modèle, vous avez votre conteneur d’application en cours d’exécution, le blue. Le vert est votre conteneur d’applications inactif nouvellement déployé. À un moment donné, vous passez au vert et tout le trafic utilise maintenant la nouvelle version tandis que le bleu est inactif. Si vous avez besoin de revenir en arrière ou de revenir en arrière, il vous suffit de revenir au conteneur bleu inactif.
Nous voyons rapidement que ces modèles ne fonctionneront pas pour les déploiements de bases de données. La base de données a un état, les transactions sont validées tout le temps, donc à moins que nous ne puissions nous permettre un temps d’arrêt pour copier l’intégralité de la base de données, déployer les modifications puis reprendre les opérations, cela pose un défi. Et à cause de ce défi, les administrateurs de bases de données et les développeurs de bases de données sont trop souvent blâmés pour ces goulots d’étranglement de déploiement. On leur dit souvent que les bases de données ne peuvent jamais faire de DevOps et encore moins de CI/CD, c’est trop hérité. Où cela laisse-t-il le DBA et le développeur de bases de données ? Ils seront marqués d’une stigmatisation héritée et considérés comme un obstacle à la CI/CD.
Outils du métier
Bien que nous souhaitions qu’il y ait une baguette magique pour rendre tous les déploiements de bases de données faciles et passer directement dans les flux CD/CD sans état, nous devons accepter qu’il y a une part de vérité avec ces préoccupations DevOps. Mais tout espoir n’est pas perdu ! Oracle Database CI/CD peut être une réalité, mais cela nécessite des changements dans les méthodologies et les processus traditionnels ainsi que de nouvelles astuces utilisant des fonctionnalités et des fonctions de la base de données Oracle qui n’ont peut-être pas été utilisées auparavant.
Référons-nous à notre flux de processus et voyons où nous pouvons ajouter des étapes spécifiques au développement de la base de données.
Le sprint commence et nos développeurs de bases de données extraient le dernier code de la dernière version. Où est ce code ? Quels outils pouvons-nous utiliser pour permettre aux développeurs d’avoir des copies locales de notre code de base de données ? Nous utilisons un référentiel de code.
Qu’est-ce qu’un référentiel de code ?
Il existe de nombreux référentiels de code à notre disposition tels que Git, GitHub, GitLab et BitBucket. Ces référentiels nous aideront à stocker nos fichiers et à fournir la gestion des versions, la responsabilité et la visibilité de notre processus de développement. Mais nous partons de zéro ici, nous n’avons pas de référentiel ou de version de code avec lequel travailler. Nous devrons créer une base de référence avec un outil de gestion/suivi du changement.
Comment faire de la gestion/suivi du changement avec Oracle ?
SQLcl avec Liquibase.
Qu’est-ce que SQLcl ?
Oracle SQLcl (SQL Developer Command-Line) est une petite interface de ligne de commande légère basée sur Java pour Oracle Database. SQLcl fournit l’édition en ligne, l’achèvement des instructions, le rappel des commandes et prend également en charge les scripts SQL*Plus existants. Vous pouvez télécharger SQLcl sur oracle.com et il est installé par défaut dans OCI Cloud Shell.
Qu’est-ce que Liquibase ?
Liquibase est une bibliothèque open source indépendante de la base de données pour le suivi, la gestion et l’application des modifications de schéma de base de données.
Comment travaillent-ils ensemble?
La fonctionnalité Liquibase de SQLcl vous permet d’exécuter des commandes pour générer un journal des modifications pour un seul objet ou pour un schéma complet (ensemble de modifications et journaux des modifications). Nous ajoutons également des fonctionnalités et des améliorations spécifiques à Oracle à Liquibase dans SQLcl.
Quelle base de données ?
Pour cet article, le moyen le plus simple de démarrer avec une base de données Oracle est un compte OCI gratuit et une base de données autonome toujours gratuite. Ils arrivent en quelques minutes et ne vous coûteront jamais un centime à utiliser. Si vous n’avez pas de compte OCI toujours gratuit, vous pouvez commencer ici. Une fois connecté à votre compte, vous pouvez créer une base de données autonome toujours gratuite en suivant ce guide ici. Pour nos besoins, une base de données de traitement autonome des transactions convient parfaitement. N’oubliez pas le mot de passe que vous avez utilisé lors de la création de la base de données ; nous en aurons besoin plus tard.
Non vraiment, quelle base de données ?
Alors que nous utiliserons une seule base de données autonome pour les exemples de cet article, dans le monde réel, vous avez plusieurs choix, mais le plus important à retenir est que tous les développeurs DOIVENT avoir des bases de données personnelles sur lesquelles travailler ; et ce point ne peut pas être assez souligné. Cela peut être délicat en raison de nombreux facteurs, mais voici quelques suggestions pour faire de cette étape une réalité dans votre organisation de développement.
Utiliser Multi-tenant dans la base de données Oracle
Saviez-vous qu’avec la 19c et les versions ultérieures, vous pouvez avoir jusqu’à 3 bases de données enfichables gratuitement ? Pas besoin de licence multi-tenant, il suffit de créer et d’utiliser. Les PDB (bases de données enfichables) ont également la possibilité de cloner uniquement les métadonnées d’un PDB d’origine. Cela rend très simple la création de copies d’une base de données de code de production pour tous les développeurs. Cela facilite également le processus d’automatisation des tests dont nous discuterons dans le prochain article. Une autre remarque rapide est que l’installation d’Oracle REST Data Services (ORDS) sur une base de données permet aux API de cloner et de créer des PDB via des appels REST.
La base de données autonome dans OCI
L’utilisation d’ADB dans OCI fonctionne de manière très similaire au multi-tenant où vous pouvez créer des clones complets et des métadonnées uniquement de n’importe quel ADB. Et ces instances ADB peuvent n’avoir besoin que de quelques minutes à quelques semaines.
Instances réutilisables
Il existe de nombreuses fonctionnalités dans la base de données Oracle qui vous permettront de récupérer l’état afin que les développeurs disposent d’une table rase pour travailler dans des instances non mutualisées. Des fonctionnalités telles que les points de restauration garantis/la base de données Flashback, les doublons/clones RMAN et Data Pump vous permettent d’avoir des instances propres pour chaque développeur au début des sprints.
Docker/Machines virtuelles
Qu’elles soient basées sur le cloud ou locales, les technologies de virtualisation peuvent également donner aux développeurs des instances personnelles dans lesquelles travailler avec des copies de notre référentiel de code principal. Les développeurs peuvent également créer des instances de VM de bases de données dans OCI sur la base de la dernière sauvegarde de notre instance de production si besoin est également pour aider à l’effort de base de données personnelle.
Bonjour Repo
En référence à nouveau à notre flux de processus et à notre exemple, nous devons créer une version de base ou principale afin que nos développeurs commencent tous avec le même code. Pour ce faire, nous devons utiliser SQLcl et Liquibase.
Configurations nécessaires
Pour les exemples que nous allons parcourir, nous utiliserons git en ligne de commande avec nos clés SSH prédéfinies, notre référentiel dans GitHub et le nom du projet étant db-cicd-project.
Vous avez ici deux choix :
Créez manuellement le référentiel ou dupliquez le référentiel qui a été pré-créé pour cet article. Je suggérerais de le forger à partir d’ici:
https://github.com/Mmm-Biscuits/db-cicd-project
Ensuite, configurez une connexion SSH via le document suivant :
Se connecter à GitHub avec SSH
Une interface graphique de bureau GitHub est également disponible. Maintenant nous…