Episerver recently released an API that allows partners and customers to automate deployment to DXC-S environments. If using this API you no longer need the manual process of logging in to the DXC-S portal and starting a deploy. The API also makes it possible to deploy directly to Pre-production or Production environments.
Update: “DXC-S” is now known as ” Episerver DXP”
Currently I’m only using the API as a way of automating the deployments instead of manually clicking the buttons in the DXC-S portal. My plan is to be able to upload packages directly to Pre-production, and have the possibility to do hot-fix deployments. Then we can start using the DXC-S environments as they are intended. With the current setup you basically is forced to setup your own development/integration environment. But even if I still use the “old” deployment flow I get the following benefits by using the API:
- Possible to setup automated deployments when e.g. a certain git branch is updated.
- Possible to automatically trigger automated testing/warmup on the slot, before going live.
- Quicker deployments when removing the manual steps.
- Anyone in the team that has access to Octopos Deploy can trigger deploy to production. You don’t need to go through the process of getting access in the DXC-S portal.
Setup Octopus Deploy
It’s possible to setup the process and environments in Octopus in different ways. With the evolvement of the tool, Octopus themselves have also changed how they recommend setting up things over the years. So, there is really no right or wrong.
I started by creating two new environments (“<Client name> DXC-S PreProd” and “<Client name> DXC-S Production” ). The environments are empty, deployment targets are not needed when deploying using the API. I then added the environments to the existing Lifecycle in Octopus.
Steps in the Octopus Deploy Process
I already had a process that is used to deploy to our dev. environments, and the DXC-S Integration environment. I added three new steps to this process. These new steps are set to only run for the new environments I just created.
First step is of type “Run a Script”. I called this step “DXC-S deploy from source environment – Step 1”. This step will run the Powershell script that will start the deployment from one environment to another (e.g. from Integration to Preproduction). The script will wait until the first step (deploying to a slot on the target) is finished.
Next step in the process is checking that the slot is responding ok. For this step I’m using a modified version of this script.
And finally a step that is finishing the deployment by swapping the slots. This step is very similar to “Step 1”.
The steps/scripts are using several variables defined in Octopus
The only way I could find the DXC-S project id was to look at the querystring in the link to the project in the DXC-S portal.
The downside with this process is that a deploy to Preproduction or Production can be manually triggered in Octopus for any release, but the actual release that gets deployed is the one currently on the source environment. Octopus could show the wrong release being deployed. For me this is fine, since I consider this process to be temporary until I set up a deploy using code package.
The scripts
I believe that code should always be in git, therefore I added the scripts as files in the repository, and did not just enter the scripts in the Octopus step.
Step 1
Step 2
These scripts could have been made simpler, I could have just started a deploy in Step 1 and saved the deployid to an Octopus variable that is then used in Step 2. But I wanted the scripts to be more idempotent. It should be able to handle if there already is an ongoing deployment, that might have been triggered from the portal, or if something failed between Step 1 and Step 2.
IT’S LIKE THAT!
Other resources
Great post Erik, thanks for testing out the API! This is really useful for us as input to future improvements.