Just some overview notes on the subject.
There are many vcsâ€™s around both free and paid for. The type of VCS while important is not as important as actually using. From the single developer up to big teams there is no way you should be coding without a VCS.
There are centralised systems such as Subversion where the project is held on a central server and developers check out and in and deployments are made from this central repository.
Then there are distributed systems, DVCSâ€™s, such as Mercurial and GIT. With these the developer has a local repository, does all the development, checking in and out locally and when appropriate will push changes to another remote repository to be merged.
See the end of this post for various links
Some of the points to be kept in mind when using VCSâ€™s
- A VCS does not replace communication between members of a team
- Clear processes and guidelines on how to use the system need to be in place, especially when, as you inevitably will, break them to help recover gracefully.
- Read the book. SVN, GIT and Mercurial have books online that are free to read or download. They donâ€™t have to be read from cover to cover and can be skimmed to get a feel for which is the right one for you.
- Before doing anything moderately complex take a backup of the repository. That way you can blow it away and start again without shafting your repository.
Branching Merging and Tagging
In SVN the practice is to have three directories, Trunk, Tags and Branch. For DVCSâ€™s the conventions are somewhat different but I am going with the SVN nomenclature to simplify things.
- The trunk is always the version that you would go live with.
- Tags are one off snapshots of the trunk and are not used for further development.
- Branches are for development work.Â A copy of the repo is taken and worked on. During the life of the branch updates can be made from the Trunk if say bugs are fixed on the Trunk to keep the version in sync.
- At some point the Branch will be merged back into the Trunk, which will be fraught with pain and angst but at least you will have the tools and the ability to see what you are doing roll back.
- Once this is done the branch is left but not used again and a new Branch made for the next level of development.
For DVCSâ€™s the picture is similar as a process but different in execution. Here the repositories can be cloned in total and worked on as a branch and then merged locally and then again merged with the remote/master repository
Development is done on local machines, checked out, worked on checked in or merged and then the deployed to the test environment (you do have a test environment donâ€™t you?) and if it passes then deployed to the production server. Ok thatâ€™s a simplified version but something along those lines.
- Rule 1 Do not deploy directly from the repository
- Rule 2 Do not deploy directly from the repository
- Rule 3 well you get the idea.
Deploy to a staging area and then to move to the test server or the live server by using shell scripting that will consolidate, add, edit, alter the files and then deploy them automatically.
rsync is a highly effective way of moving files from one server to another and has a plethora of options such as –delete which will remove files from the target server that have been deleted in the repository, therefore keeping the server uncluttered.
exclude which can be pointed to a file will allow you to exclude file, say config files which differ between test and development
it is also possible that all the assets are not in the repository. Storing assets such as images do not scale well in version control systems because these files are already binary, so a minor change can mean the whole file is altered and then stored in the VCS. This can add significantly to the repository size which will reduce its effective transfer speed.
The other major advantages of scripting the build is the speed of deployment, the fact that you will make far less mistakes especially when you need to deploy under pressure. It allows you build unit tests in and it opens the route to continuous integration in the future.