1.  Tips and Tricks for Using StarTeam More Effectively StarTeam 3002 Preconference Tutorial

2. 2 Welcome  We are here to learn and have fun (not yell at the speaker).  Cell phones on vibrate  Please interrupt with questions  Q&A will include demo

3. 3 Outline Using StarTeam Effectively Personal Options Speed, Performance Bandwidth Concerns Labels View Revision Check out revision Views What are they View Matrix Ten basic views Business Cases Using the Promotion States Project Branching Strategies Build the tips Branch All Label Stable Main branch

4. 4 Truisms of StarTeam “Truisms are bad in my opinion.” –Ferris Bueller  View Labels are attached to everything, Revision labels are attached to nothing.  Every folder has a working directory.  You never log into a project it is always a view.  Filters have three parts: What you want to see, how you want to see it, and based on what criteria  View Labels are attached to the tip revision of every item in a view.  Change the alternate working directory, never the default.  Be able to manage branching in your head.  Keep it simple StarTeam.  Flexibility is StarTeam’s best and worst attribute.  Views are WHAT you want to see, WHEN you want to see it.  Once something is added to StarTeam it is never deleted.

5. 5 Personal Options  There are over 100 options to configure in StarTeam.  Learn them, know them, live them

6. 6 Personal Options  MPX

7. 7 Personal Options  File Tab

8. 8 Personal Options  Object Tabs  Very similar, once you seen one, you’ve seen them all.

9. 9 Filters and Queries  Filters and Queries are two of the most under rated tools in StarTeam. They help us:  Manage Branching  Manage Views with many objects (20,000).  Identify anomalies in Views

10. 10 Filters  Use Case 1  Manage Branching

11. 11 Filters  Use Case 2  Manage Views with many objects

12. 12 Filters  Identify Anomalies

13. LABELS

14. 14 Labels  A “Label” is used to identify a configuration by attaching it to the specific revisions of items that comprise that configuration.  Without labels, one would have to retrieve the correct revision of each item individually.  Check out “Framework” 3.5.1  Check out “CPA” 4.5  Check out “SM” 4.5  With labels, one can retrieve the entire configuration with a single checkout operation.  Check out all item revisions that have label “Quest Central 5.0” attached.

15. 15 Classic View of Labels File A File B File C File D File E File F

16. 16 But in Reality  View Labels exist as a time stamp.  So it is more accurate to say that a view label will be attached to the revision of every object in a view that was current at the moment the label is created.

17. 17 Exception List  When we adjust labels we are creating an exception list. “This label is whatever was current at 5:30pm on 11/6, except…..A….B….C-7:30pm 11/6”

18. 18 Revision Labels v. View Labels  View labels are attached to everything, revision labels attached to nothing.  View Labels are boring.  GUI is confusing. Labels Labels Labels  Revision Labels are much more interesting.

19. 19 Revision Labels Two for one deal.  Remember Revision Labels start with nothing, so by highlighting files before we create the label, we get a…..

20. 20 Tricky Revision Labels  But now that we have a revision label, and file revisions attached to it, how do you get it out?  Three steps in the GUI, but if you understand it there it makes the command line and SDK, much easier to understand.  Select By Label  Select Check Out  Check out by Labeled Revision

21. 21 Revision Labels Select By Label Check Out. Then you adjust the configuration to the selected label. Otherwise you will get the current revision

22. Views

23. 23 What are we managing?  One Product, One Build Process?  Many Products, Common Build Structure?  Many Products, Common Components?  Many Products, Many Releases, Common Components? The truth is that we manage all these things. So, how can StarTeam help? And where it can hurt?

24. 24 What is a view? A view is a way of looking at a project in StarTeam. But WHAT objects do you want to see?  All  Docs Only  Common Components  Other

25. 25 What is a view? Now you have to decide WHEN you want to see these objects?  Floating  Labeled  Configuration (as of)

26. 26 What is a view? And of course…. How do you want this new view to interact with the parent view? HOW do you want branching to behave?  Read Only  Branch All  Branch None

27. 27 List A - List B Method Choose one from List A and one from List B List A (How) Floating Labeled Configuration (as of) Read Only List B (When) Branch All Branch None

28. 28 List A - List B Method There is only one view behavior that is an exception to this rule; Mirrored or Reference Views But they are the easiest to understand; Any changes to the “Child View” will be seen in the “Parent View”. Any changes in the Parent view will be seen in the Child view.

