This message was imported from the Ruby/Rails Modularity Slack server. Find more info in the import thread.
Message originally sent by slack user U722X9GVQWA
At Handshake we are a couple months in to adopting Packwerk and the rubyatscale suite of gems including packs, packs-rails, code_ownership, code_teams, visualize_packs, and pack_stats. We have a pretty large and old rails codebase - 12 years old, around 600 tables, and around 7k ruby files (excluding specs/configs) + 4k haml files.
So far we have moved ~4% of our code into a package, and have decided to accelerate by migrating all of our code to a package in one go. We’ve identified ~50 domains or so, and ~50 other packages for “utility” and “component” architecture layer packages.
I’m keen to speak to someone who has done a similar “big bang” transition of an existing large rails app into packages. Any tips, learnings, etc. Anyone in here who was at Shopify when I think they did something similar?
We’re also excited to be going on this journey and hopefully start contributing a bit to the open source libraries and sharing our experience!
Notably we didn’t have the ruby at scale stuff, and neither did we have packwerk at first (we built it 2 years into the effort).
We chose to split into large domains following ideas from DDD, in a way that later turned out to line up really well with a re-org of the company into product lines. That also means we had 25-150 developers per domain / component (later package).
So pretty large packages.
We added smaller packages later but treated those very differently, they were a lot more light-weight.
<@U722X9GVQWA> Philip wrote a great blog post on part of the transition back in 2020. I especially recommend the “Understand Developer Behaviour” section.
After leaving Shopify (where I worked in a Rails app with packwerk - but not the other ruby at scale stuff) and joining a new team where we’re moving into packages, the main advice I’d give is to keep the migration steps as simple as possible.
The more you can move everything consistently and without tons of pattern fragmentation the better for everyone.
I think you want to move into packages consistently. i.e. if some enforce privacy from the get-go and others don’t, that’s a variation, if some enforce namespacing and others don’t, another variation. its not inherently coupled to breaking down a monolith but it is a struggle i’ve experienced in keeping consistency during the packwerk rollout
<@U722X9GVQWA>, One Medical is at a very similar place. we’re developing some tools to help us track progress and understand the process.
• we have a tool that let’s us graph usage of globs + regex over time
• we have a framework for classifying packs’ maturity. in the future we see this driving CI behavior
• We’ve developed a training series that we’re doing with individual teams to help them with the mental frame shift of thinking modularly and adopting the tooling. We’re maybe 15% of the way through with teams and the curriculum and our tools keep evolving
• We’re making JSON artifacts of all sorts of things and then using them for visualizations (https://rubymod.slack.com/archives/C02TLU33RNW/p1700487781246239)
I’d be happy to chat any time about all this stuff!
Thanks for posting that again <@U7213XMGS3H>. I never downloaded the last iteration of your modularity chart and i liked that framing of phases.
Did you ever establish a minimum bar for teams to strive for and by when? Your “medium” bar feels like a really meaningful place for teams to reach even without privacy enforcement.