Here we will discuss the automated deploy process for Sitecore and Sitecore Commerce sites using Octopus Deploy. We will explore the ways to configure this deploy process in such granular detail so we can setup a Sitecore environment to any server without the need for Installation.OMG look how many ppl have commented
Hello there, and welcome to my blog series on setting up automated deploy with Octopus. Recently, I was tasked with setting up an automated build process using Octopus for our Sitecore Commerce 9.3 Project. I kind of went a little overboard and configured the deploy process in such a way that our team can deploy to any server we choose, even if Sitecore does not exist. That includes all the Misc Sitecore Sites such as XConnect, Identity Server, and BizFx.
This article series details every Sitecore site and service involved in a normal installation process including Sitecore Commerce. However, if Commerce is not part of your project, you can simply not include that part. It also includes setting up Host file configurations, Installing and setting permissions to the SSL Certificates, and installing the XConnect Site with its services and setting permissions for those. So you no longer have to worry about SSL trust issues or configuration problems with XConnect. It just works!
This article series assumes you at least know a little bit about Octopus but I will go over each of the areas I configured during my setup so you can easily set yours up in a similar fashion. The design of this process assumes three environment types, each of which serve a specific purpose and is loosely coupled with the GitFlow paradigm and Agile development process:
- Dev: This environment represents what is in the development branch and due to go out in the next sprint.
- QA (Stage): This environment represents what the latest release branch contains and due to be release to production
- Production: Represents what is in the Master branch
So, without further adieu, here are each of the areas of Octopus I configured followed by a brief description for my reasoning
Here is a list of the Projects I use for my deployments. Only the Engine and Storefront projects are the ones we really need to be concerned about. The others are just for initial setup. If your project does not include Sitecore Commerce, you can simply omit the Engine and BizFx projects.
I decided to make things easier on myself and run a simple powershell script to create all the SSL certs for me and upload them into Octopus. During the deploys, I setup a task to load the SSL certificate into the correct store so I do not have to worry about trust issues and XConnect not working.
Therefore, whenever you run into an issue with your SSL certificate expiring soon, you can just upload the latest one here and the next deploy will replace the old one for you. Don't even have to think about it. If you wish to see the inner mechanics of how all this works, head on over to my other blog where you learn All About Certificates
The retention policy is variable and be changed to whatever you like. The most important part here is the phases and the environments they deploy to.
The lifecycle setup is pretty straightforward. The main function they serve is to structure the release process between multiple environments. However, I only use the Dev and Release lifecycles for the Storefront and Engine projects. The important note here is the Release Lifecycle. Whenever a release branch is created off the develop branch, the release is technically "started." The latest package will be automatically deployed to the QA environment so the latest work in the sprint can be tested out. Only after a successful deploy to the QA environment has been made can we deploy to Production. The only responsibility for the Dev lifecycle is to deploy to the Dev environment where changes to the development branch will be automatically deployed without developer intervention. #autoMagic
So there are a lot of packages here (I blame XConnect). For each component of Sitecore 9.3 Commerce base install, I added the placeholder variables packaged up and loaded it into Octopus so they can be deployed to any server I choose regardless if that component existed there before or not.
I will go into the specifics of each package later in the blog series but from a high view, this is the list of packages you should expect to load if you choose to be as granular with your automated deploy. If Sitecore Commerce is not part of your project, you do not need to include the EnginePack, BizFx, and EncryptionKey packages. You can also rename Sitecore-9_3-Commerce to something more relevant (this is the Vanilla Sitecore CM/CD package).
There are a lot of variables you will likely need in your deploy process. I did my best to go through all the files in each of the packages to set the variable placeholders and upload an example of them into this set here. Most of the variables between each of the projects are shared between each other, so I figured I would organize them all by category and reference them in my projects. Below is the list of the Variable Sets along with the path to the JSON file I exported for you to import. I scrubbed the passwords (for obvious reasons) and most of the other variable info so there will have to be some configuration changes you need to make. Also, I only set it up for one environment so that will need to be set up on your end as well.
You may at lease set up your Dev Environment in a similar fashion but here is an example set for you of how I set up mine. Keep in mind the Roles I assigned to each tentacle. You will need to assign them if you decided to import the variable sets I showed earlier. Keep in mind that just because each deployment target is separate, that does not mean they need to be on separate servers. Technically, all of these could be on the same server.
So those are all the global areas of Octopus I setup to get these deploys working for my CI/CD setup. After I setup a new environment, the only two projects I need to worry about are the Engine and Storefront solutions. To further automate things, I made use of Jenkins to trigger a build upon check-in to the develop or release branch in either code repository. From there, I build out the release package to update Octopus and trigger a new release.