Sitecore, Docker et l’intégration continue

Avec la sortie de Sitecore 10, nous avons introduit la prise en charge de l’exécution de Sitecore dans Docker Containers. Cela a permis d’obtenir un développement expérience fantastique, vous permettant de créer et de supprimer rapidement et facilement des environnements Sitecore entiers de votre ordinateur local. L’époque des installations longues et interminables appartient enfin au passé !

La communauté du développement est naturellement enthousiasmée par ce changement de collaboration avec Sitecore. Mais que se passe-t-il lorsque vous dépassez le développement et que vous souhaitez commencer à déployer votre solution dans vos environnements de non-production et de production ? Eh bien, tout comme lorsque vous travaillez en dehors des conteneurs, vous voudrez configurer un pipeline d’intégration continue (CI) pour automatiser ce processus pour vous.

Regardez la vidéo accompagnant cet article, qui comprend des démonstrations de ces concepts sur notre Découvrez Sitecore YouTube canal.

Lors de la configuration d’un pipeline CI pour les conteneurs, les choses sont configurées un peu différemment. Lorsque vous travaillez en dehors des conteneurs, vous créez généralement votre application, puis vous l’envoyez directement aux instances IaaS ou PaaS qui les hébergent. L’utilisation de conteneurs modifie légèrement ce processus.

Lorsque vous travaillez avec des conteneurs, l’objectif de votre processus d’intégration continue est de créer un nouvel ensemble d’images et de les envoyer à votre registre de conteneurs. Une fois cette action terminée, la phase CI de votre déploiement est terminée.

La bonne chose à propos de cette phase CI du déploiement est que nous pouvons tirer parti de Docker Compose que nous utilisons pour notre configuration de développement local pour automatiser également nos builds d’image. L’avantage est que nous pouvons utiliser les mêmes instructions que celles que nous avons utilisées sur notre machine de développement pour construire les images qui seront utilisées dans nos instances non destinées à la production et de production. Cela augmente la confiance que vous avez dans ce que vous déployez tout en diminuant les problèmes « Cela fonctionne sur ma machine ! » que nous connaissons tous.

Lorsque vous travaillez avec des conteneurs, le concept de balisage d’image est essentiel, car il vous permet de contrôler quelle version de votre application est déployée dans quel environnement. Il existe deux types différents de balises d’image lors de l’utilisation de conteneurs : les balises stables et les balises uniques.

Balises stables

Les balises stables, représentées par les cases vertes ci-dessus, sont principalement utilisées pour les images de base : vous en héritez pour créer vos images, et elles sont rarement utilisées pour les déploiements eux-mêmes. La raison ? Ils changent avec le temps. Si vous tirez le même tag d’image stable aujourd’hui, puis à nouveau la semaine prochaine, vous pourriez en fait obtenir deux images différentes. Cela est dû au fait que les images utilisant ces balises sont rééditées au fil du temps pour représenter les versions, les mises à jour ou les modifications d’image de base.

Balises uniques

Les balises uniques, représentées par les zones gris foncé ci-dessus, sont principalement utilisées pour les déploiements, en particulier dans les environnements qui évoluent vers plusieurs nœuds ou qui s’exécutent à l’intérieur d’un orchestrateur comme Kubernetes. En effet, l’image derrière un tag unique ne changera pas, ce qui vous donne l’assurance que l’image que vous tirez aujourd’hui est la même que l’image que vous avez tirée à un moment précédent.

(Si vous cherchez plus, Microsoft a un bon article sur la différence entre ces types de balises ici.)

Les mises à jour d’images peuvent être déclenchées pour différentes raisons, mais les deux plus courantes sont un changement de code ou une mise à jour d’image de base. Une modification du code nécessiterait que vos images soient reconstruites pour inclure les modifications apportées à votre base de code. 

Avec les mises à jour de l’image de base, votre base de code n’a pas changé alors que l’une des images de base dont vous dépendez a été mise à jour. Il peut s’agir de l’une des images Sitecore ou peut-être de l’une des images MS de base. Cela nécessite également la publication d’une nouvelle image pour inclure des mises à jour importantes, telles que des corrections de bogues et des mises à jour de sécurité.

Une fois que vous avez créé vos images, la dernière action que vous devez effectuer dans votre pipeline CI consiste à les envoyer vers un registre de conteneurs, tel qu’Azure Container Registry. Cela les rend disponibles pour les autres développeurs de votre équipe et signifie également qu’ils peuvent être utilisés dans vos environnements non destinés à la production et de production.

Si vous souhaitez voir un exemple de configuration d’un pipeline comme celui-ci, vous pouvez consulter le projet Site MVP. Celui-ci dispose d’un pipeline CI/CD entièrement fonctionnel sur lequel vous pouvez baser le vôtre. Vous pouvez voir la configuration YAML à utiliser dans Azure DevOps ici.