views:

14

answers:

1

Hi All,

I work for an agency that has been responsible for maintaining a client’s .net 3.5 website for a number of years along with another agency. Work is farmed out by the client to both agencies on a pretty much ad-hoc basis.

The site is quite old and has a structure and deployment process to match. The site is setup that developers have local copies of the sites. There is a staging environment, where client feedback and approval happens, followed by the live environment. There are a number of scenarios where work from one agency will be on the staging environment awaiting approval, and changes from the other agency need to go through staging, approval and deployed to live without the original changes being affected. Most of the time we get away with it but it’s far from ideal as not all conflicts can be resolved.

Up until recently we had still been on Sourcesafe but have moved over to Subversion and are running into many more scenarios where work is overwritten. This obviously isn’t a fault with subversion, rather that the locking of projects and files in Sourcesafe served as a good indicator to developers from both agencies that someone was working on that project or file. The process previously was that you checked out a file from sourcesafe and kept it checked out until changes went live (acknowledge that this is a rubbish process hence the desire to move away from sourcesafe and such a model)

The trouble is that even though we know that the way we do it now is bad, I’m at a bit of a loss as to how to restructure the overall site and deployment process to make it “better”. Some ideas we’ve pondered are:

  • Separate dev, test and live branches in subversion so we need to commit and build the appropriate branch before deploying (not really sure how to make that work)
  • Single repository for both agencies but a separate staging environment for each. Staging environment could then reflect the changes assigned to each agency
  • A separate instance of the staging site for each branch

Any suggestions of next steps or examples of similar situations and solutions from the SO community would be greatly appreciated!

Thanks

Joel

A: 

I would recomend:

  • Use git, its really very good for working out how to merge changes.
  • Have seperate staging enviroments for each company, then, once changes are approved, merge (carfully) into a final staging environmet that only exists to help sort our merging issues there, then push to live.
  • Also make sure both agencies know who's working on what and try to wait for the other agency to finish working on part X of the app until the other has finished, in the end this is the best solution, a little bit of comunication.
thomasfedb
Thanks for the comment. I haven't used git before so will definitely have a look into it.I like the idea of separate staging environments but how would you see the process of merging into a final staging environment working? Does the setup of (or how we use) subversion need to change from just using the trunk??
Sorry, never used subversion, though I know it's popular. I see the final staging area being "held" by one of the parties at a time, while still alowing the individiual staging areas for testing.
thomasfedb
I think what we're going to go with is a split test environment for each company as well as separate subversion repositories for each company. We will then have a "pre-live" environment for integrating and testing changes before deploying live. There would also be a main subversion repository where we would merge into when we sent something live...subversion handles the merging of branches quite well.We'll try this out but, in theory, it sounds like a valid approach that would solve a lot, if not all, of our problems
Glad I could help.
thomasfedb