Session management after automated deployment best practices

Now, I’m working on automated deployment platform for LAMP
environment, using Apache Ant.

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:

mysql –user=your_username –password=your_password your_database_name -e ‘TRUNCATE TABLE sessions’

It is quite simple solution and most important working solution, in most cases it is enough, BUT :-D
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.

Tags: ,

Leave a comment

You must be logged in to post a comment.