Planification d'un pipeline CI/CD

Vous devez créer votre stratégie pour déployer fréquemment de nouvelles fonctionnalités, mises à jour ou correctifs dans votre environnement de production. Étant donné que l'environnement d'exécution HCL Commerce est exécuté sur des conteneurs Docker, profitez de la conteneurisation et implémentez un pipeline continuous integration and continuous deployment (CI/CD). Un pipeline CI/CD vous aide à automatiser les processus de votre cycle de vie de développement, depuis le moment où un développeur vérifie le code jusqu'au déploiement du code dans votre environnement de production. La configuration correcte d'un pipeline peut vous aider à publier plus fréquemment les mises à jour de façon transparente ; soit avec des modifications incrémentielles, soit avec des versions complètes.

La partie CI du pipeline facilite la compression du code personnalisé et la construction d'images Docker personnalisées. La partie CD du pipeline facilite le déploiement des images personnalisées dans des environnements nouveaux ou existants.

Assurez-vous que vous faites des recherches et planifiez en conséquence avant de décider quels outils vous souhaitez mettre en œuvre pour faciliter votre pipeline CI/CD. Pensez au logiciel qui convient le mieux à votre entreprise. Par exemple, vous pouvez implémenter à l'aide de Jenkins, UrbanCode Deploy ou d'une combinaison des deux.

Remarque : HCL n'est pas responsable de la configuration de votre pipeline. Utilisez les informations générales suivantes comme guide pour décider de la façon dont vous souhaitez construire votre pipeline en fonction de vos besoins commerciaux uniques.

Présentation du pipeline

Selon vos pratiques de développement, vous pourriez envisager un pipeline qui suit ce scénario :

1: Votre développeur crée du code dans l'environnement de développement (HCL Commerce Developer).
2: Votre développeur pousse le code vers un référentiel de code source. Par exemple, Git.
3: Implémentez des scripts (tels que des scripts python ou groovy) de sorte que lorsque le code est intégré, le pipeline puisse appeler automatiquement l'utilitaire WCB pour extraire le code du référentiel source et construire un package de personnalisation, puis pousser le package vers un référentiel d'artefacts. Par exemple, vous pouvez utiliser un référentiel d'artefacts comme Nexus.
4: Implémentez des scripts de sorte que le pipeline extraie le package de personnalisation du référentiel, crée de nouvelles images Docker, puis pousse les images vers un référentiel Docker. Pour créer de nouvelles images, vous devez définir un Dockerfile. Dans cette étape, vous pouvez également utiliser les commandes Run Engine pour configurer l'application dans les images Docker. Par exemple, pour configurer une source de données pour l'application afin qu'elle se connecte à votre base de données.
5: L'administrateur de déploiement peut déployer de nouveaux environnements de test/QA avec ces images Docker. Vous pouvez exécuter des tests unitaires automatisés ou des tests fonctionnels sur les nouveaux environnements.
6: L'administrateur de déploiement peut déployer des environnements de création et de production initiaux ou mettre à jour les environnements de création et de production existants qui s'exécutent sur votre plate-forme de conteneurs.
Remarque : Cette étape est la partie la plus difficile à configurer, car elle dépend de votre plate-forme de conteneur. Il est de votre responsabilité de déterminer comment configurer votre pipeline pour qu'il s'intègre à votre plate-forme de conteneurs. Envisagez de créer un modèle de déploiement à intégrer dans votre pipeline afin que vous puissiez spécifier l'environnement à mettre à jour. Par exemple, vous pouvez créer un pipeline où vous spécifiez un paramètre pour déterminer où déployer les mises à jour.