Deployment to Production

Best Practices

For ANY server deployment into production environment, make sure to wait for any running jobs to complete, or if possible set them to stop and wait until they're stopped by the server process first before deploying the new Shift server.

It is important to understand that for some production environment such as IIS or Azure WebJob, the actual app is running in the Temp folder through shadow copying, please refer to Microsoft documentation of Shadow Copying concept. This shadow copying impact the auto generated process ID, please read detailed information below for IIS and Azure WebJob.

Internet Information Server (IIS)

There are several things to consider when running Shift server in IIS, generally it is not recommended to run long running jobs in IIS.

• IIS automatically terminate or suspend any application pool processes with no activities, this is configured in Idle Time-out setting.
• Each application pool process has Recycling Conditions setting that will automatically recycle the process within certain time limit, a set time, memory usage, or maximum number of requests. Turning recycling setting off may produce unexpected result, such as out of memory exception.
• The auto generated Shift process ID will be deleted for every new deployment or changes to the site, this is because of Shadow Copying. Zombie jobs will not be marked with Error status and become orphaned jobs. Here is a good ServerFault.com answer dealing with recycling and its various issues What should I do to make sure that IIS does not recycle my application?

Few things you can do to run Shift server in IIS:

• Set the application pool Start Mode setting to AlwaysRunning.
• Set the Idle Time-out to 0.
• Separate the application pool for running Shift server site from the client web site.
• To avoid orphaned zombie jobs, manually set the Shift process ID in web.config and use it in the global.asax code. Refer to the Shift.Demo.MVC for a demo.

Azure WebJob

Stopping Azure WebJob will completely turn off the any running processes. I've tried to add some type of delay into the Shift server code, however WebJob seem to ignore this and kill the process immediately. This creates few complications:

• The running jobs during the shutdown will still be marked as "Running" in storage, when in reality they are not. The zombie jobs will have to be marked with Error status and then reset manually after the Shift WebJob runs again. Shift server will automatically search for zombie running jobs using its process ID.
• When Shift process ID is not manually defined in the configuration file, Shift will auto generate a unique ID and store this in a text file shift_pid.txt located in the running WebJob folder, which is physically located in the \local\Temp\jobs\ folder, such as D:\local\Temp\jobs\continuous\Shift-WebJob\4pljmxau.o4p>, The process ID in shift_pid.txt will be re-used until it is deleted. The WebJob temp folder is deleted when a new Shift version is published. It is important that the zombie jobs were found using the same process ID and marked with Error status before a new Shift version is deployed to the server.

Best practices for WebJob:

• Set the parent application setting Always On to On.
• Set the process ID manually in the app.config file and also set the Shift config before starting it.