29. 29 If we create a Mirrored view, what behavior will we see? 1.01.11.21.31.41.5 1.01.11.21.31.4 Version 1.3 was checked in Friday at 5:30pm Version 1.2 has label “Build 105” attached to it 1.51.6 View A (Parent) View B (Child) Mirrored

30. 30 Introduction to TIME  The time element of Views can be one of three basic states: Floating, Labeled, Configuration (as of). 1.01.11.21.31.4 Version 1.3 was checked in Friday at 5:30pm Version 1.2 has label “Build 105” attached to it 1.51.6 1.01.21.31.6 Floating Config as of Labeled

31. 31 Read-Only If we create a Read Only view, what behavior will we see? 1.01.11.21.31.41.5 1.01.11.21.31.4 Version 1.3 was checked in Friday at 5:30pm Version 1.2 has label “Build 105” attached to it 1.51.6 View A (Parent) View B (Child) Mirrored Changes will not be allowed

32. 32 Branch All If we create a Branch All view, what behavior will we see? View A (Parent) View B (Child) Mirrored 1.01.11.21.31.41.5 1.01.11.21.31.4 Version 1.3 was checked in Friday at 5:30pm Version 1.2 has label “Build 105” attached to it 1.51.6 1.5.1 All Items will branch, but one at a time

33. 33 Branch None If we create a Branch None view, what behavior will we see? View A (Parent) 1.01.11.21.31.4 Version 1.3 was checked in Friday at 5:30pm Version 1.2 has label “Build 105” attached to it 1.51.6 1.01.11.21.3 View B (Child) Mirrored This branch will remain read only until the Branch On Change attribute is set Files, folders or the whole View can be set to Branch on Change at once.

34. 34 Create a View Select View – New Remember List A?

35. 35 View Wizard Then Select the root of the new view. WHAT Then choose a working directory. Changing the working directory for every view is a best practice.

36. 36 Select the new view’s configuration (When)? Remember List B? View Wizard And Finish

37. 37 Reference Tab Current View

38. 38 Nuances of Views  Views are simple to setup, use and manage. What is hard is the individual branching within folders and objects.  Folders can branch, Files can Branch, but so can Change Requests, Requirements and Topics. View 1 View 2 Branch All Floating View 3 Branch None Label Folder A Folder B File X Shared between folders Folder A Folder B File X Folder A Folder B File X

39. 39 Nuances of Views  Now Predict the behavior of File X in Folder B, of View 3 when a developer checks into Folder A in View 1.  We should focus our efforts controlling branching on a folder level rather than on the view level.

40. 40 Branching - Item versus Project  The discussion of views forces us to generalize about the behavior between two views, however in reality this is an item by item branching behavior. Hence the confusing terminology “Branch All” means that all the individual items have been set to Branch On Change.

41. 41 Branching - Item versus Project  In any given view it is possible and likely to have many different branching behaviors.

42. Project Branching Strategies

43. 43  I can use Labels  I understand Views  I think I understand the business cases for views Now What? What branching strategy will work for me?

44. 44 Branching Strategies Build the Tip Advantages  Simple  Easy to manage  No need to branch at all Disadvantages  Must Integrate changes immediately  High Risk Daily Builds  Support of multiple releases more difficult Build 100 Released to GA

45. 45 Branching Strategies Branch All Label GA Candidate BAL View P1 Fix Releases and maintenance from branched view Current Development

46. 46 Branch All Label Branching Strategies Advantages  One view type to manage  Branched views deleted over time  All current / future development done in main/root view Disadvantages  Manual merging of changes  Releases managed from branches

47. 47 Branching Strategies Ready for Build Build 100 Revision Labels New Build Label copied from last build then adjusted for “Ready” Revision Labels

48. 48 Branching Strategies Ready for Build Advantages  More Flexibility  Allows rolling out of changes  Encapsulates changes  Allows post development CCB. Disadvantages  Most complex of build practices  More changes per build, complicates

49. 49 BAF View Branching Strategies Stability Centric (Quality Controlled) BAF View Future Development When development is done. Label is applied. Approved by QA/QC. Merge into main view controlled by QA/QC After Merge, new “Approved” Label Created for branching

50. 50 Advantages  Very Stable root view  Highly controlled process  Guaranteed integration  Simple merge process  Incentive for rapid development Disadvantages  Can have many branching behaviors  Complicated view structure  Many views  Many merges Branching Strategies Stability Centric (Quality Controlled)

51. 51 What Not to Do…… The names have been changed to protect the not so innocent.

52. 52 Questions?