Reliable Systems - Software Development Blog

Obviously every project, technology and company are different, but there are some common practices which, when properly implemented, may cause everyone in the team to be less stressed out by the whole concept of “collaboration”.

The basic idea is - don’t interfere with other’s work if you don’t intend to.

If you ever had experienced a hell of working on a shared network drive and overwriting other people’s changes, then I think you might appreciate this post.

What I usually do (or: try to to within available resources and within constraints) is:

• Each developer, and programmer - namely: everyone who modifies code or “required resources” (in Web development - CSS, images, etc) has his own development toy-server installed on their local computer.
• The database can be either installed aside the local server, but I advocate all developers to use a shared database installed in the local network. The drawback of this solution is obvious - anyone can modify the database and cause your version of the system to stop working. But the thing you gain is more important - you are sure that your changes are affected in others’ systems and that their code doesn’t cause any problems with the structure you’ve created. This can obviously cause some downtimes when the database schema changes radically, but these cases don’t change very often in real life, at least not in the later stages of most projects.
• Now comes the “internal server” used by developers to deploy the application for others’ usage. Typically this is the place where the “last good” version of the application is stored - and this place should be updated as frequently as possible (preferrably - by an automatic script triggered by any change in the code repository). The thing is - if you don’t have a way of automating the deployment of the code from the repository - this copy of the system becomes obsolete
• Internal Staging environment - place where all the “proper” testing takes place. This is suggested to be different from the “last good” version because testers may want to see if the bugs they submitted are resolved correctly in the “last good” version, but the “staging” might not be updated as frequently. The reason being - “last good” version can contain unfinished code which might cause the system to stop working, and the last thing you want is to have your “staging/testing” version down.
• Once per day/week/any other time (periodically) the “last good” version gets copied onto the Staging environment and gets sent to testing.
• When the staging version is good enough, which means - satisfactory in terms of bugs and functionality - we can consider copying it onto the Live system to upgrade it.
• I would advocate the “last good” and “staging” versions of the system to use a shared database, but you can run into all sorts of issues with that configuration, especially when changing the database structure. You just have to see what works for you and what doesn’t.
• As the Live system is the most crucial part of the infrastructure - I would advise the live database to be updated manually each time you do an update from the staging environment - to minimise the risk of data loss or corruption.
• Don’t forget to schedule backups of your live database from the stage when it contains important information!

This is all good and nice, but how to actually implement the process?

It obviously depends on your environment, as far as I’m concerned in the PHP environment it isn’t very hard.
What comes with help for you is:

• Both MySQL and PostgreSQL allow you to make a full database dump into an *.sql text file and import it into the target database - and this process can be automated (this is highly recommended).
• Subversion allows you to attach scripts to its events - the most frequently used handle is the .postcommit one, which executes every time a developer commits a part of the source code. This script should update the “last good” version by copying over the updated files from the repository into the “last good” environment.
• You can also create scripts on your internal testing server which will copy over the “last good” version to “staging” environment at wish, so you won’t waste time doing it manually - trust me, it isn’t a creative or rewarding task

As I say, this is just an infrastructure, now you need a good process in place for task management and responsibility management - but that’s a material for another post.

As for the project management - I’ve got one, in my opinion most important advice - dont’ use the paper. It becomes obsolete 10 seconds before you print it out.