We work in small agile teams, each with a specific area of ownership. Most teams consist of a product manager & 2-3 developers. We also have a floating product designer (Luke) and staff engineer (Dave) that rotate between teams.
DoSomething.org may look simple, but it’s made up of a bunch of independent pieces that all talk to each other. This allows different teams to move independently, and helps us build systems that are more reliable when one piece fails.
Users mainly interact with our front-end applications – Phoenix and Gambit.
Phoenix Next is our web interface. It was re-built in 2017 to provide more flexibility to campaign leads, and powers any campaigns launched since October 2017. It’s maintained by Team Rocket.
Phoenix Ashes is our old web interface. It’s what users see when they visit older campaigns, the homepage, or 11 Facts pages. It’s not under active development.
Gambit is our chatbot. It allows users to sign up and reportback to campaigns by texting messages to 38383. It’s maintained by Team O’Doyle.
Aurora is our admin interface. It allows staff members to view and edit user profiles in Northstar. It’s also where we configure URL redirects & the credentials our applications use to talk to each other.
There’s a lot that happens behind the scenes too! Many core pieces of what make DoSomething.org tick are not things that our users directly touch. These tools are where important data is stored, and also where we’ve built some admin interfaces for staff.
Northstar is our user identity service. It stores user profiles, handles login & registration, and authorizes requests between our other services. It’s maintained by Team Rocket.
Rogue is our user activity service. It stores all the things users do – whether on the web, via SMS, or anywhere else! It’s also where staff members go to review reportbacks. It’s maintained by Team Bleed.
Sixpack is an A/B testing framework. We use it to opt users into experiments & track conversion, even across different services!
Quasar is our data warehouse. It stores historical and analytic data, which can be viewed with Looker. It’s maintained by Team Storm.
Blink is our message broker. It helps applications communicate efficiently by handling service failures or slowness. Think of it like the post office - rain, sleet, snow, or internet outage… it’ll get our apps messages where they need to be!
Contentful is our content management system. It’s where we write and store content for our web and SMS interfaces, like campaign information, updates, and pages.
Customer.io is our email & SMS messaging tool. It allows strategic members of staff to segment users and create messaging without any technical builds.
Fastly is our content delivery network (CDN). It’s a layer that sits in front of all of our applications. It caches static content & routes requests to the correct application servers.
Front is our SMS support tool. When a user enters a support conversation over text, the support team will see & respond to their messages here.
GraphQL is an experimental way to query resources across services. It provides a universal schema for all the data we store in different services, and finds the most efficient way for apps to query across service boundaries.
Looker is a data visualization & reporting tool that we use to keep track of our goals. It builds dashboards and reports based on the historical data gathered in Quasar.
New Relic is a performance monitoring tool. The engineering team uses it to diagnose performance problems or other errors, so we can make sure all of our applications are running as efficiently as possible!
Puck is our in-house analytics service. It’s a library which makes it easier for React applications to collect analytics, and a server that funnels those messages into our data warehouse.
Zendesk is a tool we use for email support & our help center.
Code follows a standard path on its way from an engineer’s machine to the live website. This helps us to collaborate and test our changes.
Local apps exist on engineer’s computers, and are used while working on new features or bug fixes. When they need something from another application, they’ll use our development environment.
Development apps are bare-bones versions of applications that developers connect to when building features. They are populated with fake data & routinely reset to a “factory default” state. This is always running the
master branch. You can find a service’s development environment at
QA apps (sometimes referred to as “Thor”) are the last step before production. They are refreshed with a copy of production data weekly. This is where we do QA testing before code goes live. This is always running the
master branch. You can find a service’s QA environment at
Production apps are “live”! This is the website that our users see.