We use Team Foundation Server and have numerous ASP.NET Web Application Projects. Each of the Web Apps uses a custom content management system that we’ve developed in house. The CMS is itself, an ASP.NET web app.
When deployed, the CMS resides in a subdirectory, such as “/Admin”. The CMS is comprised of .aspx and ascx files, and the corresponding assemblies are, of course, placed in the bin.
Presently, the CMS files exist separately for each Web App in source control. In other words, an “Admin” folder exists in each web application that depends on the CMS. This poses obvious challenges since updates to the CMS must be distributed to every dependent site. It’s my job to automate/simplify the process.
We currently do not perform any automated builds. I have limited knowledge of source control branching in TFS and I’m not sure that it’s applicable in this scenario. What is the best way to ensure that dependent projects receive the latest assemblies and markup from the CMS project? Thanks in advance.
It sounds like #2 (from ‘bamboo) is the solution I’m after. Given that the shared code already resides in each individual project, can you briefly describe the process that I’ll go through to “Branch/Share” the CMS? Also, it’s worth noting that I do not want the .cs files propagated to the dependent projects, just the markup and assemblies. Does this change the strategy? Should I first create a build event on the shared project to copy the requisite files to a “Release” folder, and then branch the Release folder?
The are a couple popular ways to handle this scenario.
Map the TFS project for the shared stuff to each applications workspace and then include the shared project in each applications solution. Use this method if you want all teams/apps to get the shared changes immediately when they build since they will get latest of the shared stuff as well.
Branch/Share the shared stuff into each applications source control tree. This is easy to do in TFS. This is really good if each team/app wants to control when they get the latest of the shared stuff. This keeps the teams being able to do their thing until they are ready to integrate the shared stuff.
I generally always prefer #2. But it really depends on the specifics of how you need/want to work.