1. En savoir plus sur la sélection d'une architecture CI/CD appropriée
  2. Identifier l'architecture ou la solution la plus appropriée

Identifier l'architecture ou la solution la plus appropriée

Considérez la série de facteurs d'évaluation (ou de facteurs de stress) pour identifier l'architecture de référence (RA) ou la solution qui répond le mieux à vos besoins. Les sections suivantes vous fournissent des informations sur les facteurs à prendre en compte.

Pour chaque facteur, nous vous fournissons une indication indiquant si une architecture ou une solution prend en charge le facteur ou non. Si nécessaire, vous pouvez le nuancer en attribuant à chaque facteur un score numérique. Utilisez les informations et la matrice de décision à l'aide de ces recommandations.

  • Gardez une trace des colonnes correspondant à votre réponse préférée.
  • Comparez l'ER ou la solution qui répond le mieux à vos besoins par rapport à chaque facteur d'évaluation à l'aide de la matrice de décision.
  • Ajoutez une pondération aux facteurs qui sont plus importants pour vous que les autres.

Considérer les différents facteurs d'évaluation

Examinez chaque facteur d'évaluation, puis comparez-les à chaque architecture et solution pour déterminer celle qui correspond le mieux à vos besoins.

Conteneur, machine virtuelle ou spécialiste

Vous pouvez redimensionner efficacement les ressources pour les processus qui nécessitent davantage de puissance de calcul en déployant des processus vers des conteneurs dans un environnement d'orchestration de conteneurs comme Kubernetes. Des tâches telles que les tests unitaires et l'analyse de code statique peuvent en tirer parti. L'inconvénient de l'utilisation de conteneurs est la complexité accrue dans la configuration de bout en bout. Votre équipe devra savoir utiliser des outils d'orchestration de conteneurs tels que Kubernetes. L'utilisation des conteneurs permet également de s'assurer que, lorsque les conteneurs sont détruits, ils empêchent la récupération accidentelle de dépendances transitoires ou de données d'état antérieures.

L'utilisation d'une machine virtuelle est plus simple car vous pouvez créer une seule machine virtuelle pour gérer toutes les étapes d'un pipeline. Un récipient est de nature monolithique. Une approche VM réduit également les problèmes tels que l'hébergement des développeurs et évite les problèmes d'utilisation des hôtes Windows et Linux.

Certains scénarios spécialisés prennent uniquement en charge les produits PaaS ou SaaS dans lesquels le processus de build prépare et déploie des artefacts pour le service. Vous pouvez orchestrer cela à l'aide d'un outil à usage général. Dans certains cas, l'utilisation d'un outil spécifique à l'exigence peut être plus bénéfique. Par exemple, Oracle Visual Builder Studio est conçu pour les solutions impliquant Visual Builder.

Orchestration de pipeline avec OCI Native avec des produits open source/tiers

L'utilisation d'outils propres à un domaine ou très personnalisables, y compris d'outils open source tels que Jenkins, peut offrir une plus grande liberté dans le processus de création lors de l'exécution par rapport à l'utilisation de solutions natives OCI. Bien que des outils comme OCI DevOps publient régulièrement de nouvelles fonctionnalités. Mais cette flexibilité a un coût de gestion supplémentaire des étapes de processus telles que le déploiement, l'application de correctifs et la surveillance, même lors de l'exécution de pipelines standard.

Référentiels de déploiement standardisés ou référentiels de produit spécial

Les services natifs prendront en charge vos exigences lorsque vous gérez des configurations à l'aide de services standard tels qu'OCI Git, GitLab ou GitHub, et d'outils similaires. Les processus d'intégration continue et de déploiement continu peuvent être limités par des référentiels hérités partiellement intégrés. Vous devrez peut-être apporter des modifications importantes au pipeline afin de pouvoir utiliser les processus d'intégration continue et de déploiement continu avec des référentiels hérités.

Gestion des configurations standard ou outils hérités du secteur

Lorsque vous utilisez des services fournis dans le cloud, il est classique de ne prendre en charge que les solutions standard du secteur qui utilisent des systèmes de gestion de configuration tels que Git et SVN. Ces fournisseurs de services peuvent également prendre en charge tous les mécanismes de gestion de configuration spécialisés dont le fournisseur a besoin. Si vous devez utiliser un système CM hérité ou de niche, il peut s'avérer nécessaire d'envisager des solutions tierces prises en charge par le fournisseur du système CM. Par exemple, la prise en charge de CVS en tant que solution héritée peut nécessiter que les utilisateurs utilisent des outils tiers pour gérer la configuration.

Déploiement multicloud ou dans un seul Cloud

Le déploiement de la même solution de base sur plusieurs clouds peut ajouter des complexités que vous devez prendre en compte. Par exemple, si le processus de déploiement est incorporé dans un service Terraform, chaque fournisseur cloud doit disposer de processus de déploiement qui prennent en compte les différences avec différents fournisseurs Terraform. Des considérations plus subtiles, telles qu'un chipset cible pour les images Docker, peuvent être requises car différentes images devront être créées.

Pour garantir une meilleure sécurité, vous pouvez choisir de ne pas exposer vos cibles de déploiement pour une solution de déploiement externe. Par exemple, si vous effectuez un déploiement vers Oracle Container Engine for Kubernetes (OKE) et Azure Kubernetes (AKE), vous pouvez utiliser GitHub pour contenir le code commun et les actions GitHub pour orchestrer le build de conteneur. Toutefois, vous pouvez choisir de ne pas exposer AKS et OKE directement aux actions GitHub. Envisagez plutôt une solution à plusieurs étapes avec Azure et OCI pour fournir une orchestration de déploiement et utiliser GitHub pour les processus de construction en continu ou le code principal.

