Brief:
I work in a 2-men team (we may expand in future).
We’ve got a web-dev server and we’ve got a production server.
Currently, when we start development, we start them on localhost, then we deploy them to web-dev (which we have access through a mounted drive) and we submit changes from this “shared” drive to SVN. Final test on web-dev, approval from the top and off it goes through FTP to our production server.
(I can hear lynch coming…)
Yes, I’m aware it’s all wrong with sharing files from one location and submitting it from there, but this wasn’t such a bad idea back then when I got to know SVN. And now I want to change it.
So, I know basics of version control, and that the way it works now is wrong big time. I’ve gone through wikipedia and some svn pages, but I couldn’t find a perfect solution how it should actually work.
Could some of you well experienced people suggest how this should actually work?
Things I’ve found out:
- we should work on local copies on our machines
- then we submit changes to SVN.
Things I want to know:
- how do we make web-dev update after SVN commit?
- how to deploy patches to production server? ftp files? is this what you do? or some other clever solutions?
- anything else I should know about web-dev workflow.
Subversion has post commit hooks which allow you to perform actions on a commit.
You could also look at a continuous integration solution like CruiseControl.net or Team City.
Our process is individual developers work on local configurations. We commit to Subversion and CruiseControl.net checks out and builds the system every time one of us commits.
There’s a scheduled build for update installer that runs weekly and updates the install on a server that QA use to verify fixes. Once the fixes are verified, someone (manually) applies the update that was applied to the QA server on the production sites.