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.

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.
    bsingh@wegowise.com
    

    View Slide