Team Development

[Shawn Berg]

I have just finished reading the "Team Development with Visual Studio .NET
and Visual SourceSafe" patterns & practices white paper. I just wanted to
get a good feel from others if what they suggest here is really the best
implementation for team development. My company only has a handful of
developers (2 currently, as many as 5 possibly in the future) that need to
work on the same ASP.NET projects. All of our existing apps are in classic
ASP and we do not even use source control since there is only two of us and
we communicate well . We simply use InterDev to connect to the web site
and edit the files necessary as long as we know the other isn't working on
it as well. This white paper suggest setting up Visual SourceSafe in such a
way that all code will be executed on the developer's actual workstation,
which is a big concern for me.

Following are a few things in this white paper I do not understand:

1. Since all code is executed on the developer's workstation, and not on the
development web server, how will images, external javascript files, etc. be
referenced? Will the ENTIRE site be copied to EACH developer's workstation?
Our sites are rather huge and this may not be a good idea. We also do not
want to put the entire web site in Visual SourceSafe -- only the .NET/HTML
code. In other words -- no images, flash files, etc. in VSS.

2. How can we be sure our development server is updated upon files being
checked in? I'd like our development server to always be running the latest
version of the software available (meaning a rebuild would be necessary
everytime code changes). How can we implement this on a development server?
This is required for our QA department to always be able to test the latest
version of our sites.

I know I'll think of some other scenario's as well, but these are just a few
of my first concerns. Is there an easier way to work on ASP.NET projects
with other developers withOUT using VSS and making things this complicated?

Thanks!

Shawn

 

[Karl Seguin]

Shawn:
That guide is gold. Everything they say is on the ball and totally worth
following. To answer some of your questions:

"all code will be executed on the developer's actual workstation"

When developers debug an application it locks the IIS process.. If you
develop on a shared server you'll have serious problems because of this.
Also, you don't want one developer's broken build to break all other builds.

1 - You should go all in, not partially else youl'l run into these problems.

2 - That guide talks about the "build process" and through the build process
and continuous integration (via CruiseControl.Net) you can easily keep a
server up to date..

It seems to me that you haven't fully bought into the benefits of source
control. Until you're there, I wouldn't bother and I'd stick with the "good
communication" approach. .

Karl

 

[jasonkester]

we do not even use source control since there is only two of us and
we communicate well . We simply use InterDev to connect to the web site
and edit the files necessary as long as we know the other isn't working on
it as well.

First off, Yikes! You have a SINGLE copy of your code living in a
SINGLE place? As in, one errent delete away from oblivion? And no way
to track down changes that may be causing bugs?

Following are a few things in this white paper I do not understand:

1. Since all code is executed on the developer's workstation, and not on the
development web server, how will images, external javascript files, etc. be
referenced? Will the ENTIRE site be copied to EACH developer's

workstation?

Yes. All the code is on your box. A 200GB hard drive costs $200. Are
you saying you can't fit your Huge site on one of those?

And Yes, ALL the code is in source control. Even the images and .SWFs.

2. How can we be sure our development server is updated upon files being
checked in?

Build & deploy from VSS. You can do that. No, really you can!

Is there an easier way to work on ASP.NET projects
with other developers withOUT using VSS and making things this

complicated?

I think you will soon discover the true meaning of "complicated" if you
continue with your current process. Everybody screws up from time to
time. Personally, when I need to roll back a whole day's worth of
changes that inadvertently broke something, I'd rather not have to do
it by hand.

Good luck!
Jason
http://www.expatsoftware.com/

 

[Ken Cox [Microsoft MVP]]

Hi Shawn,

We followed that guide almost to the letter in a small team of 4-5
developers for an ASP.NET project and it was very good. The worst problem
was with VSS which sometimes got corrupted and had to be repaired.

The key to working that way is to have a rule that no one can check in a
page if it doesn't build without error. It doesn't have to be complete, it
just has to compile. If there are errors and you "get latest", you're stuck
with bad code on your machine.

When we thought we had a build to send to QC, we'd get the latest and test
it locally. Then, someone would compile the project and post the relevant
files to the development server. After a test there, we'd label the build in
VSS and tell QC to go get it.

Ken
Microsoft MVP [ASP.NET]

 

[Shawn Berg]

Ken,

Thanks for your informative and encouraging response. After the brief
convincing here, I am definitely moving forward to put this environment into
place.

The reason I originally asked about the web site existing on each developers
workstation as well is because we have some virtual directories that hold
hundreds of gigabytes of videos and image files, and there is absolutely no
reason to keep these under source control, and to push them to each
developers machine. The problem posed, however, is that some of the code on
the ASP.NET web sites we will be placing in VSS will need to access the
files in these subdirectories programatically. Is it possible to test that
without copying hundreds of GBs of data to each developer's workstation?
This data is also updated frequently and will cause a network bandwidth
nightmare if it will have to be updated on each developer's machine. Maybe
somebody could explain a little better exactly how this works?

Also, I planned on putting VSS and it's databases on a server separate from
our development Web server. This seems standard, but not exactly clear in
the white-paper. Is this common?

Shawn

Hi Shawn,

We followed that guide almost to the letter in a small team of 4-5
developers for an ASP.NET project and it was very good. The worst problem
was with VSS which sometimes got corrupted and had to be repaired.

The key to working that way is to have a rule that no one can check in a
page if it doesn't build without error. It doesn't have to be complete, it
just has to compile. If there are errors and you "get latest", you're stuck
with bad code on your machine.

