Skip to content
Gallery
ramp-logo
Ramp
Ramp + Infield 12/21
More
Share
Explore

ramp-logo
Ramp + Infield 12/21

Ramp Dependency Management Review (10 mins)

Summary: 3 Key Elements

Risk - relevant to Stephen’s team / Security
Effort - is this actually something the team wants to undertake
Value - we want to highlight upgrades the same way we highlight merges

Architecture

Flask monolith - were using pip tools, now poetry for deps
Some other apps have fallen by the wayside
Stephen has a particular focus on performance - database can be a bottleneck
Infra team owns AWS layer
Teams can add new packages as they see fit

Security

Eli from Security frequently getting tagged in to review Dependabot alerts
Part of the move to Poetry was better support from Dependabot

Dependency Management

At one point there was an effort to upgrade everything, which was deprioritized
Nothing stopping folks from adding new / small packages - less layers of approvals at Ramp
Non-security upgrade decisions for smaller packages are generally due to performance / feature improvements. This is generally happening reactively
Big upgrades become items on the backlog (Flask, SQLAlchemy, Celery, etc) - these aren’t just one engineer. Particularly gnarly for packages like Celery, which aren’t well maintained
Typically Stephen’s team curates docs / tooling for folks that need to fix breaking changes associated with large upgrades
Rolling out punch lists to guide and track upgrade progress

Codemods

Stephen’s team writes codemods where appropriate to make a lot of the simple changes (typically can do 60%) of the work
Have used Semgrep - good for detection, bad for rewriting
Looking into
Grit.io
⁠
as well

Value

Understanding the (non-vuln) reasons to upgrade
PSA other teams on why the upgrade happened and what they can do now

Ramp + Infield Demo (30 mins)

Next Steps (15 mins)

⁠
Product Conversation
⁠
⁠
⁠
Raw Notes - 12/4/23
⁠
⁠
Notes
“Random ideas”
Who owns what? Who should be the person that we point to? We have code owners set up
This is only referenced in one module - the team owns this thing
Flask - used in so many different places, that it’s owned. Crawling import files. Import lib
Have a mapping of code owner to slack channel. “You’re the only owner of this.” Tag them in automatically.”
Main monorepo - a bunch of other random things that we’re not allowed to call microservices
Many are written in python
We’ve upgraded this version in core
Hey growth team, you’re the only ones who haven’t done the upgrade yet
When the complexities map to other services, then the other teams choose not to do them.
Based on the size of the foundations team, the 25 number makes sense.
Active interactors vs passive beneficiaries
Stephens team - 150 developers interactors. Would be nice for the folks who are interacting with the tool.
Dark mode
Tractable thing for you to look through, split up by team. If a new update comes up, you should take a look at this.
If a team is completely ignoring this, they get chased
Who upgraded it in the past, who’s been associated with work in the past. Who has touched it over the last 2 years
People can add dependencies willy nilly. If you’re introducing something, for them to have looked at how many stars does it have.
Active / passive user - who is benefitting
This will be deprecated in future versions
Contractor goes through and fix a bunch of problems at once.
Install the github app.
Want to exercise tooling on a major upgrade. Stale packages - non-blockers.
Use this in a different service that

Ramp Dependency Management Review (10 mins)
Summary: 3 Key Elements
Architecture
Security
Dependency Management
Codemods
Value
Ramp + Infield Demo (30 mins)
Next Steps (15 mins)
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.