Atomic Commits

A70410682bd132d5edf76b42189ebb45?s=47 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.

A70410682bd132d5edf76b42189ebb45?s=128

Barun Singh

December 11, 2012
Tweet

Transcript

  1. Atomic Commits Keep your codebase healthy without acting like the

    thought police Barun Singh Founder/CTO Boston Ruby Group, 11 Dec 2012
  2. A Social Anarchist View of Software Development

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

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

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

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

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

    must think
  8. 4PNFUJNFT ZPVKVTUXBOUUP HPFYQMPSJOH

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

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

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

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

    flexibility encourage clear communication
  13. Convey intention across space and time.

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

    flexibility encourage clear communication foster learning
  15. “If I had to do this again, maybe I could

    find an easier path.”
  16. Your team’s process ought to: protect the codebase preserve developer

    flexibility encourage clear communication foster learning
  17. Git Branching Strategy master is always deployed All changes are

    mage on branches that are merged master in-progress feature
  18. master is the commons Feature branches are where you get

    your work done
  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.
  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
  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)
  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
  23. Thank you. bsingh@wegowise.com