Current workflow using SVN
At my place of work we currently use Svn in the office for our version control. Altogether their are 10 dev which use the codebase its a mixture of four frontend developers and six backend developers. As a team we have been using SVN for over five years. I’m going to describe a high level overview of our svn workflow in the office.
Most of us use TortoiseSvn as our main svn client with a couple of the guys using the command line. I tend to use my editor built in tools as my svn client. The following steps are no means the best way to work, but we found this works best for us. We are always continuing refining this process.
- We tend to work of feature branches. So if their is a task we create branch. It can get tedious for small tasks to create a branch. But what we found that grouping up tasks if one of them get delayed the deploy gets held up waiting for the all the features to be signed off.
- Once the dev is ready to start the task. We create a branch from the recent version of trunk. During the task or tickets as we call them in the office, its up to the developer to keep the task up to date with trunk. But since most of the time the tickets are small we wait until we are ready to merge into trunk.
- Once the ticket is complete we then put the branch into code review. We use a tool called review-board. Once the work has been signed of by two other developers it then leaves code review.
- The next stage the ticket goes to QA once passed it goes to to UA to get signed off.
- Once the ticket is signed off we would merge the latest changes from trunk into the branch. So we can pick up any latest development on trunk. We then test that the task is still working correctly.
- Once we have ran the test to see that the task as not caused any problems with trunk. We then merge the ticket into trunk. Then we would do the final tests on of the site on our pre production server. The code is then deployed on the next deployment window which is usually weekly.
We tried several different workflow but we found this one works best for us especially when you have several developers working on a task.