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

Atomic Commits

Barun Singh
December 11, 2012

Atomic Commits

Keep your codebase healthy without acting like the thought police.

Presenting a process for collaborative software development that yields high quality code, preserves developer flexibility, and fosters communication and learning.

Barun Singh

December 11, 2012
Tweet

More Decks by Barun Singh

Other Decks in Programming

Transcript

  1. Atomic Commits
    Keep your codebase healthy
    without acting like the thought police
    Barun Singh
    Founder/CTO
    Boston Ruby Group, 11 Dec 2012

    View Slide

  2. A Social Anarchist View
    of Software Development

    View Slide

  3. Our objectives
    Reliable application
    Maintainable code
    Scalable process
    Knowledgeable team

    View Slide

  4. Let’s take this one step at a time
    Testing
    Code reviews
    Communication

    View Slide

  5. Your team’s process ought to:
    protect the codebase

    View Slide

  6. TDD
    “Write tests first.
    Watch them fail.
    then write code”

    View Slide

  7. Guiding principle:
    Your process ought not
    tell you how you must think

    View Slide

  8. 4PNFUJNFT
    ZPVKVTUXBOUUP
    HPFYQMPSJOH

    View Slide

  9. Laws ought to
    protect the commons, but
    preserve individual liberty

    View Slide

  10. Laws ought to
    protect the commons, but
    preserve individual liberty
    codebase
    developer flexibility
    Your team’s process

    View Slide

  11. Your team’s process ought to:
    protect the codebase
    preserve developer flexibility

    View Slide

  12. Your team’s process ought to:
    protect the codebase
    preserve developer flexibility
    encourage clear communication

    View Slide

  13. Convey intention across space and time.

    View Slide

  14. Your team’s process ought to:
    protect the codebase
    preserve developer flexibility
    encourage clear communication
    foster learning

    View Slide

  15. “If I had to do this again,
    maybe I could find an easier path.”

    View Slide

  16. Your team’s process ought to:
    protect the codebase
    preserve developer flexibility
    encourage clear communication
    foster learning

    View Slide

  17. Git Branching Strategy
    master is always deployed
    All changes are mage on branches that are merged
    master
    in-progress
    feature

    View Slide

  18. master is the commons Feature branches are
    where you get your work done

    View Slide

  19. Do whatever you want on your branch,
    but follow group norms for master
    And what if I don’t?
    Nothing, we just won’t accept your pull request.

    View Slide

  20. Rules of the commons
    1. Every commit must make sense on its own
    2. Every commit must do something meaningful
    3. No commit may break the build
    4. Every commit must include thorough tests for all code changes
    Every commit must be atomic

    View Slide

  21. Why?
    1. Every commit must make sense on its own
    Communication and clarity
    2. Every commit must do something meaningful
    Less noise == less frustration
    3. No commit may break the build
    Reliability (part I)
    4. Every commit must include unit & acceptance specs for all code changes
    Reliability (part II)

    View Slide

  22. The final process
    Formulate an
    approach
    Write your
    code & tests
    Organize your
    branch
    Present code
    for review
    Iterate based
    on feedback
    QA & merge
    into master

    View Slide

  23. Thank you.
    [email protected]

    View Slide