views:

75

answers:

3

Hey guys! I run a small web development company along side with my brother and friend. After doing extensive research I have decided on using subversion for version control.

Here is how I currently plan on running typical development. Keep in mind there are 3 of us each in a separate location.

I set up an account with springloops (springloops.com) subversion hosting. Each time I work on a new project, I create a repository for it. So lets say in this case I am working on site1. I want to have 3 versions of the site on the internet:

  1. Web Development - This is the server me and the other developers publish to. (site1.dev.bythepixel.com)
  2. Client Preview - This is the server that we update every few days with a good revision for the client to see. (site1.bythepixel.com)
  3. Live Site - The site I publish to when going live (site1.com)

Each web development machine (at each location) will have a local copy of xamp running virtual host to allow multiple websites to be worked on. The root of the local copy is set up to be the same as the local copy of the subversion repository. This is set up so we can make small tweaks and preview them immediately. When some work has been done, a commit is made to the repository for the site. I will have the dev site automatically be pushed (its an option in springloops). Then, whenever I feel ready to push to the client site I will do so. The final stage will be to push to the live site.

Now, I have a few concerns with those work flow:

  1. I am using codeigniter currently, and in the config file I generally set the root of the site. Ex. http://www.site1.com. So, it looks like each time I publish to one of the internet servers, I will have to modify the config file? Is there any way to make it so certain files are set for each server? So when I hit publish to client preview it just uploads the config file for the client preview server.

  2. I don't want the live site , the client preview site and the dev site to share the same mysql server for a variety of reasons. So does this once again mean that I have to adjust the db server info each time I push to a different site?

  3. Does this workflow make sense? If you have any suggestion please let me know. I plan for this to be the work flow I use for the next few year. I just need to put a system in place that allows for future expansion!

Thanks a bunch!!

+1  A: 

1) Look into conception of Continuous Integration. (there are a dozen free for small projects CI servers , for instance TeamCity)

2) Having 1. Prepare deployment procedure that will be able to target any of your three environments

3) Consider ALWAYS check that there is no .svn files accessible to users on deployed sited, because it is really unsecure

Also read something on working with tags/branches in SVN

Next, I would propose the following workflow

First case (simple) Everyone makes checkout and works on local copy. Having commited (well tested) amount of new functional, your trigger (maybe automatically) preview to be build Having preview comprehensively tested, you trigger building production

Second case (better) Everyone makes a branch on every considerable amount of changes and is free to comit anything to his own branch. After having branch stable branch, you merge it to trunk what triggers test machine to checkout and build what you name preview and mark a tag Comprehensively tested preview goes to release branch

Point to have so many branches is to be able to store personal changes history and stable builds at once.

vittore
Does CI offer version control and such?
Roeland
CI is top level stuff.CI as a conception include usage of version control and it's usage stratage, testing, auto incremental builds etcCI servers helps you with all this stuff
vittore
Do you think CI may be over kill?
Roeland
frankly it may be, but what i suggest is to have at least clear stratagy on using version control and automatic build procedure.
vittore
+2  A: 

There are better version control solutions for distributed version control systems than subversion, I would highly recommend looking into one of these:

  1. http://mercurial.selenic.com/
  2. http://git-scm/
  3. http://bazaar.canonical.com/en/

see here, here and here for some unscientific discussion

also, as vittore said, I would consider a CI solution to be quite useful, that could automate your push from the dev environment over to "production" where the client could see it on a successful build/test cycle.

David
rawr. just spent last few days familiarizing with subversion.. :(
Roeland
Yeah I know, supposedly from those readings it's also a shift in thinking. I'm looking at moving from TFS
David
Well.. the scenarios Roland asked for are in no way easier with these 3 systems. Keeping all currently visible sites in one working copy is easily possible with Subversion, while you would be busy merging all unrelated changes from the co-developers with these DVCs. There are no DVCs with support for things like sparse working copies, (mixed revisions,) partial updates.. to allow sharing a single workingcopy on a server. So using a DVCS would require using a different workflow.
Bert Huijben
A: 

You don't want to use the root of your repository as the root of your working copy. That makes it impossible to really use branches later. (Or you would alsways have all branches checked out locally.. making Subversion's cheap copies, expensive in the working copy)

Bert Huijben