Make It Cooler: Using Decentralized Version Control

6,958 views

Published on

A commonly used version control system in the ColdFusion community is Subversion -- a centralized system that relies on being connected to a central server. The next generation version control systems are “decentralized”, in that version control tasks do not rely on a central server.

Decentralized version control systems are more efficient and offer a more practical way of software development.

In this session, Indy takes you through the considerations in moving from Subversion to Git, a decentralized version control system. You also get to understand the pros and cons of each and hear of the practical experience of migrating projects to decentralized version control.

Version control is often used in conjunction with a testing framework and continuous integration. To complete the picture, Indy walks you through how to integrate Git with a testing framework, MXUnit, and a continuous integration server, Hudson.

Published in: Technology
1 Comment
5 Likes
Statistics
Notes
No Downloads
Views
Total views
6,958
On SlideShare
0
From Embeds
0
Number of Embeds
4,507
Actions
Shares
0
Downloads
99
Comments
1
Likes
5
Embeds 0
No embeds

No notes for slide
  • Make It Cooler: Using Decentralized Version Control

    1. 1. Make it Cooler With Decentralized Version Control Indy Nagpal Straker Software
    2. 2. A bit about me • CTO, Straker Software, New Zealand • Lots of CF and Flex experience • In love with Groovy • Tackling challenges of creating cloud-based software • nagpals.com/blog
    3. 3. Once upon a time, in a galaxy not too far away... There was CVS
    4. 4. And it was a little... well... painful
    5. 5. Subversion made it a little easier
    6. 6. Both are centralized version control systems
    7. 7. Central Server Network in between Clients
    8. 8. http://tinyurl.com/dcvs-explained
    9. 9. A little history • Emerged in 1970s – Yes, that’s about 40 years back • That was the time of – weak clients – grunty mainframes • Centralized teams
    10. 10. Centralized Version Control • Simpler • Works nicely for – backup – undo – synchronization • “Everyone in my team knows how to use it”
    11. 11. So what’s the problem? • Reliance on being connected • Single point of failure • Branching and merging -- a big pain • Growing projects • Diffused teams
    12. 12. Enter...
    13. 13. Decentralized Version Control Systems
    14. 14. Not too long a ago on a planet called Earth Lived a nerd called Linus Torvalds And then there was Linux and Git
    15. 15. Other DVCS Systems Mercurial Bazaar
    16. 16. Main repository Multiple clients clone the repository, including all history Commit changes locally Push to main repository
    17. 17. http://tinyurl.com/dcvs-explained
    18. 18. Decentralized Version Control • Relatively recent innovation • Focus on sharing changes • Recording changes and Applying changes are separated • Fast • Efficient
    19. 19. Decentralized Version Control • Works offline • Branching is cheap • Merging a pleasure • Support for non-linear development • Distributed development
    20. 20. Considerations in switching from Centralized to Decentralized
    21. 21. IDE Support • git-gui, egit (Eclipse), gitx (Mac) • Command-line works very well • Configurable to work with other diff-ing/ merging and editing utilities • Nothing as simple as TortoiseSVN
    22. 22. Repository Hosting Infrastructure • Third party hosting works well – Unfuddle, Assembla – repo.or.cz, github • Host own server • *nix friendly, but have Windows ports
    23. 23. Learning Curve • There is one! And it is a little steep • Getting everyone to change development practice is a biggie • Need a champion who doubles up as trainer • If business finds reason, development teams have limited choice
    24. 24. Existing Repos • Size of repositories • Most DVCS can import SVN repos, including history • Process of migration needs to be planned and implemented
    25. 25. Integration with Third-party Tools • Code repos are tied to other systems: – Bug Tracking – Continuous Integration Systems – Code Review Systems • Switching requires updates to those processes • Do-able
    26. 26. Eternal Truth #1 The longer you use a system, the harder it is to switch
    27. 27. Eternal Truth #2 Inertia does not help
    28. 28. Eternal Truth #3 Lack of a business case does not help either
    29. 29. Eternal Truth #4 Change is the only constant
    30. 30. So where does that leave us?
    31. 31. Choose Git • Seems to have more legs than others • A little more difficult to grasp and work with • But once you’ve got your head around it, and worked with it for a while, it is easy
    32. 32. git-svn • Very useful feature • Checkout a SVN repo as a Git repo • Work with locally as a Git repo • Branch/merge locally as much as you like • Commit locally, and then push to SVN repo
    33. 33. A few other useful things • Only one .git folder, not a zillion .svn folders • Create local repos for things you normally wouldn’t • Efficiency – 1.5 GB svn repo = 700 MB git repo • Speed – Of local commits and pull/push from main repo
    34. 34. Resources • Git – git-scm.com • Peepcode – peepcode.com/products/git • Pragmatic Programmers – pragprog.com/titles/tsgit/
    35. 35. One Last Truth Automation is the key
    36. 36. On Automation and Developers Given a choice between spending an hour doing a task manually, or spending three hours writing a program to do it automatically... a geek will write the program, every single time. And, if not given the choice, if explicitly ordered to do the job manually, we'll disobey and write the program anyway. Catherine Devlin (http://tinyurl.com/devautomation)
    37. 37. Hook DVCS up with Testing and CI
    38. 38. Unit Testing • MXUnit works well • mxunit.org/ • Writing testable code -- key to automation • Retro-fitting tests does not work • Have to write tests before writing code • Makes the code more robust
    39. 39. What is testable code • Marc Esher’s presentation on Testable Code: – Extracted – Abstracted – Injected
    40. 40. Git with Unit Testing • Agnostic • Key issues are: – Where do you store tests – How do you run them
    41. 41. Continuous Integration • Hudson works extremely well • https://hudson.dev.java.net/
    42. 42. Setting up CI Workflow • Set up project • Ping Git repo / Implement callback • Checkout if new changes • Call MXUnit Unit Ant Task to run tests • Publish report • Notify
    43. 43. Thank you! indy@strakersoftware.com strakersoftware.com nagpals.com/blog

    ×