ASP.NET, source safe and promotion levels

J

Jon Paul Jones

For some time now, I have been looking for a build system for ASP.NET that
will merge the file based ease of deployment of classic ASP with the type
saftey and prebuilt nature of ASP.NET with codebehind. The team that I work
on manages several web sites and we have many different projects (not VS
projects) going on in each site simultaneously. Each of these projects may
have different deployment schedules. In a classis ASP world this was
(mostly) not a problem because you could work on one file and push out the
changes to that one file only, not affecting other parts of the site. In the
ASP.NET world with codebehind, changes can not be put out individual as
easily due to having to build the system as a whole.

Has anyone found a solution for this type of scenario? What I had been
thinking about doing was to use labels in source safe to "promote" files.
When a file was ready to move to the next level (like from development to
testing) the individual files that needed to be moved to this new
environment would be labeled as "test". Then, a customized build process
(probably using NANT) would get the files with the "test" label and build
the system. There might be more than one set of changes (i.e. project (again
not VS project)) that had a label of "test" at any given time. When a
particualr set of changes has finished the testing phase, the files that are
part of the change set would be labeled "stage" and then another build
process would take the "stage" files and build the system to go to the
staging server. These changes would then be retested on the staging server
and then copied to production at night. After the copy, all files with a
"stage" label would be labeled with a "prod xx/xx/xxx" label to give a
unique label for that production build.

Does anyone do anything like this? Is there any reason this would not work?
Is there a better way?

The only problem I can think of with this is that it might not be pratical
to use NANT's "solution" tag to read in the VS.NET solution and project
files. This is because you would need to be able to promote the solution and
project files and these would be in contention and might have changes that
did not need to be promoted with your change set. I have not looked in to
this fully yet, but I'm guessing that a NANT build script would need to be
created and maintained for both test and staging environments. These scripts
would need to include references, default imports and other settings to
support the current files being built for that environment.

If someone knows of a better way or has some insight, please let me know.

Thanks...
 
S

Scott Allen

Hi Jon:

So if I read this correctly - you'll be deploying only the changed ASPX files
between builds?

I prefer to have the entire ASP.NET application built and deployed as a whole.
I have a build engine that will apply a label to all the files in the source
repository needed for the project, then pull files by the newly applied label
(the label is typically just a product name and build number, like FOO.4567).
The projects are built and then everything is packaged up for easy deployment
to a test server.

The advantage is I can look at a build that is deployed in test or production
and easily recreate the exact set of files used to put the software together.
All of this was put together before the rise of Nant. I've thought of moving
to Nant but I think at this point I'll wait for MSBuild to arrive this year.
 
J

Jon Paul Jones

No, I was thinking that the web project would always be deployed as a whole,
but that individual files (.aspx, .vb, .cs) could be promoted individually
to be included in the next build. I was probably going to label all the
sources that were at a particualr build level with a unique build number
like you are talking about. Like I would label everything that currently
has a "test" label with a new "test some_build_number" label then get these
files and do the build.

The main thing I am trying to acomplish with this is to be able to build the
files that are ready to be built for a particular point in the application
development lifecycle. If there are files in testing but are not ready for
production, I do not want them built in the production (or in our case
"staging") build. If two files have changed and have been promoted to
(labeled as) "test", I want to then be able to promote maybe just one of
these files to be built in the "staging" build. Does that make since?

If your build script does this type of build, could you possibly post it or
email it to me? If you can't I understand but I would like to see how
someone else does this. I'm not wanting to wait for MSBuild since that is
several months off. Plus, I'm not sure that MSBuild by itself will be able
to do what I want. Team System might be able to handle this though.
 
J

Jon Paul Jones

