DXP deployment improvements
We've been working on a few improvements related to DXP deployments lately and wanted to share some recent and upcoming updates with everyone, we really hope you'll enjoy these new features!
Deployment API updates
The deployment API has been very well received and we're therefor investing further into it's capabilities by enabling a few new features for the API first in time for it's GA release.
The ones we released recently are:
- Content syncdown
The API now supports triggering content syncdown (copying of DBs and/or blobs) from the Production environment to Preproduction/Integration. If you're using the EpiCloud PowerShell module, you can use the Start-EpiDeployment cmdlet with the IncludeDb and IncludeBlob parameters to start a content syncdown. - DB export (bacpac)
This is a completely new endpoint in the API that supports exporting a database to a downloadable bacpac file that can be used for local development purposes for example. The EpiCloud PowerShell module has two cmdlets for managing this, Start-EpiDatabaseExport can be used to start the export (it has a -Wait switch if you want it to wait until the export has finished before it returns). If you don't use "-Wait" there is also a cmdlet for fetching the export status called Get-EpiDatabaseExport. - More flexible API key management
The API key management in the DXP Management Portal has been updated to allow for greater flexibility in how keys are created and can be used (it's now possible to assign access to environments on each key instead of having one key for each environment). For more information, see the documentation.
General deployment updates
We've also been working on a feature that is currently in closed beta, namely Smooth deployments (aka. Zero Downtime Deployments). This feature aims to solve the problem of applying database updates without having to take the site offline.
While this feature is still in closed beta, we've added some improvements to the reset-process of deployments in general which can be used together with the maintenance page option in the DXP Management Portal. There are now three different recovery options after a deployment has completed it first stage:
- Roll-forward
We're now enabling you to start a new deployment while the maintenance page stays up if you want fix an unforeseen issue by code. - Rollback code and database
It's now possible to automatically restore the database to the point in time before the database was updated as part of the reset process together with the previous version of the code (see the "-RollbackDatabase" switch of the Reset-EpiDeployment cmdlet in the EpiCloud PowerShell module). - Rollback code only
Rollback only the code to the previous version (like it works today).
Another update we've made that it's possible to validate the restored slot before it's swapped back to receive live traffic (optional step available in the DXP Manangement Portal).
More information about these recovery options and the upcoming Smooth deployment feature is available here.
What's next?
While these new features hopefully provide some significant improvements to the experience when developing for the DXP, we're definitely not done yet. We will soon look into more ways of accessing the blob storage in the different environments, harmonizing the functionality between the DXP Management Portal UI and the deployment API, getting Smooth deployment ready for GA and more.
Meanwhile, make sure you grab the latest version of the EpiCloud PowerShell module and look through the related documentation to these new and updated features:
And finally but definitely not least, please reach out to us with any feedback you might have!
It would be good to make sure that new features to the API are also coming to the pass portal as well for people who have not migrated to using the API yet.
Scott, we plan to align features next where possible. Let's see who make it first, the people to embrace CI/CD or Epi to move around some pixels. :)
I've been doing some blog posts about the Deployment APIs and how to create Azure DevOps tasks with them. The one thing that I would love to see is more progresss outputs for the jobs. When looking through the powershell code, I see that its using Write-Progress, which isnt supported in the logs of Azure Devops, so I've had to write my own.
I just got a post out yesterday about the updates in 313, and it doesnt look like theres any progress for the DB Export.
That being said, I absolutely love the scripts, and I'm excited to see what more you guys come up with :)
Would it be possible for us to do content sync down of only the content and not the codebase?
@Eric, thanks for the feedback! I saw your posts and actually replied just now with a potential workaround for that! :-) We've tried to stick with PowerShell best practises which is to use the Verbose or Progress streams for things like this, basically we want the module to be as "solution agnostic" as possible. But I agree it would've been neat if Azure DevOps had better support for those streams. Write-Host is (depending on what PowerShell version you're running), potentially a bit harmful for PowerShell solutions in general, but in the case of Azure DevOps, it's sort of the way to go. If we use Write-Output instead we break pipelining and pollute the output stream. Hence, we log progress to Verbose and/or Progress streams instead.
Hope that at least makes a little bit of sense :-)
Definitely appreciate your feedback though, we want to make this as straight forward and simple to use as we possibly can, but at the same time allow for as much flexibility as possible. Having a simpler way to track progress is definitely a valid point and we'll see if we can make that easier in the future!
@Johan B, Yes, definitely! That's the main use case actually :-) You simply use Start-EpiDeployment without specifying a source web app, example:
Might be worth mentioning that you won't need to "complete" this deployment since there will be no slot to swap at the end.
This is awesome!
@Anders: will it be any downtime for the site because of no slot swap at the end?
@Justin: Glad you like it!
If you copy a DB we will stop the target site during the copy. But I guess that might not be too bad since it would be the Integration or Preproduction environment :-)
If you copy to Production you can include code as well and use different maintenance options.
@John Håkansson I wish it was always as easy as just "embracing" CI/CD. I have moved companies in the last year and in my previous role I was an Azure Devops master with everything fully embracing CI/CD and Devops culture. However in my current organization there's a lot of challenges to that organizationally and adoption wise which mean I can't just change the core processes. Seeing it from both a CI/CD and devops fayboy like myself and from an organization policy point of few there's always going to be a need to cater for both camps. Hell I've had to push hard to even let us use the Pass portal deploy to Production button instead of emails...
Thanks Anders. Will give this a try next release :)