Did you happen to see the blog post Xperience by Kentico CI/CD developer scenarios?
at what point do I run --cd-store and --cd-restore for those server environments to obtain those object changes? Documentation isn't really clear at all on this, especially if we're using DevOps Pipelines or GitHub Actions.
Deployment processes vary widely from team to team based on a lot of factors, so it can be difficult for us to tell you when and where you will run these processes.
However, we do describe the commands that you will need to run during a deployment that includes a CD deployment package and where you can run them from.
The key is to realize your deployment pipeline is just a VM that can run your Xperience by Kentico app and act as another instance of your application.
Here's a general flow that might work for your deployment pipeline scenario.
- Stage 1: Build the app, generate the CD deployment package, store the artifact.
- Stage 2: Stop the app on the app server.
- Stage 3: Deploy the updated application code to your app server.
- Stage 4: (Optional) Run
dotnet --kxp-update MyApp.dll if you are deploying a hotfix or Refresh
- Stage 5: Deploy the CD repository changes
dotnet --kxp-cd-restore MyApp.dll
- Stage 6: Start your app
Notes:
This is a super simplified outline of the stages and doesn't include backups or error recovery, optimizing when dotnet --kxp-update needs to be run, swapping slots, enabling read-only mode, etc...
I'm obliged to mention here that Xperience by Kentico SaaS handles all of this for you 😁.
All stages are running in the pipeline, not on the server.
This requires the .NET SDK in the pipeline VM image.
You don't need the .NET SDK deployed to the application server, only the .NET runtime.
The connection string for your app needs to point to the database for the environment you are deploying to. This connection string needs to be available in the target application server and in your deployment pipeline. You can specify this in appsettings.json, retrieve via Key Vault, command line arguments for dotnet ..., or use an environment variable. These are features of ASP.NET Core, not Xperience by Kentico.
If you have restrictions on what can access your database (example: network firewall), you need to somehow give access to the infrastructure running the deployment pipeline.
The end result is the same "app" that is deployed to your server is the app you are running in the deployment pipeline.
Yes, you are updating the database with migrations and CD artifacts, via the logic in Xperience, remotely from the pipeline, not on the target server. If you have access to the target server and the .NET SDK you can run it there, but you don't need to, and I generally wouldn't recommend it.
Basically, imagine your deployment pipeline VM is a web farmed instanced of your app writing to the database.
Where do you generate your deployment package? That's up to you. Some teams prefer to generate it locally by hand and commit it to source control. This is an easy way to get started but has some big downsides - noisy commit history, difficult to automate. This is like committing your .dlls to source control, in my opinion.
I prefer to generate it in the deployment pipeline by restoring the CI repository to a SQL Server Docker container database and then storing the CD repository to the filesystem before I package everything up for deployment. No commit noise and automated. The CD repository is a build/deployment output artifact, not the application source.