I have studied the team development guide several times in the past and I do
not think that it solves my problem. I think it is suited towards
development teams that work on release schedules. For these people, all
code has to be ready for testing (or staging or production) or something has
to be backed out before the build. The team I work on can needs more
granularity than that. The BuildIt system also uses VS to build based on
solution/project files and this would also be a problem since the files that
are at a particular promotion level may or may not be in the current VS
project file. This would happen in cases of additions or deletion of files
from the project. Promoting the correct version of the project file might
be difficult to do so either having seperate solution/project files for each
build environment or just not using the solution/project files at all might
be a solution.
 
P

Patrice

When archiving files are copied to a "shadow" directory. The web application
is compiled on this server using the command line compiler allowing to
create multiple DLLs. We can then deploy the needed single DLLs without
updating other DLLs...

Patrice


--
 
J

Jon Paul Jones

I'm sorry, I do not quite understand what you mean here. What do these
multiple DLLs contain?
 
P

Patrice

Each DLL contains a subset of our web application. The "trick" is that
compiling a web site into a single DLL is just how VS.NET works (for now).
You can use directly the compiler to compile a web site into multiple DLLs.

This way you can pick from those DLL the one you want to deploy on your
production server while leaving other DLLs unchanged...

From the begining of your post I thought this could be another way to
achieve what you are looking for (i.e. deploy a particular "module" for now
by looking at building a single DLL with all the latest "ready for
production" files for all modules ?)

Patrice


--
 
R

Rusty Zarse

You are absolutely on the right track! We implement a very similar methodolgy in my development group.

Files ready for integration (promotion) are labeled with the version number of the project for which the change is intended. Make sure to prefix your label so it can never look like a date or VSS will get confused and fail (we are eager for team services). We use Bx.xx.xx (B1.03.01). B stands for Build. A version is tied to an intended release. So B1.03.xx may go out this month but B1.04.xx is slated for next month while B2.01.xx is going out sometime next quarter. Every build for QA increments the build number on a particular minor version until it is passed and deployed. Then, the minor version is incremented.

When a file has multiple releases for which it is being changed, developers must coordinate their changes so that modifications for future releases don't get picked up by intermediate builds. However, this is no different than we were used to with classic asp files. If you see a label, that means the changes are intended for that version. If you see no label, that means the changes are still in progress or the developer forgot to promote. Either way, it requires further action to resolve.

The build system is a home grown windows app that integrated vss with nant. I found alot of bugs in vss that required some programatic work arounds (mostly getting by label) so the application was necessary for us. I think these bugs are resolved with a patch from microsoft on VSS but I do not have admin rights on vss and was unable to get this update applied in my shop.

The application manages dependencies in an xml file very similar to the vs solution file. I decided that any .cs file labeled for promotion should be included so the vs project file is not used.

Builds are incremental. Therefore, the previous build's source code is necessary before labeled files can be built on top of them. All Source code is duplicated in a release vss tree. The compiled build is checked in parellel with its source.

The application performs the following steps:
1) check out the entire release tree to a local working directory for all projects to be built.
2) get latest for all projects from the development source tree.
3) using nAnt, follow the dependency chain to the bottom and build the first level projects. (if a project has a dependency that must be built, control is transfered to build that project). Moving through the config document, build each project.
3) if the builds were all successful, check all project release trees back in. Otherwise, uncheck the checkouts.
4) if the builds were successful, label them with the build version label plus a timestamp
5) email the build report to an email list (also in the xml config file)

Every solution can be represented by an independent config file.


I found that managing many project dependencies became a burdon because the label retrieval takes longer and longer as the depth of history increases in vss. The builds take 20 minutes. this isn't really that bad considering how long it takes a developer to set up a new environment (a different topic) but it is annoying if a build fails due to one missed label. Consider versioning your internal assemblies as if you were shipping them to clients and managing dependencies that way. You'll find you change the same 2 or three projects very frequently and the rest very infrequently.

I hope that helps.

I think this entire process could be managed using nAnt if the get by label thing were fixed. I am not sure. You may want to try that first.

If you have any quick questions: rusty.net -at- vitaminzrecords -dot- com


Posted via DevelopmentNow Groups
www.developmentnow.com/g
www.developmentnow.com
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top