Sitecore, Docker e integração contínua

Com o lançamento do Sitecore 10, introduzimos suporte para execução de Sitecore dentro de contêineres do Docker. Isso permitiu uma experiência de desenvolvimento fantástica, permitindo que você crie e remova ambientes Sitecore inteiros de sua máquina local de forma rápida e fácil. Os dias de instalações longas e demoradas são finalmente uma coisa do passado!

A comunidade de desenvolvimento está compreensivelmente entusiasmada com esta mudança para trabalhar com Sitecore. Mas o que acontece quando você passa do desenvolvimento e quer começar a implantar sua solução em seus ambientes de não produção e produção? Bem, assim como quando você trabalha fora de contêineres, você vai querer configurar um pipeline de Integração Contínua (CI) para automatizar esse processo para você.

Assista ao vídeo que acompanha este artigo, que inclui demonstrações desses conceitos em nosso Discover Sitecore canal do YouTube.

Ao configurar um pipeline de CI para contêineres, as coisas são configuradas de forma um pouco diferente. Ao trabalhar fora de contêineres, você normalmente cria seu aplicativo e, em seguida, envia-o diretamente para as instâncias IaaS ou PaaS que os hospedam. O uso de contêineres altera um pouco esse processo.

Ao trabalhar com contêineres, o objetivo do seu processo de CI é criar um novo conjunto de imagens e enviá-las para o seu Registro de contêiner. Com essa ação concluída, a fase de CI da sua implantação é concluída.

A coisa boa sobre esta fase de CI da implantação é que podemos aproveitar o Docker Compose que usamos para nossa configuração de desenvolvimento local para também automatizar nossas compilações de imagem. O grande aspeto sobre isso é que podemos usar as mesmas instruções que usamos em nossa máquina de desenvolvimento para construir as imagens que serão usadas em nossas instâncias de não produção e produção. Isso aumenta a confiança que você tem no que está implantando, enquanto diminui os problemas "Funciona na minha máquina!" que todos conhecemos.

Ao trabalhar com contêineres, o conceito de marcação de imagem é fundamental, pois permite controlar qual versão do seu aplicativo é implantada em qual ambiente. Há dois tipos diferentes de tags de imagem ao trabalhar com contêineres: tags estáveis e tags exclusivas.

Tags estáveis

Tags estáveis, represented by the green boxes above, are primarily used for base images — you inherit from them to build your images, and they're rarely used for deployments themselves. The reason? They change over time. If you pull the same stable image tag today and then again next week, you could actually get two different images. This is because the images using these tags are re-issued over time to represent versions updates, or base image changes.

Tags exclusivas

Tags exclusivas, represented by the dark grey boxes above, are primarily used for deployments, especially in environments that scale to multiple nodes, or running inside of an orchestrator like Kubernetes. This is because the image behind a unique tag won't change, giving you confidence that the image you pull today is the same as the image you pulled at a previous time.

(Se você está procurando mais, a Microsoft tem um bom write-up sobre a diferença entre esses tipos de tags aqui.)

As atualizações de imagem podem ser acionadas por diferentes motivos, mas os dois mais comuns são uma alteração de código ou uma atualização de imagem base. Uma alteração de código exigiria que suas imagens fossem reconstruídas para incluir as alterações feitas em sua base de código. 

Com as atualizações de imagem base, sua base de código não foi alterada enquanto uma das imagens base das quais você depende foi atualizada. Esta pode ser uma das imagens Sitecore ou talvez uma das imagens base MS. Isso também requer que uma nova imagem seja publicada para incluir atualizações importantes, como correções de bugs e atualizações de segurança.

Depois de criar suas imagens, a última ação que você precisa executar em seu pipeline de CI é enviá-las para um registro de contêiner, como o Registro de Contêiner do Azure. Isso os torna disponíveis para outros desenvolvedores em sua equipe e também significa que eles estão disponíveis para uso em seus ambientes de não produção e produção.

Se você quiser ver um exemplo de como configurar um pipeline como este, você pode dar uma olhada no projeto MVP Site. Isso tem um pipeline de CI/CD totalmente funcional do qual você pode basear o seu próprio. Você pode ver a configuração do YAML para uso no Azure DevOps aqui.