Matthew Eckstein is the VP of Engineering for charity: water. For more information, visit: www.charitywater.org. Read our charity: water customer story to learn more about how Heroku has helped their organization deliver clean water to millions of people around the world.
Tell us a bit about charity: water
charity: water is a non-profit organization that brings clean and safe drinking water to people in developing nations all around the world.
We rebuilt our online fundraising and donation platform on Heroku and are super excited to share our story today, March 22nd on World Water Day.
When we first moved to Heroku, we decided to rebuild our system from the ground up. The engineering team was already familiar with Heroku, which made it an easy choice.
Tell us about your stack
Our new stack is built using Ruby on Rails connected to a Heroku Postgres database. We do a lot of asynchronous processing using Sidekiq and Heroku Redis.
We recently started adding isomorphic React components using both the Ruby and Node.js Heroku Buildpacks because we were building some complex Javascript behaviors. It seems to be going well so far.
When we think about our new stack at charity: water, Heroku is at the core of it. Any system that we build or rebuild gets put on Heroku. Also, continuous integration is woven into Heroku, which is perfect for us.
What about your application architecture? Is your API separate from your front-end client?
Our fundraising platform is one app. We don't have a separate front-end client that uses an API. We do have other apps with specific functions that are also hosted on Heroku. One such app is a Sinatra app that takes callbacks from our payment providers and syncs the data to our fundraising platform and our general ledger.
What is your deployment process?
We use Heroku’s Git integration for source control and deployment, along with GitHub, pull requests (PRs), and a continuous integration process using Codeship as a Heroku Add-on. For the fundraising app, we use a continuous delivery process.
We do test-driven development with test coverage close to 100%. So when we make a pull request, we use Heroku Review Apps for testing and merge to master. It runs CI again and deploys through Heroku Pipelines.
How do you conduct internal reviews?
We have three checkpoints before deployment.
At least one engineer will review every pull request. The first thing the reviewing engineer looks for is that the solution is simple and directly addresses the problem we are trying to solve. We would rather write clear, simple code and refactor later than risk over-engineering and create unneeded complexity. We also look to make sure it is obvious what the code does and what the effect of a change would be. One ideal we strive for is that all code pushed to production should be exemplary. Our code should have the ability to be used as an example of how to write new code. There shouldn’t be anything on our site that we wouldn’t want to replicate.
There are always comments in our PRs. Every once in awhile we will see one with many comments. It’s a good sign when that happens because it means our engineers are very actively reviewing the code. I’d rather see a clash of strong opinions than a very passive process where people are just looking for obvious mistakes.
If the PR addresses a user-facing feature, our product team and/or creative team will use Heroku Review Apps to test it from a user’s point of view as well. It’s great how seamless the review app integrates into our workflow.
Finally, we have all of our automated testing. If it can be automated, we prefer to automate it!
What other tools do you use for testing?
In our quest to reduce visual regressions on charitywater.org, we experimented with a few solutions. We started by building tools based on some open source projects. After realizing that this would be a larger maintenance burden than we initially realized, we moved on to another commercial solution. That worked pretty well, but it didn't catch the visual regressions until they were already in our production environment. Eventually, we landed on a great service called Percy.io. Percy is a continuous visual regression system that exposes visual regression at the same point that the rest of our automated tests run.
We use Codeship and parallelize our tests since we have so many but don’t like to wait. Some other tools we use include Rubocop for coding style and Code Climate to identify potentially problematic code.
What has been the greatest benefit to using Heroku?
charity: water has always been at the leading edge of using technology to drive our work. We raise a tremendous percentage of our funds online, and we also use technology heavily in our operations and to monitor our projects in the field.
Our 100% model means that we fundraise separately for operations and water projects. When we can save money on ops, we’re also saving on opportunity cost. Our fundraisers can now focus more of their time on raising money for water. Heroku’s services are so seamless and easy to use—the add-on services, the deploy process with Git integration and Review Apps—it allows our engineers to focus on work that raises money and makes our operation more efficient. Heroku’s services eliminate the need for a dedicated DevOps role at charity: water, which saves operational budget that can be applied elsewhere in the organization.
Thank you for your time!
Thanks!