Lesson Learned: Transforming from ClearCase to Git
- 1. Lessons Learned: Transforming from ClearCase to Git Tamir Gefen @almtoolboxalmtoolbox.com
- 2. Why Switching Tools?The Situation
- 3. The Situation 1. 100 developers (end-users); 5 groups 2. Working with Base ClearCase ; hundreds of branches 3. Users want to work from home in a convenient way 4. Users want to move to modern processes
- 5. Why Switch Tools? 1. Costs: licensing and maintenance 2. Ease of use for end-users 3. Consolidate the organization into one tool
- 7. The Challenges 1. Different tools? 2. Train 100 developers in how to use a new system 3. New development concept. Set a new flow? 4. Integrated with IDEs? 5. How to move history? Should we take the whole history? 6. Train administrators in how to operate git 7. Limited (and short) timeframe
- 9. Different Tools? Not so different… Similarities: Project structure Branching Users and permissions Differences: Working copies Work items Are Git and ClearCase different tools?
- 10. The Transition
- 11. The Transition (Planning) 1. Migration strategy 2. New flow 3. Training 4. Limited timeframe
- 14. Results 1. Licensing costs: 0 2. New flow 3. Shorter learning curve (than before) 4. New options for integrating with modern tools, including issue- tracking; CI and more
- 15. Lessons Learned
- 16. Lessons Learned 1. You can move active baselines / labels only 2. Move each SW group separately 3. Allocate 1-2 days to accommodate developers (after migration) 4. The transition is an opportunity to improve SW processes 5. Transition should be planned by a person who knows BOTH ClearCase and Git 6. Define SUCCESS criteria (acceptance tests)
- 17. Tips
- 18. Tips 1. Build a table translating ClearCase-ish to Git-ish (e.g.: check-in -> commit, label -> tag( 2. Print the new flow (as a diagram) and share it with the end-users 3. Use strong and reliable infrastructures 4. Beware of ClearCase “evil twins” and hard links!