June 24, 2019
So, you've designed your architecture, you've built your app, you've configured Sitecore - what next? Go live!!!
Well first up, we better get things deployed :)
This is probably the most subjective of this series of blog posts. The tooling and technologies of choice are very much dev team specific. The approach detailed below is how we solved the problem - it's not the way you have to tackle your deployments!
This post ties into the series: an intro to going live with jss.
Orchestrating your deployment
Our project started without JSS, we were building Razor components and composing Sitecore pages via out the OTB tooling.
This gets deployed to WebApps in Azure via the ARM templates provided by Sitecore. We tweaked the templates to remove redis and add a couple new databases - very much application specific changes. To install the templates, we run some powershell to bootstrap the installation.
In order to then push our Sitecore code onto the WebApps, we run all our CI/CD through Azure Devops. Any custom dns is setup via the same suite of powershell scripts used above.
Adding JSS to the mix
As we layered in more of the application, deployment complexity grew, but the toolset we used remained consistent.
Our JSS application runs off VM's hosted in AWS. These are managed using Elastic Beanstalk and provisioned via Cloud Formation. Again, all CI/CD'd using Azure Devops. There are some very good AWS specific add-ins for Azure Devops - these make all the tasks above a breeze.
Build once, deploy many
One pattern we wanted to follow in our CI/CD pipelines was to build once, deploy many. JSS challenges this assumption slightly as when you build your JSS app, configuration values held in scjssconfig.json get copied into several places within the codebase.
Our workaround is to run a regex replace task across specific files during the deploy phase, before we push the changes to Beanstalk.
Note, if you don't like ^ approach consider something like environment variables. However, this would need some extra dev work within your application.
Deploying to authoring
When you deploy your JSS app, you need to push the same code to your authoring deployment.
Because we hosted our Sitecore application on WebApps we could make use of the Kudu ZipDeploy task to push the latest JSS code into Authoring every deployment. This ensures Experience Editor works on Razor and JSS pages.
Azure Devops
Working with Azure Devops has been a very positive experience. My only regret, YAML pipeline support for releases launched once we'd built all our pipelines via the online portal.
My advice to anyone working with Azure Devops - YAML everything! It's currently a preview feature but you can orchestrate all your build and release pipelines from YAML files hosted in app's source control.
Azure Devops rest api
All the code deploys we run are triggered via Powershell. These call into the Azure Devops Rest API to select specific builds, releases and artifacts. It allows us to create a full clean environment and deployment from a single script.
Summary
Once you have the power to deploy the different components required for a full JSS deployment you gain a lot of flexibility.
If needs be you can deploy the whole stack at the press of a button, or if it makes sense you just redeploy your Vue/React/Angular app.
Next up, will JSS be the right choice for us?
