Now it looks, something like that:

1. blocks all requests, and display “Website is under construction”
page.
2. implement database schema updates
3. update the application’s source code
4. unblock all the requests and hide “Website is under construction” page.

I thought, that we need the following:
after third, and before fourth point I want the webserver to drop the sessions of already loggined users. I think, this practice is useful for automated deployment, because there might
be significant changes in sessions handling and in the application
core itself, so it is better to drop users’ sessions and force them to
login again.

Because it is an automated deployment and usually take very small time, so we can’t wait when loggined user’s session will expired.

The solution for the problem depends on where does the application stores sessions – files in system tmp folder, application tmp folder, database or some custom session-handling mechanism.

We store our session in the database, in single table called `sessions`. So when we need to drop the sessions, all we have to do is to execute SQL command: “TRUNCATE TABSE `sessions`;”. This can be done automatically, from command line. For example, like that:

It is quite simple solution and most important working solution, in most cases it is enough, BUT
it is not ideal, and can be improved.

We decided to do it another way:
new build can have just minor updates, which don’t refer with sessions in any way, so we should save user’s session in that case. Build manager, or person responsible for deployment should to know such details, whether sessions must be dropped after deployment or not(just hide unnecessary details), because it is developer’s responsibility to “tag” the build with “drop the sessions”, if it is necessary. This process, has to be automated too.

Then we started to think, how we can make that. The solution was simple and straightforward – give this responsibility to database SQL deltas automated updates mechanism.

We use DBDeploy for the task, which handle plain SQL format for SQL updates.
So when developer sees the need of sessions drop after deployment, all he have to do is to add the “TRUNCATE TABLE `sessions`;” SQL command to new SQL delta script.

This solution, of course, becomes useless if sessions are stored in tmp folder, as default option in php.ini file. In that case, I wan’t to recommend you to drop the session files manually from that folder, but better stop apache web server before, for avoidance of conflicts.

I think, that this page has to show user some indication of action progress(real or fictional), not just a static page, user has to refresh to see if it is finished or not. What user has to do – is just open once the site, see the message, that it is “Under construction”, and stay the page for a while.

It has to refresh itself until the time, deployment has finished. After that it has to load index page of new version’s website.

I wan’t to tell you, how and when this new index page is setting up. Right, all the deployment processes can vary a lot depending on the software it deploys, environment it uses, deployment tools etc.

What is highly recommended in most cases:

1. Install new index page with “Under construction” message

2. block all the web site’s pages, except index

== different actions here(DB updates, server restart, caching refresh etc.) ==

3. unblock all the pages(except index)

4. delete “Under construction” page

That is how, I did it:

It is an Apache Ant build file, with the following contents:

To install our “Under construction” page – just run:

It will backup your default .htaccess file, and replace it with new one, which catches all the queries and redirect it to the root of the web site.

And when deployment will be finished, run:

It will restore your default .htaccess file.

In attachment, you can find all those files you need to do the same.

That solution is not the best, and is not for types of projects.If you like the idea, mostly you’ll need to modify it to your demands and your environment.

Download an attachment

Have fun!

What we decided to do:

1. make a pack of all the Java scripts and CSSes, to reduce the page load time
2. make a static content versionable

If first is quite a common practise, I wan’t to tell more about the second point, on example.
We use an automatic deployment system. So installing of new software version can be done easily and takes little time. So, for example, if we faced some serious bug with CSS, something is very bad with User Interface and the problem is with some external CSS directive.

If we will just change solve the problem, locally in those CSS file, make a build and upload it to the server we’ll have some users, with loggined sessions and cached CSS files in browser. We have uploaded the fixed version of CSS, but user still see the old one, with bugs.

The same problems can arise with all the static content(java scripts, CSS files, images).  So we decided to make that content versionable too.  Main purpose is to force the browser to load new version of those content, when we deploy new version.

That is how we decided to do that:

if we change all the paths in HTML, to static content with some unique postfix, such as, for example “styles.css?ver1.2″ or “logo.png?ver39″ or even “logo.png?UUID-UUID-UUID-UUID-UUID”, we’ll force all the browsers to reload the files.  But, we have found that actual CI build number(not UUID or revision) works best for us, because it some bug arises we can know for sure, in what build is it, to make a bug fix and deploy new version.

I automated the process making the unique URL postfixes for static content while packing build, ready for deployment, by using the Apache Ant and sed. Here is the example:

That command search for all the files recursively in the build.dir folder, and replaces all the matches “BUILD_NUMBER” to build.number value.

To make this command run your view templates have to look like that:

So it will still works in development environment.

There are different ways of setting ${build.number} variable, depending on your repository vendor(if you want to tag it by revision number), continuous integration server(by using its build number), generate some unique string(UUID) and assign its value to the ${build.number} variable, or even to install ${build.number} value manually, but it is not desired.

For, example, here are some ideas:

http://www.zorched.net/2006/07/20/getting-the-revision-number-of-your-subversion-working-copy/

http://code.google.com/p/bamboo-ant-tasks/

You can reduce code duplication by using the wrappers for outputting the links for static content(images, javascripts and CSS).