1 / 36

Overview

Team Development Using Visual Studio 6.0 Martyn Lovell Development Lead Visual Studio Enterprise Microsoft Corporation 6-309. Overview. Team Development Tools Source Control Setting up Unifying tools Parallel Development VSS integration best practices Component Management Setting up

havily
Download Presentation

Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Team Development Using Visual Studio 6.0Martyn LovellDevelopment LeadVisual Studio EnterpriseMicrosoft Corporation6-309

  2. Overview • Team Development Tools • Source Control • Setting up • Unifying tools • Parallel Development • VSS integration best practices • Component Management • Setting up • Best practices • Summary • Q&A

  3. Focus Areas • Covered • Visual Studio 6.0 • Visual C++, Visual Basic, Visual J++, Visual InterDev • Source Control Systems • Visual SourceSafe, Others • Visual Component Manager • Not Deeply Covered • Visual FoxPro • Microsoft Access • Other uses of the Microsoft Repository

  4. Team Development Tools • Source control • Manage Source code • Manage Documentation • Share Reusable source • Component management • Manage Built binaries • Manage External binaries (MFCxx.DLL) • Share Binary components (OCX) • Each allows other’s content • But is optimized as described above.

  5. Source Control • All of Visual Studio is integrated with Source Control • Each piece of the product does it slightly differently • Working with each individually is well-documented • When your work crosses tools things become more complex • This is the focus of this part of the talk

  6. Types of Integration • Client Side • Has user interface • e.g. Diff/Merge • Uses Microsoft Source Code Control Interface (MSSCCI) • Server/Automation • No user-interface • Runs unattended

  7. Client Integration • MSSCCI-based • De Facto standard • Supported by all major vendors • PVCS, ClearCase, Team Connection, … • Used by other editors and tools • MS Products • Visual Basic, Visual C++, Visual J++, Visual FoxPro, Access

  8. Server Integration • Server-side integration uses a VSS-specific interface • SourceSafe supports it • PVCS has some support too • Used to keep a server backed by source control • Not widely used on the client • MS Products • FrontPage, Office Web Server, Visual InterDev

  9. Setting up: Team • One person should administer • They will be responsible for • User management • Sharing • Branching • Pinning • Analyze • Creating Databases

  10. Setting up:Visual SourceSafe • Use VSS explorer to open databases • Use browse to find your database on the network • Create shareable connections • Shareable connections look like • \\martyn\vss\srcsafe.ini • Non-shareable connections look like • C:\foo\srcsafe.ini • Avoid using NetSetup • It makes a non-shareable connection

  11. Setting up: FrontPage • Set up FrontPage server to point at VSS • Can point at VSS database on any machine • Tough process • Get the KB articles • See Q157883, which points at other KB articles • Works seamlessly when set up

  12. Creating A New Project • Create it on your local machine • Ensure it builds there • Keep everything under a unified root • All projects and files should be under some well known point • Otherwise, VSS will force you to copy them • Put metafiles above their references • Workspaces above projects (VC) • Project groups above projects (VB) • Solutions above projects (VJ/VID) • Vital for VB and VC; highly desirable for others

  13. Importing Libraries • Don’t try to share local copies of library files • Your development efforts will interfere with each other • Source space is a small fraction of build space • Use ‘Share and branch’ to make references to common libraries • Caveats later

  14. Adding To Source Control • Server layout should match disk layout • Don’t add output or temporary files • OPT/SUO • NCB • PDB • APS • Do add binary files • BMP/ICO • Consider adding input binaries (OCX, DLL)

  15. Working With Source Control • Use integration where ever possible • Resort to VSS Explorer only when necessary • Use Refresh status command after using VSS Explorer • Check out all files before working on them

  16. Unifying Tools • Three ways to unify tools • Command Line • Build Tree • Single SCC Environment • Each has strengths and weaknesses • No perfect solution yet

  17. Command Line • Ensure unified root across all languages • Avoid adding directories too often • Write command line scripts to get latest versions • Pro • Simple • Extensible • Con • Completely manual

  18. Build Tree • Ensure unified root across all languages • Avoid adding directories too often • Use VSS GUI to get new versions • Recursive • Build Tree • Pro • Simple • Con • Completely manual

  19. Single SCC Environment • Choose a host environment • Probably best to choose your most important one • Create fake projects to wrap all projects from other environments • Fake projects must be kept in sync with real projects • All SCC operations done from the host environment • Other environments see themselves as controlled

  20. Host: MDE (VJ/VID/VSA) • Microsoft Development Environment • Best SCC UI and integration • Use utility projects to model external projects • Can set up build too • No debugging except of VJ • Only way to integrate with VID as well • Good support for Share and Branch • Does not have VC’s issues in this area. • Best general-case solution from a source control perspective

  21. Host: VC++ • Good SCC UI and integration • Use makefile projects to model external projects • Can set up build too • Debug VB, VC • No way to integrate with VID • Manual support for Share and Branch • Good for primary-VC users

  22. Host: VB • Basic SCC UI and Integration • Use a VB Project to model external project • Not ideal • Can’t easily set up build • Debug only VB • No way to integrate with VID • Good support for Share and Branch • Good for mostly VB users who do a little VC

  23. Demo • Assorted hosts

  24. Parallel Development • VSS uses Share command to work in parallel • Branch command splits the share • Always branch metafiles • DSW, DSP, VBG, VBP, SLN, VJP • Some manual fix up required in VC • See knowledgebase Q173065 • VJ has command to aid fix up • Change Connection

  25. Parallel Development (2) • Simplest solution • Share and branch everything • Administrator should complete branch before people start work • Be sure to reopen everything before you let others loose • Branching webs is hard • Avoid it • Use Copy Web

  26. Parallel Development (3) • Merge branches when no one is working • Tree can become un-buildable • Do a get latest version • Build, Test • Fix any problems • Avoid re-share unless required

  27. VSS Best Practices • Run Analyze weekly • Take regular backups • It’s a database! • Use the 6.0 format database • Performance • Get Visual Studio 6 SP4 • Includes several useful VSS fixes • Deploy to clients, not just server • Avoid unreliable networks • Use RAS only for read operations

  28. Integration Best Practices • Have a shareable connection • Have a unified root • Share sparingly • Always use integration • Check out early

  29. Component Management • Use Visual Component Manager to • Share built components • Reuse across organization boundaries • Provide centralised repository • Assign custom properties • Archive binary dependencies • VBRUN, MFC, etc • Not good for • Source code sharing

  30. Setting Up • Experiment with MS Access • Create a taxonomy • Investment here will pay off • Initial taxonomy may help • Decide on keywords • People will not bother unless the keywords are apposite • Then setup SQL server • Key for performance • Have users deploy • Many may not have installed

  31. Demo • Publish and Reuse

  32. Best Practices • Archive all used binaries, OS-es, etc • Archive all inter-team releases • Create a simple website using FrontPage • Allows users to describe their component in more detail • VCM will run within IE too • Keep the publish burden low • Users are loathe to add metadata

  33. Summary • SCC integration is powerful and flexible • Managing across many products is easier than it seems • Simple best practices can avoid most problems

  34. Q & A • Http://msdn.microsoft.com • MartynL@microsoft.com

More Related