Source Control Best Practices II

· Use unique strong name keys when appropriate. If the business solution being developed is composed of two or more distinct parts, then consider whether multiple key files should be used. Multiple keys in this scenario allow the parts to be treated as independent entities in the future, for example with differing upgrade paths.

· Keep test messages in their own folder under the project. Choose a folder name to hold messages ("Msgs" or "SampleMessages") and use it consistently across all BizTalk projects. You should keep generated and example messages distinct by naming convention or by placing them in a separate folder. Track version numbers in the file name and through your version control system.

· Check in code only when it has passed functional tests. The developer should be confident that the code will build successfully without breaking any related code. Schemas should be checked in only when they have been tested against a wide variety of messages, BizTalk projects containing business processes should be checked in only after testing with expected (and unexpected) messages with all ports configured, and Web service projects should be checked in only after testing using a test harness or by the initiating system.

· Use the version control system to track non-BizTalk projects related to your solution. Use the version control system to track custom tools, deployment utilities, scripts, documentation, and other artifacts relevant to your BizTalk project. For example, if your project uses a Visual Basic® .NET Windows® application to manage accounts in a related system, you should consider tracking the executable and configuration files.

· Choose a versioning number approach and stick with it. There are two approaches to setting version numbers for BizTalk solution assemblies: choose a fixed assembly version and increment only the file version, or increment both assembly and file version for a build. The approach you choose will impact how you maintain and deploy your project.

Source: Microsoft

Source Control Best Practices

· Use a consistent folder structure for solutions and projects. Team development is made easier when a consistent folder structure is used on all member computers. This practice can also reduce the amount of time it takes to identify build issues across computers and decrease project ramp-up time for new team members.

· Keep source control and file system structures identical. This keeps team member directories synchronized with the source system and with other developers and helps to ensure they are following team project organization guidelines.

· Define and use a common root folder. Organize projects under a common root folder in the source control system. Developers should create the same root directory on their own computers.

· Create a master solution that will hold all projects. The master solution can be used as the main build solution and is a recommended practice for medium to large BizTalk projects. All related BizTalk projects should be stored under the master solution.

· Divide the project folder structure according to business process. Shared processes should be sequestered to their own folder. This will make it easy for developers to navigate to the different business processes in the solution and make enhancements without modifying unrelated processes.

· Group related pipelines into separate projects. During development of pipeline components, it is a common requirement to modify and retest a pipeline independent of the rest of the solution. For this reason it is often helpful to keep pipeline solutions as a separate BizTalk project, resulting in a separate pipeline assembly that can be removed and redeployed without the need to rebind the rest of the solution.

Source: Microsoft