I wanted to write a quick post explaining the way our internal staging and live workflow works with Subversion. It's simply but it works great. And great things are worth sharing.
Every website that we build and host at Open Door Internet has two versions: live and staging. The staging version is where we test stuff and make sure it works. The live version is where we move that stuff once it is working.
The staging version of a website is accessed via a different website address which clients and developers are given where required.
Sounds simple right? In principle; yes it is.
This means we're never editing the source code of a live website, which means we never break live websites. Which is good.
Each website has it's own Subversion repository. This is a bit like a folder for storing files in; except it uses 'version control'. Version control means that we can easily restore older version of a file, or merge changes made by different people. It stops us treading on each others toes.
The developer uses their NetBeans IDE (integrated development environment) to write their code, and each time they want to upload it to the server they 'commit' it to the Subversion repository on the server.
A post-commit hook automatically executes an 'svn update' command in the folder for the staging sub-domain.
So; every time a developer 'saves' their files by committing them to the remote subversion repository the staging website is automatically updated to that version.
To keep things simple the live and staging versions of the site normally share a database and they also share a 'userfiles' folder (using a symbolic link) where user uploaded content is stored. This means that the live and staging versions can't ever get 'out of sync' with each other, which is potentially a big problem when using version control like this.
Sometimes we're making really big changes to a website that are too risky or disruptive to share the userfiles and MySQL database. When we do this we simply create a new development site (which most likely will also have a live and staging version itself).
When we're happy with a staging version of a website the lead developer on the project can use SSH to navigate to the live website root and execute an 'svn update' command. This updates the live website folder with the latest version of the website (the same one that is on the staging website).
Simple right?
One of the greatest things about this system is that it allows junior and trainee developers to work in a production environment without significant risk of breaking the live website.
