Multi projects and deployment

If I have to define a wish list wish for the next release Whidbey I would like surely to add this.

I have a web project A deployed on a production server. After few months of good services, the site needed some new features and improvements.

So I deployed another project A on another development server B to implement and test the changes.

The difficulty here is the site A in production must continue its life cycle with daily updates.

So I am stuck here by the fact that I can't have on my development machine twice the same project using the same name, for two different servers.

Of course I can change the name on the server B, but when I would like to put it in production, I will have a lot of issues with page inheritance because they refer to B and not A.

On my development PC, obviously my local IIS don't let me having twice the same name

So the solution could be something like:

Development:                       Test:                                   Production:

Project A  ------------------------------------------------[

                                                                                    Project A

Project B(copy of A)--------[  Project A  ------------------[

The new project A obviously should be release on production after approval on the test platform.

IMHO I think the Copy Project button should be improve. I know that the notion of Project doesn't exist anymore on Whidbey, and maybe refactoring can also be an idea to dig.

But is it possible to make it simpler ?

I think this is one thing I dislike in the current VS version, the lack of global deployment environment. I would like to declare a set of servers rather than deploying to one machine at a time.
I mean something to let me deploy the projects for test or production, VS knowing the details of my network.

Maybe the notion of relational links between the servers can also be a way to explore.

 

3 Comments

  • These are issues that require a proper SCM (Source Control Management) solution, which is part of VSS's domain. Unfortunately, VSS is not particularly adept at this.



    VS is not a particularly adept at this. You should look at nAnt to automate a build, and another source control system, which allows you to branch a solution more effectively.



    The reality (whether you use VS or not) is that developing two (or more) branches of a solution (and the associated config issues) is never simple.



    When you work on version 1.0, you don't really want any of version 2.0 on your dev machine, and vice-versa.



    If you are on your own then it's a lot simpler. When there is more than one developer on multiple projects and multiple versions, it's a difficult problem, and VS is not the solution.

  • Just to clarify, Visual SourceSafe is not a very good at SCM and Visual Studio has not really been designed as a deployment tool.



    Look at these technologies...



    * Vault for SCC

    * nAnt for automating builds

    * CruiseControl.NET or Draco.NET for continuous integration (not really necessary if you are on your own).

  • Thanks for your ideas, but I already know VSS and yes I am one developer here only.

    But I surely think it could be a good idea to maintain two identical projects for different purposes. After all at the assembly level, you can now deploy without breaking the previous assemblies, sorting out the old DLL hell problem.

    so why it's so difficult to have the same at a higher level.

    Look at my little drawing in the post. 2 different versions of the same project on my machine but one project at the very end on the production box. Of course at the end I have to choose between. But the idea that my current project A could still be updated by someone else when I am working on some imprtant upgrades is something interesting, and I am surely not the only one to want this.

    I am not sure but I remeber now that Golive has something like this. Hmm I am going to dig there to see.

Comments have been disabled for this content.