Deploying a GitHub update to Azure hosted DocPad Node.js website takes the site offline for 1-2 minutes

Question

I'm testing a GitHub deployment of a DocPad/Node.js site.

I've got the deployment working however when a new push is made to GitHub the public website site becomes unavailable for 1 to 2 minutes while the deployment is in process.

This seems off to me.

I would think the DocPad static HTML files would be generated by node.js, then copied to the wwwroot folder -- thus minimizing any type of downtime.

However this does not seem to be the case.

While the site is being deployed visitors to the website receive the following error message:

The page cannot be displayed because an internal server error has occurred.

A copy of the DocPad/Node.js deployment can be found at https://github.com/Richard-West/DocPadAzureDemo

I would appreciate any insight as to why this is occuring, and if there is anything I can modify to prevent this from happening. I'd like to be able to push updates to the site at any time, while not affecting any visitors.

Answer 1

Many thanks to Amit Apple for his help with this.

Amit posted some very helpful information in the comments of the Gist I posted, so I wanted to post the final solution here in case this issue is encountered by anyone else.

The problem was because of the Deployment section in the deploy.cmd file. This is the file that gets executed by Azure when a new site is published. My original Deployment section was installing the NPM packages in the %DEPLOYMENT_TARGET% folder, however this should have been occurring in the %DEPLOYMENT_SOURCE% -- since that is where DocPad will be executing from and generating the static site first.

After the site is completely generated then KuduSync copies the new version to the wwwroot in the %DEPLOYMENT_TARGET% folder, and the site is live.

A copy of the Deployment section is below. It's also worth noting that in part 3, before building the DocPad site I am deleting all files that are in the "out" folder from any previous builds. This is done with "rd /s /q out". This ensures that pages or files previously created but are not in the site anymore, are not copied to the production site.

:: Deployment
:: ----------

:Deployment
echo Handling DocPad deployment.

:: 1. Select node version
call :SelectNodeVersion

:: 2. Install npm packages
echo Installing npm packages...
pushd "%DEPLOYMENT_SOURCE%"
call !NPM_CMD! install --production
IF !ERRORLEVEL! NEQ 0 goto error
popd

:: 3. Build DocPad site
echo Building DocPad site...
echo Deployment Source Folder: %DEPLOYMENT_SOURCE%
echo Deployment Target Folder: %DEPLOYMENT_TARGET%
pushd "%DEPLOYMENT_SOURCE%"
rd /s /q out
IF !ERRORLEVEL! NEQ 0 goto error
"!NODE_EXE!" .\node_modules\docpad\bin\docpad -e static generate
IF !ERRORLEVEL! NEQ 0 goto error
popd

:: 4. KuduSync
echo Copying Files...
call %KUDU_SYNC_CMD% -v 500 -f "%DEPLOYMENT_SOURCE%\out" -t "%DEPLOYMENT_TARGET%" -n "%NEXT_MANIFEST_PATH%" -p "%PREVIOUS_MANIFEST_PATH%"
IF !ERRORLEVEL! NEQ 0 goto error

Answer 2

There are 2 options for you:

1. You can customize your deployment process where you generate the static html files prior to deploying them to wwwroot, for more information on how: http://www.amitapple.com/post/38418009331/azurewebsitecustomdeploymentpart2/ http://www.amitapple.com/post/38419111245/azurewebsitecustomdeploymentpart3/

2. You can use the "slots" feature where you deploy to a staging site first and once the staging site is fully deployed and ready for requests you swap between the production and staging sites so visitors will not be impacted. More about it: http://azure.microsoft.com/en-us/documentation/articles/web-sites-staged-publishing/