Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Corporate Adoption of Distributed Version Control

Corporate Adoption of Distributed Version Control

Slides from my talk at GLSEC 2013.

Jace Browning

April 29, 2013
Tweet

More Decks by Jace Browning

Other Decks in Programming

Transcript

  1. Why are we on this topic? If your company is

    not in the process of exploring distributed version control, they should start.
  2. Major Advantages #1 Collaboration #2 Branching #3 Efficiency #4 Productivity

    #5 Scalability #6 Affordability Change what you mean to change but keep separate changes separate to work as fast as possible without barriers for any of your teammates without killing your budget.
  3. So, what is version control? Storage of all changes Their

    ownership And explanation What? Who? Why?
  4. What version control isn’t. Backup Access Control Workflow Management Metrics

    Collection Etc. You typically get these things, but that’s not the point.
  5. A Brief History Three Generations: Local Networked (Centralized) Decentralized (Distributed)

    No longer used. (I hope) Status quo for corporations. Adopted for open source, web, and mobile development.
  6. Centralized Examples Concurrent Versions Systems (CVS) Apache Subversion (SVN) IBM

    Rational ClearCase Perforce Microsoft Visual SourceSafe (VSS) Serena Dimensions 2000 1990
  7. Distributed Advantages #1 Collaboration #2 Branching #3 Efficiency #4 Productivity

    #5 Scalability #6 Affordability Change what you mean to change but keep separate changes separate to work as fast as possible without barriers for any of your teammates without killing your budget.
  8. But, Multiple Developers 1. Get code 2. Make changes 3.

    Share them 1. Get code 2. Make changes 3. Share them Problem?
  9. CVCS Example 1 1 1 2 2 1 1 1

    2 2 Developer A Developer B
  10. CVCS Example 1 1 1 2 2 3 2 Developer

    A’s Change Developer A+B’s Change
  11. DVCS Example 1 1 1 2 2 1 1 1

    2 2 Developer A Developer B
  12. Minimizing Overhead Most actions require access to the repository: Getting

    code Adding files Removing files Renaming files Saving changes Tagging baselines Comparing tags Creating branches Merging branches Etc.
  13. DVCS Example Intranet or Internet Update Add+Remove / Tag Compare

    / Merge Commit Repository Repository Code Sync
  14. CVCS Example Causes of Downtime: Server upgrades or crashes Network

    connectivity loss Customer/supplier site network access Travel, home, etc.
  15. DVCS Example During Downtime: Nearly all operations are available Effective

    merging means swift recovery Code is also implicitly backed up on every computer
  16. CVCS Example Options: 1. Get a bigger server (scale up)

    Impact: Downtime Non-linear cost growth $ $$ $$$
  17. Options: 1. Get a bigger server (scale up) 2. Scale

    out DVCS Example $ $ $ $ $ $ $ $ $ $ $ $
  18. CVCS Example 100 Developers and 50 Projects Fixed License Cost:

    $4125, $2930, $3520, $1880 $2000 × 100 Developers = $200k
  19. Distributed > Centralized Atomic storage of logical changes Local history

    is branch and merge friendly Efficient synchronization between repositories Limited hardware and network dependencies Flexible network architecture and scalability Cost-effective hosting options
  20. So, what’s next? Free Downloads: Git, Mercurial, Veracity, etc. Gradual

    Exploration: Tools + Scripts 㱺 Tests 㱺 New Projects Cloud Hosting and Communities: GitHub, SourceForge, Bitbucket, onVeracity, etc.