When we thought we had a build to send to QC, we'd get the latest and test
it locally. Then, someone would compile the project and post the relevant
files to the development server. After a test there, we'd label the build in
VSS and tell QC to go get it.

Ken
Microsoft MVP [ASP.NET]

I have just finished reading the "Team Development with Visual Studio ..NET
and Visual SourceSafe" patterns & practices white paper. I just wanted to
get a good feel from others if what they suggest here is really the best
implementation for team development. My company only has a handful of
developers (2 currently, as many as 5 possibly in the future) that need to
work on the same ASP.NET projects. All of our existing apps are in classic
ASP and we do not even use source control since there is only two of us
and
we communicate well . We simply use InterDev to connect to the web site
and edit the files necessary as long as we know the other isn't working on
it as well. This white paper suggest setting up Visual SourceSafe in such
a
way that all code will be executed on the developer's actual workstation,
which is a big concern for me.

Following are a few things in this white paper I do not understand:

1. Since all code is executed on the developer's workstation, and not on
the
development web server, how will images, external javascript files, etc.
be
referenced? Will the ENTIRE site be copied to EACH developer's
workstation?
Our sites are rather huge and this may not be a good idea. We also do not
want to put the entire web site in Visual SourceSafe -- only the ..NET/HTML
code. In other words -- no images, flash files, etc. in VSS.

2. How can we be sure our development server is updated upon files being
checked in? I'd like our development server to always be running the
latest
version of the software available (meaning a rebuild would be necessary
everytime code changes). How can we implement this on a development
server?
This is required for our QA department to always be able to test the
latest
version of our sites.

I know I'll think of some other scenario's as well, but these are just a
few
of my first concerns. Is there an easier way to work on ASP.NET projects
with other developers withOUT using VSS and making things this
complicated?

Thanks!

Shawn

 

[Ken Cox [Microsoft MVP]]

Hi Shawn,

We had a similar situation where we had thousands of PDF files on the file
system that were triggered by and linked from our Web application and a
backend database process. On everyone's machine, we set up a virtual
directory in IIS that pointed to a common mapped drive on another file
server. That's where the PDFs were stored. I can't recall the detail now but
it seemed to work very well except when we had to change the passwords that
IIS kept for the remote server. That caused a fair amount of confusion for a
while because the app would break without explanation.

Of course the files we were creating and referencing were demo files. We
used the web.config and a little code to detect whether the PDFs were to
come from the development remote server, the QC remote server or the
production remote server.

So, you shouldn't need to copy anything more than the updated source code
files and a few images that are part of the Visual Studio project that you
are checking out from VSS.

Ken

Ken,

Thanks for your informative and encouraging response. After the brief
convincing here, I am definitely moving forward to put this environment
into
place.

The reason I originally asked about the web site existing on each
developers
workstation as well is because we have some virtual directories that hold
hundreds of gigabytes of videos and image files, and there is absolutely
no
reason to keep these under source control, and to push them to each
developers machine. The problem posed, however, is that some of the code
on
the ASP.NET web sites we will be placing in VSS will need to access the
files in these subdirectories programatically. Is it possible to test that
without copying hundreds of GBs of data to each developer's workstation?
This data is also updated frequently and will cause a network bandwidth
nightmare if it will have to be updated on each developer's machine. Maybe
somebody could explain a little better exactly how this works?

Also, I planned on putting VSS and it's databases on a server separate
from
our development Web server. This seems standard, but not exactly clear in
the white-paper. Is this common?

Shawn

Hi Shawn,

We followed that guide almost to the letter in a small team of 4-5
developers for an ASP.NET project and it was very good. The worst problem
was with VSS which sometimes got corrupted and had to be repaired.

The key to working that way is to have a rule that no one can check in a
page if it doesn't build without error. It doesn't have to be complete,
it
just has to compile. If there are errors and you "get latest", you're stuck
with bad code on your machine.

When we thought we had a build to send to QC, we'd get the latest and
test
it locally. Then, someone would compile the project and post the relevant
files to the development server. After a test there, we'd label the build in
VSS and tell QC to go get it.

Ken
Microsoft MVP [ASP.NET]

I have just finished reading the "Team Development with Visual Studio .NET
and Visual SourceSafe" patterns & practices white paper. I just wanted to
get a good feel from others if what they suggest here is really the
best
implementation for team development. My company only has a handful of
developers (2 currently, as many as 5 possibly in the future) that need to
work on the same ASP.NET projects. All of our existing apps are in classic
ASP and we do not even use source control since there is only two of us
and
we communicate well . We simply use InterDev to connect to the web site
and edit the files necessary as long as we know the other isn't working on
it as well. This white paper suggest setting up Visual SourceSafe in such
a
way that all code will be executed on the developer's actual workstation,
which is a big concern for me.

Following are a few things in this white paper I do not understand:

1. Since all code is executed on the developer's workstation, and not
on
the
development web server, how will images, external javascript files,
etc.
be
referenced? Will the ENTIRE site be copied to EACH developer's
workstation?
Our sites are rather huge and this may not be a good idea. We also do not
want to put the entire web site in Visual SourceSafe -- only the .NET/HTML
code. In other words -- no images, flash files, etc. in VSS.

2. How can we be sure our development server is updated upon files
being
checked in? I'd like our development server to always be running the
latest
version of the software available (meaning a rebuild would be necessary
everytime code changes). How can we implement this on a development
server?
This is required for our QA department to always be able to test the
latest
version of our sites.

I know I'll think of some other scenario's as well, but these are just
a
few
of my first concerns. Is there an easier way to work on ASP.NET
projects
with other developers withOUT using VSS and making things this
complicated?

Thanks!

Shawn