Partilhar via

Establishing an Environment for Multiple Developers

  • Artigo

Several of the requirements for creating a multiple developer environment for the Commerce Server 2009 are common to any multiple developer software project. These requirements include the following:

  • You should select and use a source control system, such as Microsoft Team Foundation Server (TFS) or Microsoft Visual Source Safe. These systems use check out and check in procedures to prevent developers from accidentally overwriting each other's work. A source control system also enables developers to synchronize their snapshot of the source code with the code of their peers.

  • You should designate one of your computers as an integration or build computer (referred to as the build computer in the rest of this topic) on which the work of multiple developers is frequently brought together and tested. This process helps determine incompatible development sooner instead of later.

  • The developers on your team should have their own development computers that provide isolated environments in which they can develop their own code according to their own programming style. When a developer has a new feature or modification that works sufficiently well, the developer checks it into the source control system. Other developers are then free to synchronize with it and continue their own development.

The remaining requirements for creating a multiple developer environment for Commerce Server 2009  are specific to Commerce Server 2009. These requirements include the following:

  • Each development computer and the build computer should run Windows Server 2003 or Windows Server 2008. Each development and/or build computer should also have the Commerce Server 2009, SQL Server 2005 or 2008, and Visual Studio 2008 installed.

  • To test your secure URLs, for Internet Explorer 6 you should download the Internet Information Services (IIS) Resource Kit and use SelfSSL, for Internet Explorer 7 you should create a self-signed certificate using Internet Information Server (IIS) Manager.

  • Perhaps the biggest decision that you must make for your multiple developer Commerce Server 2009 project is whether your developers will work with local copies of the various Commerce Server 2009 databases, or whether they will work in an environment in which they share single instances of those databases.

Local Databases versus Shared Databases

At the start of your project, you must decide whether developers will have local copies of the Commerce Server 2009 databases on their individual development computers, or if they will work with shared instances of these databases. The following table lists the pros and cons to each approach. 

Local databases

Shared databases

Each development computer and the build computer have their own copy of the Commerce Server 2009 databases that includes the Administration database (MSCS_Admin).

Dd464550.alert_note(en-US,CS.90).gifNote:
It is still possible to share the Profiles database because it is a global resource.

Pros:

  • Enables free progression of individual development work, especially development work that requires schema changes.

Cons:

  • Requires more SQL Server licenses.

  • Requires extra communication to work smoothly. This makes it more prone to errors. When a developer checks in changes that include schema changes to one or more databases, the developer must export the schema changes and include the resulting file(s) in the check-in. Additionally, any other developers who are synchronizing their changes must also retrieve the file(s) that contain the exported schema changes and update their own local database(s) with those changes.

  • Lacks built-in protection against two developers making their own schema changes to the same database at the same time. Unlike source code files, database schemas do not typically have an explicit representation in the source control system. You should establish conventions to help prevent this kind of conflict. One potential solution is to create placeholder schema export files in the source control system at the start of the project. You can then require that these files be checked out by a developer before schema modifications are made to a local copy of the corresponding database.

All the development computers (and possibly the build computer) share a single copy the Commerce Server 2009 databases that includes the Administration database (MSCS_Admin).

Pros:

  • Requires fewer SQL Server licenses.

  • Saves time for individual developers by centrally providing and managing test data.

Cons:

  • Might block developers. The time that is required to make schema changes is typically short enough to manage. However, the time that is required to write and debug the code that uses the changed schema is generally much more significant. This could block developers if the schema changes stop critical functionality until the corresponding code can be debugged, checked in, and then synchronized.

  • Testing requirements might conflict. Developers might have incompatible needs with regard to test data. For example, one developer might stress the capacity limits of the database, and create unnecessary overhead for other developers.

  • Makes off-line development difficult or impossible.

  • Slows remote development. Geographically distributed development might become intolerably slow because of connection speeds between the development computers and the computer on which the databases reside.

The following figure illustrates the environment for multiple developers when you use local databases.

Workflow for local databases.

The following figure illustrates the environment for multiple developers when you use shared databases.

Workflow for shared databases

Additional Tips and Best Practices

The following are several tips and best practices to help create a successful multiple developer environment for Commerce Server 2009 development:

  • If you select the shared database approach, you should not use the Add Web Server option in the Commerce Server Manager or the Site Packager. If you use this option, you will create a Web farm and developers will be unable to predict which Web server will service a given request. This makes debugging very difficult. Instead, use Commerce Server Manager to set the Nonsecure host name and the Secure host name for the application your developers are jointly developing to "localhost". This will enable the developers to run and debug the code on their own development computers and share the data in the various Commerce Server 2009 databases.

  • On one of your computers, create a basic version of your Commerce Server 2009 site that includes its resources and corresponding Visual Studio project (if you select the shared database approach, follow these steps on the computer upon which the shared databases will reside, regardless of whether the computer is one of the development computers or the build computer). Use Authorization Manager to modify the authorization policies for the Commerce Server 2009 Web services, as appropriate for your environment. When these initial steps are complete, check your site code and Visual Studio project files into the source control system. Also, use the Site Packager to create a site package for your basic site and its resources.

    After you copy the site package to the remaining computers, use Site Packager to unpack your basic site as appropriate for the local versus shared database approach that you have chosen. Be careful when you specify the database connection strings on the Site Packager wizard screens, as this determines the approach you are taking.

    Development can then start by using standard source controlled processes. The process should start by synchronizing the development computers together with the source control system to make sure that all the development computers are starting from the same point.

    Dd464550.alert_caution(en-US,CS.90).gifImportant Note:

    To avoid problems with paths, relative references, and so on, make sure that you unpack the site by using the same directory and Web site that you used when you first created the site.

  • Avoid developing on your build computer. You want the build computer to remain a pristine reflection of the source files that have been checked into the source control system. You might want to designate a member of your team to be in charge of builds. This person should protect the state of the build computer so that it remains in a well-known state.

  • The more frequently you build and test on the build computer, the closer you will stay to having a working Commerce Server 2009 Web site.

  • To avoid issues during deployment, run the various services and application pools under the same accounts, and with the same permissions, as will be used in your production environment. If this creates too much of a burden in your situation, you can perform this secure deployment testing on the build computer. However, it might cost you more to resolve secure deployment issues in the build environment than you would save by having the developers resolve the issues in their isolated environments.

  • If you have chosen the local databases approach, make sure that the developers understand the processes for sharing changes with each other. Schema changes must be exported and checked in with the code that depends on those changes. In addition, other developers must retrieve and apply the schema changes to their database(s) together with synchronizing the dependent code.

See Also

Other Resources

Developing with the Multi-Channel Commerce Foundation

Developing with Commerce Server Core Systems