Transitioning a Large Rails Codebase into Packages: Seeking Tips and Advice from Experienced Developers

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!

Message originally sent by slack user U70TIGAX94P

Yeah. I was at Shopify for that.

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.

Message originally sent by slack user U72DOM2VVHS

<@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.

Message originally sent by slack user U72DOM2VVHS

I’m a pretty big supporter of large packages that feel like small Rails apps

Message excluded from import.

Message excluded from import.

Message excluded from import.

Message originally sent by slack user U72DOM2VVHS

Multiple ways to do the same thing. It often can lead to uncertainty and inconsistency

Message excluded from import.

Message originally sent by slack user U72DOM2VVHS

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

Message excluded from import.

Message originally sent by slack user U72DOM2VVHS

in my experience at shopify, the app i worked in was pretty stable and didn’t need much reworking. outside of shopify we’re still on the first swing

Message excluded from import.

Message originally sent by slack user U7213XMGS3H

<@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!

Message originally sent by slack user U72DOM2VVHS

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.

Message originally sent by slack user U7213XMGS3H

<@U72DOM2VVHS> we set some 2024 goals, and I agree medium has a ton of value

Message originally sent by slack user U72DOM2VVHS

What do you consider “application”?

Message originally sent by slack user U7213XMGS3H

really just our legacy app and our graphql implementation

Message originally sent by slack user U7213XMGS3H

we hope we don’t have application forever

Message originally sent by slack user U7213XMGS3H

but graphql is gonna be hard to figure out