Teams
We work in small agile teams, each with a specific area of ownership.
| Team Name | Description |
|---|---|
| 🍤🍟 Team Applications | Web & Messaging Applications |
| ⚡️ Team Storm | Analytics & Insights |
| âš’ Team Viking | Platforms & Infrastructure |
- Team Applications’ focus is on increasing organizational KPIs with our web and messaging product offerings.
- Team Storm focuses both on data engineering (getting the data into our data warehouse) and data analytics and modeling (providing the organization with actionable insights).
- Team Viking’s focus is to increase developer and staff member velocity and happiness, as well as increase overall system resilience and security.
Services
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.
Check out our system diagrams.
Front-ends
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 the user facing website and all campaigns.
Gambit is our chatbot. It allows users to sign up and reportback to campaigns by texting messages to 38383.
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.
Back-ends
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.
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.
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.
Supporting Cast
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 how we 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.
Ghost Inspector and Runscope are automated testing tools. We use them to constantly monitor that applications are functioning correctly, and sound the alarms if they’re not!
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!
Snowplow We use Snowplow and Google Analytics (with Google Tag Manager) to track web analytics.
Zendesk is a tool we use for email support & our help center.
Environments
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 {service}-dev.dosomething.org.
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 {service}-qa.dosomething.org.
Production apps are “live”! This is the website that our users see.