Enterprise Templates and Source Control
Infusion Development Corporation
Summary: This article discusses the importance of source control requirements when designing Enterprise Templates. Three source-control models are discussed, as well as explaining how you can decide which models best fits your developments needs. (6 printed pages)
At first glance, Enterprise Templates and project source control seem to be unrelated topics. Whereas an Enterprise Template prescribes the project skeleton a user receives when creating a project with that template, source control determines how a project's files are versioned and maintained when concurrently accessed by numerous developers.
These two topics, however, are closely related when applied within practical scenarios. Because Enterprise Templates target team development scenarios, their adoption in the corporate setting is dependent upon how well they integrate with source control technologies
In this article, we'll examine the relationship between these two important technologies. As you will see, source control applies to Enterprise Templates in much the way it applies to any project that must be versioned. However, an upfront understanding of the various source control options will allow you to better design templates that must adhere to certain source control schemes.
Any source control setup must begin with the selection of a source control provider. In the Microsoft realm, the most popular provider is Microsoft Visual SourceSafe (VSS), and it is on this provider that our discussion is centered.
Note These models will work equally well with other source control providers.
The next step in the source control process is to choose a Collaborative Design Model, which prescribes the manner in which project files are versioned, maintained, and executed. In general, there are three Collaborative Design Models to choose from, and the choice depends upon factors ranging from hardware availability to developer expertise. These three models are:
- Isolated: Each developer works against a personal working copy of the source controlled master file, which allows for parallel development. Running and debugging of the project takes places on the developer's local machine.
- Semi-Isolated: Each developer works against a personal working copy of the source controlled master file, which allows for parallel development. Running and debugging of the project takes places on a remote, centralized server.
- Non-Isolated: Each developer works against the master copy of the file, which results in serialized development. Running and debugging of the project takes place on a remote server.
As will become evident, the model you should use depends upon your choice of numerous underlying technologies and other business factors. In this respect, the most important technology choice is the manner in which source code is shared and where applications are debugged.
Before you choose a Collaborative Design Model, you must make a few decisions about the technologies you will use to share code (in fact, these choices implicitly determine the Collaborative Design Model being used). Specifically, there are three variables that come into play—the location where Web applications are saved and executed, how are source control files accessed from a remote server, and the manner in which files are checked out. These three facets of source control are discussed below.
Local Web Host vs. Remote Web Host
Web-based applications (such as ASP.NET applications or traditional ASP applications) execute within the confines of a Web server, such as Internet Information Server (IIS). An important question for source control is where such applications are initially saved, as this initial location dictates where the application executes. With Visual Studio® .NET web-based applications (and Web services) can be saved either locally or on a remote server.
When saved locally, a Web-based project executes and is debugged on the local Web server. Thus, the developer requires a copy of IIS on the local machine. This is the default setting and is based on the localhost alias in the URL name: http://localhost/projectname.
Alternatively, a web-based project can be saved on a remote server such that execution and debugging takes place at a centralized location. Remote addresses have a working directory of http://remoteservername/projectname. This mode of access should be considered if local machines do not have IIS or if debugging needs to be performed on a production (remote) Web server. Be warned, however, that debugging remotely locks the server, which effectively locks out other users. In other words, a server used for such purposes should not be used for multiple projects or for production purposes.
The Web Access method specifies the manner in which Visual Studio .NET accesses files on a network. There are two such methods—File Share and Microsoft FrontPage® Server Extensions.
File Share is both the default and recommended method for remote file access. A Web application resides at a shared network location. Once the initial http address for the project has been determined, Visual Studio .NET resolves the address to a Universal Naming Convention (UNC). Using a combination of direct file and http access, the UNC-addressable network share is used to perform all operations on the project. When you open a project from source control, Visual Studio creates a "working copy" of the remote master copy in the specified working folder.
Developers perform all work against this working copy. Having one master copy and one or more working copies allows developers to work in isolation, modifying shared files on their own machines and safely merging changes to the master copy without overwriting the changes made by others. File Share Web access can be used with all Microsoft Source Code Control Interface (MSCCI) compliant providers including Visual SourceSafe.
FrontPage Server Extensions
A second way for Visual Studio .NET to access remote files is by means of FrontPage Server Extensions. Server Extensions act as an intermediary and forward source control requests from Visual Studio .NET to Visual SourceSafe.
Unlike the File Share technique, a working copy of the project is not maintained—modifications persist directly to the master copy. As a result, a project's files cannot be checked out by numerous developers. Instead, file access is serialized. One developer checks out and makes modifications to a file and all other developers are blocked until the file is checked back in.
Another restriction of FrontPage Server Extensions is that a project cannot be directly added to VSS from Visual Studio. Instead, the action must be performed within VSS itself.
Because of these disadvantages, FrontPage Server Extensions are not recommended for most situations.
A final question in the source control equation is whether or not to permit shared checkouts. Shared checkouts allow developers to work against personal copies of the source controlled master file. Team members are free to check out and modify files without having to worry about overwriting changes made by other team members. When a file is checked in remotely, Visual Source Safe displays conflicts between the working and master copies that must be resolved (by rejecting/accepting changes in the working or master file). Of the two Web Access methods listed above, only File Share supports multiple checkouts.
The combination of the three variables discussed earlier gives rise to a certain Collaborative Development model. These Collaborative models determine how the team members interact, where debugging takes place, and how source control communication is performed. The collaborative models include Isolated, Semi-Isolated, and Non-Isolated.
With the Isolated model, each team member edits, runs, and debugs projects on their own machine. Developers work against the working copy of the project that is stored in a local working directory. Developers interact through the source controlled master project and allow the source control provider to deal with all version conflicts, either automatically or through prompting.
- The Isolated model allows team members to easily create, access, and manage Web applications because such applications run locally.
- The Isolated model allows one or more team members to edit, run, and debug a project simultaneously through shared checkouts.
- The Isolated model supports advanced source control functionality, such as branching and merging.
- The Isolated model can be used with any MSSCCI compliant source control provider.
- Testing on a local server does not provide realistic performance or concurrency metrics as there is only one user of the application.
- Each team member must have IIS installed and running on their local machines
- All team members must be linked together through a LAN or VPN so that they have access to the source controlled master project.
The Semi-Isolated model is similar to the Isolated setup in that each developer has a working copy of the project. The difference is that the application executes and is debugged on a shared, centralized server. With the Semi-Isolated model, a team member creates a distributed project on a remote server and subsequently adds it to the source control provider. The rest of the team can then open the project from source control. Although each developer has a working copy of the project, it must be saved and executed on the remote server.
- The Semi-Isolated model requires less hardware and fewer software licenses as each developer machine does not require a copy of IIS.
- The Semi-Isolated model allows a network administrator to manage shared resources on the centralized server.
- The Semi-Isolated model supports advanced source control functionality, such as branching and merging.
- The Semi-Isolated model can be used with any MSSCCI compliant source control provider.
- Web references are not automatically shareable when using the Semi-Isolated model as the Web server is located on a centralized server and not the developers' machines.
- All team members must be linked together through a LAN or VPN so that they have access to the source controlled master project.
- When an application is debugged using the Semi-Isolated model the process locks the Web server, thus preventing other users from simultaneously working on projects on the same server. In other words, if one team member debugs an application all other members must wait until debugging is complete.
The Non-isolated model occurs when FrontPage Server Extensions are used. With the Non-Isolated approach, one team member creates a distributed project and manually adds it to Visual SourceSafe. The remaining members of the team manually extract the files from Visual SourceSafe and open Visual Studio .NET. Team members can still perform their work simultaneously, but only one developer can have a file checked out at any given time. If two developers need to work on a file at the same time, one must wait until the other is finished.
- Team members need not be connected through a LAN or VPN.
- Developers cannot work in parallel. That is, access to project files is serialized.
- Visual Studio .NET projects cannot be added to Visual SourceSafe directly through FrontPage Server Extensions from the IDE, but must be added manually within Visual SourceSafe itself.
- The Non-Isolated model does not support advanced functionality, such as branching and merging.
- Developers are restricted to using Visual SourceSafe as the source control provider as it is the only provider that supports FrontPage Server Extensions.
In general, Enterprise Templates are used in team-based scenarios. Accordingly, a source control strategy for such projects should be as unrestrictive as possible. Unless circumstances prevent it, either the Isolated or Semi-Isolated models would be appropriate choices because they allow developers to share files, merge changes, and work in parallel.
The decision of which model to use is made when the user of a template selects the working directory for the Web portion of template. If a localhost address is specified, the source control model is Isolated. If a remote address is specified, the Semi-Isolated model is used.
An important question is the manner in which Web portions of a template are handled by Visual SourceSafe. As detailed below, the procedure depends on the version of Visual Studio .NET being used. Before proceeding, however, it is worth noting that special care must be taken in managing Enterprise Template policy files on a central source control server.
When you add a Distributed Application created in Visual Studio .NET 2002 to VSS, the project is not added to an existing folder, but rather you are prompted to create a new folder. Moreover, any subprojects within the project cause another prompting. After VSS creates the project's folders, it asks you whether you want to save the Web project within the distributed application. If you accept the default folder location, the Web project is saved in a folder named WebUI that is not under the Project directory.
This behavior has a dangerous side effect. If a second Web-based application is added to Visual SourceSafe and the default locations are accepted, the Web project is also saved in the WebUI folder and overwrites any identically named files that already exist. To avoid this dangerous predicament, you must change the default location to a directory within the project directory.
The behavior under Visual Studio .NET 2003 is slightly different. Visual SourceSafe creates a folder named projectname.root in its root node. Within this folder, two subfolders are created—projectname and webprojectname. The projectname folder contains all regular code for the project, whereas the webprojectname folder contains all Web or distributed files. This is all done without the prompting required in Visual Studio .NET 2002. This smarter approach is illustrated in Figure 1.
Figure 1. Handling Web-based projects in Visual Studio .NET 2003
When designing Enterprise Templates it is important to keep in mind source control requirements. Of the three source control models, either the Isolated or Semi-Isolated models are appropriate for the team-based environment that templates espouse. The choice between these models is made by the developer during the creation of a template instance.