StarTeam 3002 Preconference Tutorial

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

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. 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. 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. Personal Options • There are over 100 options to configure in StarTeam. • Learn them, know them, live them

6. Personal Options • MPX

7. Personal Options • File Tab

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

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. Filters • Use Case 1 • Manage Branching

11. Filters • Use Case 2 • Manage Views with many objects

12. Filters • Identify Anomalies

13. LABELS

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. File A File B File C File D File E File F Classic View of Labels

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. 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. 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. 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. 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. 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. 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. 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. What is a view? Now you have to decide WHEN you want to see these objects? • Floating • Labeled • Configuration (as of)

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. List A - List B Method List A (How) List B (When) Read Only Floating Branch All Labeled Branch None Configuration (as of) Choose one from List A and one from List B

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. Mirrored Version 1.2 has label “Build 105” attached to it Version 1.3 was checked in Friday at 5:30pm 1.0 1.1 1.2 1.3 1.4 1.5 1.6 1.0 1.1 1.2 1.3 1.4 1.5 1.6 If we create a Mirrored view, what behavior will we see? View A (Parent) View B (Child) Mirrored

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

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

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

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

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

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. View Wizard Select the new view’s configuration (When)? Remember List B? And Finish

37. Reference Tab Current View

38. Folder A File X Folder A Folder A File X File X Folder B File X Folder B Folder B File X File X 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 3 Branch None Label View 1 View 2 Branch All Floating Shared between folders

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. 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. Branching - Item versus Project • In any given view it is possible and likely to have many different branching behaviors.

42. Project Branching Strategies

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

44. Build 100 Released to GA 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

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

46. Branching Strategies Branch All Label 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. New Build Label copied from last build then adjusted for “Ready” Revision Labels Build 100 Revision Labels Branching Strategies Ready for Build

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

50. Branching Strategies Stability Centric (Quality Controlled) 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