Application deployment

Deployment is important technological step for many web applications. It is especially needed when you run application in a shared environment or in a cloud. Web applications running such technologies as Ruby, Python or Node.js usually imply you to have console access to the server. Before being able to actually execute the application users need to run commands in the console, create folders, install modules and components, initiate database structures, users, etc. With shared environment such user interaction is not possible as console access to the server is not available and you cannot change global server components or settings. Same thing apply when you run application in a cloud – even if console is available in theory, application deployment process should be automated to allow dynamic creation of cloud nodes, making user interaction impossible again. And this is where Helicon Zoo deployment scripts bump in.

Deployment scripts are the scripts executed by a server outside of the normal request processing context. To execute these scripts Helicon Zoo uses same scripting engine and application pool user as configured in the application, but deployment scripts are executed in a separate process and only when main application and all workers are stopped. This means that Perl applications will be deployed using Perl scripts, Ruby for Ruby and so on. If application deploy is initiated Helicon Zoo will automatically stop all existing application workers for this web site/application and all further user requests will be served with the “Application deployment in progress” message.

Stopping workers is important part of the concept, because deployment script may include such operations as database migrations or component installation. If these operations executed when user requests are still running database could be damaged and users may get unpredictable responses/effects. If this is a first application start, then deploy will be executed before starting actual application workers.

Whole deployment process may take several minutes and more, so deploy script execution time is not actually limited by the Helicon Zoo system. If normal user requests are usually timed out and worker health is monitored for possible hangs, deployment scripts are allowed to run until it actually finishes. So be careful with this as if your deployment script hangs the whole web site will keep serving “Application deployment in progress” message to users until the application restart. Fortunately other web sites on a system will not be affected.

The other important thing: "Application deployment in progress" message is served using HTTP status 503 – Service temporarily unavailable. This brings several effects:

1. Search engines will not index this message as your new home page content;
2. Thin clients like smartphone apps will not try to interpret this message as a valid service response;
3. If you use load balancer you can tune it to wait for application to warm-up until it gets a 200 OK response.
4. If you want to replace this page with something that fits your web site design you can simply override 503 error pages in the IIS settings.

By default, if DEPLOY_LOG environment variable is not set, the output of deploy script will be sent to the "Application deployment in progress" page in a real time. This means everyone who requests a page on your site during deploy will see the deploy log. In production environment you can set the DEPLOY_LOG variable to the name of writable file, this will direct deploy script output to this file.

The “Application deployment in progress” page updates in real time and once deployment script has finished successfully it will automatically refresh, transferring you to the resource you where initially requesting. If deployment script finishes with the error, the page will not be refreshed automatically, allowing you to read deploy script output.

After deployment script is finished, the deploy file will be automatically renamed as filename_done.ext. This is needed to prevent subsequent execution of deploy script, so make sure write permissions are granted. Next time when you need to re-run deployment script simply rename the file back re,oving "_done" suffix. Helicon Zoo watches for this file and will execute it automatically upon next request to the web site. If you update your application files make sure deploy script file is written after all other files has been updated. This will guarantee that when deployment script is executed all required files are already up to date.
You can find deployment script examples for various web engines on a usage page or in the application templates for specific engine.