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...
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...