I code, write, take photos, and read.
I have been coding since 2010 and I have taken business critical websites and desktop apps from inception to production by working in/leading cross functional teams with an Agile focus. I currently focus on developing & securing cloud native applications.
Let us see how we can build a .NET core console application that can upgrade itself using the Cincinnati update protocol. The Cincinnati protocol will serve OTA updates to the client. Cincinnati is an update protocol designed by Openshift as a successor to Google’s Omaha update protocol. It describes a method for representing transitions between releases and allowing a client to perform automatic updates between these releases.
In the previous post, we manually deployed our website to Azure and we enabled CDN with a custom domain and HTTPS. In this part, we will be automating deployments and we will create staging websites.
We will add a GitHub action that will deploy the production website when changes are pushed to the master/main branch. We will also add one GitHub action that will deploy a staging website when a pull request to master is opened. We will add one last GitHub action that will automatically tear down the staging website when the pull request is either merged or closed. These actions will allow us to leverage git branches to work on multiple posts or website changes without one affecting the other.
In the previous post, we looked at what a git-based CMS is, and we set up a Jekyll website on our local machine. I recommend that you read the previous post here before proceeding.
In this post, we are going to be creating the necessary resources on Azure and we will deploy our website. If you don’t want to use Azure, you can use any other public cloud provider such as AWS. Most cloud providers have similar offerings to host a website along with a CDN, custom domain, and HTTPS.