Azure Web apps comes in with very interesting tool, called Kudu, which is web application itself, designed to service and configure your web application. It exposes several APIs to service you - for example, MsDeploy, zip, zipdeploy. In this post I wish to cover some differences between zip and zipdeploy and how I used zip API to deploy Sitecore Unicorn data.
First of all, I wish to describe my problem - we have huge Sitecore 9 web application, which required to deploy 18000 Unicorn files to CM instance in scope of every release outside of web root to solve issues with long paths (we were deploying at C:\home\N directory).
Initially, I tried to solve this problem with MsDeploy - it seems to be fast and reliable and it is designed to deploy you web application to remote server. It worked, but it took too much time due to retries in-between. As I discovered, deployment of 18000 tiny files would not be the best things MsDeploy is able to handle reliably. So, I started looking in other possibilities and discovered, that Kudu exposes 2 more APIs which could be used for deployment: Zip and ZipDeploy.
Zip vs ZipDeploy
ZipDeploy have following possibilities
- Delivers files ONLY to webroot (there is some magic which one could do with NPM, but I never finished this exercise)
- Support both sync and async behaviors (async could be required to overcome built in app services hard-coded timeout of 230 seconds per request)
- Smart as MsDeploy - would not update files that have not changed; would remove files which is not present in archive
Zip have following possibilities
- Delivers files almost to any place of web app work drive
- Does not remove files which is not present in archive
- Have only sync behavior
- Continues execution in background even after request have timed out
Following up on my explanation where I required to deploy 18000 tiny yml files for Sitecore Unicorn outside of webroot - I have been left with only option: using zip API. But, most of my tries it required more than 230 seconds to deliver files on web app, which means that I was not able to reliably find out if unzip operation have been finished.
Solution
I implemented following solution - in each archive with Unicorn files I am adding to the root of archive some unique text file (I am using build number as name and content). From my observations, this file would be extracted last. So, I am feeding api/zip with my Unicorn archive and then, if it fails with timeout, I will just keep asking api/vfs (virtual file system provider) for this file. When file appears there - it means that api/zip have finished it's work and I could proceed with Unicorn import routines. I shall note, that before starting deployment I have to clean up Unicorn folder, as zip API does not remove excessive files.
This small powershell script allowed me to solve my issue with deployment
Top comments (0)