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

Laying the Cultural and Technical Foundation for Big Rails

Alex Evanczuk
May 20, 2022
420

Laying the Cultural and Technical Foundation for Big Rails

As applications built on Rails get larger and larger, and more and more engineers work in the same monolith, our community needs to think more about what sort of tooling and architectural changes will help us continue to scale. This talk shares ideas around a toolchain, and more importantly, the social and cultural programs needed to support that toolchain, that can be used to help engineers in an ever-growing Rails codebase continue to have high velocity, manage their complexity, and claim ownership over their own business subdomains.

Alex Evanczuk

May 20, 2022
Tweet

Transcript

  1. Thank you to those who have helped maintain and contribute

    to Rails. Thank you to those who have helped put together this conference.
  2. What is Big Rails? A system of sociotechnical tools, practices,

    and conventions that scale Rails development in terms of lifespan, number of contributors, and complexity. A Definition Accountability and Ownership Clear Boundaries Thoughtful Dependency Management Gradual Adoption Intentionally Curated and Sustainable Feedback Loops Major Principles
  3. github.com/bigrails/code_ownership github.com/bigrails/code-ownership-vscode github.com/bigrails/bigrails-teams # config/teams/payroll.yml name: Payroll slack: handle: '@payroll-team'

    room_for_robots: '#payroll-notifications' room_for_humans: '#payroll’ github: team: '@Gusto/payroll' owned_globs: - app/services/payroll_syncer.rb team = Teams.find(‘Payroll') CodeOwnership.for_file('app/services/payroll_syncer.rb') == team CodeOwnership.for_class(PayrollSyncer) == team begin PayrollSyncer.sync_deductions! rescue => ex CodeOwnership.for_backtrace(ex.backtrace) == team end
  4. app/ models/ benefits/ payroll/ hr/ views/ benefits/ payroll/ hr/ controllers/

    benefits/ payroll/ hr/ services/ benefits/ payroll/ hr/
  5. app/ models/ benefits/ payroll/ hr/ views/ benefits/ payroll/ hr/ controllers/

    benefits/ payroll/ hr/ services/ benefits/ payroll/ hr/
  6. app/ models/ benefits/ payroll/ hr/ views/ benefits/ payroll/ hr/ controllers/

    benefits/ payroll/ hr/ services/ benefits/ payroll/ hr/ github.com/bigrails/stimpack packs/ benefits/ models/ views/ controllers/ services/ payroll/ models/ views/ controllers/ services/ hr/ models/ views/ controllers/ services/
  7. packs/ benefits/ models/ views/ controllers/ services/ + package.yml payroll/ models/

    views/ controllers/ services/ + package.yml hr/ models/ views/ controllers/ services/ + package.yml # packs/benefits/package.yml enforce_dependencies: true enforce_privacy: true dependencies: - packs/payroll metadata: owner: Enrollments github.com/shopify/packwerk
  8. packs/ benefits/ models/ views/ controllers/ services/ + public/ + package.yml

    payroll/ models/ views/ controllers/ services/ + public/ + package.yml hr/ models/ views/ controllers/ services/ + public/ + package.yml # packs/benefits/package.yml enforce_dependencies: true enforce_privacy: true dependencies: - packs/payroll metadata: owner: Enrollments github.com/shopify/packwerk
  9. # packs/benefits/app/services/benefits.rb module Benefits def self.some_method HrHelper.inform_administrator! end end #

    packs/benefits/deprecated_references.yml --- packs/hr: "::HrHelper": violations: - privacy - dependency files: - packs/benefits/app/services/benefits.rb
  10. Okay… but what about gems and engines? github.com/bigrails/package_protections Gems/Engines Packages

    Supports gradual modularity ❌ ✅ Inexpensive to change boundaries ❌ ✅ Supports distribution ✅ ❌ Supports versioning ✅ ❌ Fast tests ✅ ✅* Supports strict boundaries ✅ ✅** Engine features ✅ ✅*** * With spring and bootsnap ** With package_protections *** With stimpack
  11. To start off, 100% of packages do not enforce privacy

    or dependency protections. The challenge: Push every team to turn on privacy and dependency enforcement Gradual Adoption
  12. Feedback loops to focus on… Dev writes code Dev commits

    code Dev’s packwerk build step fails Dev updates the packwerk TODO list Dev merges PRs to the main branch ? ? ? ? ?
  13. Dev writes code Dev commits code Dev’s packwerk build step

    fails Dev updates the packwerk TODO list Dev merges PRs to the main branch ? ? ? ‼‼‼ ? Feedback loops to focus on…
  14. Dev writes code Dev commits code Dev’s packwerk build step

    fails Dev updates the packwerk TODO list Dev merges PRs to the main branch VSCode Extension Pre-commit Hooks Inline Automated PR Comments Inline Automated PR Comments Datadog Metrics github.com/bigrails/packwerk-vscode github.com/bigrails/danger-packwerk github.com/bigrails/modularization_statistics Feedback loops to focus on…
  15. In what ways can Ruby and Rails continue to offer

    great tools and cultural norms that help users create well-modularized systems?
  16. What can the different conventions of packwerk packages, gemspecs, and

    other packaging systems learn from each other?
  17. We’re hiring! https://gusto.com/careers Feedback and Communities - Emailing me: [email protected]

    or just starting a conversation - Creating issues, starting discussions, or opening PRs in any repository within https://github.com/bigrails - Joining us in the Ruby/Rails Modularity Slack Server: https://rubymod.slack.com - Invite link: https://tinyurl.com/ruby-modularity - Catch me after the talk and let’s pair! Other Resources and Tools - “Gradual Modularization for Ruby and Rails” by Stephan Hagemann - “Thinking in Systems” by Donella Meadows - “Boundaries” by Gary Bernhardt - https://engineering.gusto.com (Gusto’s Engineering Blog) - Just released: Blog post version of this talk! Your feedback is important and appreciated!