views:

88

answers:

2

Trying to keep it simple, but with almost no experience in version control, here is what I came up with for version and deployment workflow for a facebook application that is already live:

Development:

  1. branch from trunk

  2. checkout and setup dev enviroment (automatically create database, netbeans project, facebook app, config file);

Staging (same as development branch):

  1. run tests (manually);

  2. if ok - svn commit and merge development/staging branch with trunk

  3. Post-commit hook to deploy project to live server and update production database if needed.

Synchronize different development branches - if one development branch graduated to production, merge it with the other branch(es) still in development.

Are there any blaring mistakes with this workflow? Or any suggestions on how to improve it.

PS: I'm the only developer for now.

Image to illustrate the above.

+4  A: 

It sounds a little complicated.

Why do you need branches for staging? If you are using a developer-branch type of workflow, as soon as you merge back to trunk, this can be what you deploy.

Especially since you are the only developer for now, this sounds like excessive branching and merging for Subversion. I would try to make life simpler for yourself, and try to keep to one of the common branching patterns.

Avi
A: 

For one developer it's unnecessary, just develop on your staging branch and merge into trunk when ready.

Feature branches (your proposed workflow) - work well on large code bases where projects/releases need to be developed in parallel.

Release branches - work well for small code bases where projects/releases follow an iterative development cycle.