Considérez une solution à plusieurs étapes lorsque Infrastructure-as-Code (IaC) fait partie du processus de déploiement. Cela permet à chaque environnement de disposer d'une configuration IaC différente pour le provisionnement des services gérés, de stockage et de calcul. L'utilisation de Kubernetes vous permet de limiter ou d'enlever ces problèmes.

Personnalisation de processus ou processus sur mesure

Si vous avez besoin de processus spéciaux ou de niche, les outils permettant de prendre en charge le pipeline de build doivent autoriser les extensions pour la configuration personnalisée. La création de vos propres processus sur mesure nécessite plus d'efforts. Vous devez prendre en compte et évaluer le risque que des modifications futures empêchent la personnalisation de fonctionner.

Potentiel de mise à l'échelle

Les charges de travail de développement peuvent fluctuer en raison de facteurs tels que les tendances courantes au cours d'une journée de travail. Par exemple, les validations des activités de fin de journée qui déclenchent des processus d'intégration continue et de déploiement continu entraînent une augmentation de la charge de travail à la fin de la journée de travail. Au fur et à mesure que les projets progressent dans leur cycle de vie de création, de mise à disposition et de déploiement, la création d'infrastructure entraîne une augmentation de la demande. On observe une augmentation du nombre de demandes de petits changements, les problèmes mineurs étant traités à la fin des cycles de publication/impression.

Examiner la matrice de décision

Les architectures et les solutions sont regroupées sous un nombre commun, tel que 1a, 1b et 1c en fonction de l'endroit où elles ont des variations subtiles. Par exemple, un seul noeud pour la solution CI/CD ou la même solution avec une configuration d'outillage différente indique que la solution peut fonctionner à plus grande échelle. Chaque regroupement est un en-tête de colonne dans la matrice de décision et chaque facteur est un en-tête de ligne. Les légendes du tableau, telles que 1, fournissent des informations supplémentaires.

Architecture et regroupements de solutions

  1. Orchestration Jenkins (avec deux variantes)
    1. Configurer un pipeline d'intégration continue et de déploiement continu pour les déploiements cloud avec Jenkins : approche de déploiement minimal sans évolutivité ni résilience
    2. Déployer Jenkins en mode maître/agent : déploiement évolutif et résilient
    3. Créez un pipeline d'intégration et de déploiement continus à l'aide du service Oracle DevOps
  2. GitLab
    1. Déployer GitLab pour activer les pipelines CI/CD sur OCI
    2. Déployer des programmes d'exécution GitLab sur Oracle Container Engine for Kubernetes avec le redimensionnement automatique de cluster
  3. OCI DevOps : variantes pour les conteneurs et sans serveur
    1. Créer un pipeline CICD à l'aide du service Oracle Cloud Infrastructure DevOps et d'OCI Functions
    2. Créez un pipeline d'intégration et de déploiement continus à l'aide du service Oracle DevOps
  4. Actions GitHub : Créez un pipeline d'intégration continue et de déploiement continu pour les déploiements cloud à l'aide des actions GitHub et du service Oracle Cloud Infrastructure DevOps
  5. Stratégie pour les applications modernes : planifiez les stratégies de déploiement d'applications modernes avec Oracle Cloud Infrastructure Devops
  6. Mobile Hub : créer un pipeline d'intégration et de déploiement continus pour les applications mobiles
  7. Bots : créer un pipeline d'intégration continue et de déploiement continu pour les composants personnalisés de bots

La matrice de décision suivante représente les différences entre les architectures et les solutions pour vous permettre d'identifier celle qui correspond le mieux aux besoins de votre entreprise.

Facteur 1. Orchestration Jenkins 2. GitLab 3. OCI DevOps 4. Actions GitHub 5. Stratégie des applications innovantes 6. Hub mobile 7. Bots
Conteneur, machine virtuelle ou spécialiste

Machine virtuelle et conteneur

(Bien que la solution fournie cible les machines virtuelles)

 Machine virtuelle ou conteneur Machine virtuelle et conteneur Machine virtuelle et conteneur Machine virtuelle et conteneur Spécialiste Spécialiste
Orchestration du pipeline avec OCI native ou non gérée avec des produits open source/tiers Oui Oui Non Oui Non Non (Oracle Dev Cloud) Non
Référentiels de déploiement normalisés Oui1,3 Oui1 Non Non (dans l'implémentation RA - mais possible) Oui1 Non Non
Référentiels de gestion de configuration pris en charge GIT, SVN et autres GIT (HOMONYMIE) GIT (HOMONYMIE) GIT (HOMONYMIE) GIT (HOMONYMIE) GIT (HOMONYMIE) GIT (HOMONYMIE)
Déploiement multicloud ou dans un seul Cloud Unique2,3 Unique ou multicloud Unique2 Unique ou multicloud Unique2 Un Non
Personnalisation des processus ou processus sur mesure Oui Oui Oui Oui Oui Non Limité
Évolutivité du potentiel

1a - Non

1b - Oui

 Oui Oui Oui Oui Non Non

Notes de bas de page du tableau

Remarque :

  • 1 OCIR est conforme aux normes.
  • 2 utilise OCI pour piloter les processus dans d'autres environnements. Mais soulève également le défi de l'exposition indésirable aux services dans d'autres environnements.
  • 3 Utilise OCI DevOps lors de la phase de déploiement pour l'option 1a, ce qui limite cette phase à un seul cloud.