Andrew Lee on Farcaster

Content pfp

https://opensea.io/collection/dev-21

0 reply

0 recast

2 reactions

Andrew Lee pfp

Here's how our developer tooling allows us to ship 100+ features per year with a team of 9. I’ll cover 🧵 - Our monorepo - One-command local build - Shared multi-platform code base - CI - Multiple staging environments - Fast deployment & easy rollback

3 replies

5 recasts

20 reactions

Andrew Lee pfp

Our development environment is central to how we work, not just for engineering, but for *everyone*, in every function. Not only are all of our apps in code, but so is our website, blog posts, emails, marketing assets, etc. Git is the common language we speak across the whole company.

1 reply

0 recast

1 reaction

Andrew Lee pfp

Every person, from me, to our growth specialist, to our designer, is working directly in code: testing & reviewing things locally, making changes, and shipping.

3 replies

0 recast

1 reaction

Andrew Lee pfp

How do we enable this? With a monorepo. All of the code for our core product, including web, iOS, Android, backend code, k8s config, etc. all lives in a single repo. This makes setup easy, and it gives us versioning & code review for changes across the entire stack. It also makes testing easier.

2 replies

0 recast

0 reaction

Andrew Lee pfp

We are obsessed with making our local development environment work with only a single command -- including loading test data. We use Bazel for our builds, and all of our configuration is code, checked into git. This makes getting started fast and keeps everyone's dev env moving in sync as our infrastructure evolves.

3 replies

0 recast

0 reaction

Andrew Lee pfp

It's a ton of work to set this all up, and ensure that *everything* we do works in both production and development environments (esp. with AI!), but it's worth it.

1 reply

0 recast

0 reaction

Andrew Lee pfp

We share a single code base across all client-side platforms (web, iOS, and Android). All of our business logic is in Typescript and separated from UI code with clear internal APIs. 90%+ of our business logic is shared across all platforms. We use React Native on iOS, and drop down to native only when we have to.

1 reply

0 recast

3 reactions

Andrew Lee pfp

Next: CI We lint and test our code automatically on every commit using Github Actions. We aggressively enforce linting and code formatting rules to avoid bad habits and bikesheds.

2 replies

0 recast

2 reactions

Andrew Lee pfp

We make it really easy to get code onto staging environments for testing. Our backend has a staging cluster that mirrors our production cluster. It's smaller (to save $$) but functionally the same.

1 reply

0 recast

0 reaction

Andrew Lee pfp

Our web frontend can be deployed to many different staging environments, each with its own subdomain. Everyone on our team can have a different version of the app deployed to staging simultaneously. Our Android app pulls this same code (it's a PWA) so we can test there quickly too. For iOS, we use Testflight.

1 reply

0 recast

0 reaction

Andrew Lee pfp

Lastly - deployment and rollback. The goal of all of the above is to get things *shipped* -- and we do! We've fully automated deployments, and we put new code in prod 5-10 times per day.

1 reply

0 recast

1 reaction

Andrew Lee pfp

To ship things this quickly you have to make it easy to handle errors (yes we make mistakes!). This is what rollbacks are for! We save every deployed artifact and make it one click to roll back to a previous version. When something breaks in prod, we rollback first, and ask questions later.

3 replies

0 recast

2 reactions

Andrew Lee pfp

And that's the core of it! Tomorrow I'll be talking about how we use experiments to deliver features incrementally and get rapid early feedback from users.

1 reply

0 recast

1 reaction

Fidel Ramos pfp

How do you handle DB on rollbacks? Do you make schema changes backwards-compatible?

1 reply

0 recast

0 reaction

Joe Petrich 🟪 pfp

Joe Petrich 🟪

What are you using for deployments and rollbacks? We've got a lot of the same setup as you but I think we could improve our deployment process - we don't yet have canarying and we rely on Google Cloud's UI to do fast rollbacks and revert code + deploy after.

1 reply

0 recast

0 reaction