Tithe.ly Engineering

Engineering blogs are pretty trendy these days. Here at Tithe.ly, we didn’t want to be left behind. Plus, our engineers solve problems every day that we feel should be shared widely with our community. Let’s get a little meta and talk about how we stood up the site you’re on.

Building the Ship

Setting out to build the blog, we had three goals in mind:

• Provide an easy-to-use platform so that developers of different disciplines could contribute
• Make writing and contributing a post as frictionless as possible
• Build in peer review as a natural part of the publishing process

To address the first goal, we settled on a statically-generated site. There are many tools to do this, including Bridgetown (a Ruby version that we picked), Jekyll and Gatsby.

A static site’s power is that it vastly simplifies our infrastructure requirements (more on that later). It also allows anyone to contribute content using Markdown and quickly work on the layouts and styling.

In the end, we chose Bridgetown because the team spearheading the blog effort was primarily proficient in Ruby, and there was minimal overhead to get started. There was also a Bulma plugin that we could use for some excellent, out-of-the-box styles.

Tackling the remaining goals was achieved with GitHub. Bridgetown sucks in new posts from a _posts directory and, given some metadata, automatically knows how to tag, timestamp, and display them. Our engineers can open a new pull request with the post they are working on and receive code reviews from other engineers. Using this familiar workflow makes the contribution process less daunting, and the content becomes more collaborative.

Adding Wind to the Sails

Even though we had a static site built, we needed a simple way to deploy and serve it to quickly allow any of our engineers to publish new site styles and content. If you’ve needed to deploy a static site in the last three or four years, you’re probably aware of the plethora of options that have sprouted up, thanks in large part to the Jamstack movement.

Some options include Netlify, Vercel (previously Zeit), and Render. While each of these options is great, hosting our products on one of these providers would have introduced a new infrastructure vendor for our DevOps folks to maintain. We run everything on AWS here at Tithe.ly, so we wanted a solution from there. With 100s of services, surely AWS had something we could use?

Most major cloud providers have a storage bucket solution (S3 in AWS’s case) where you can upload a published static site, and it will host it for you. Storage buckets are an excellent option if you have an existing deployment solution and can automate building and pushing your static site to S3 on a trigger.

It turns out that AWS has an even better option that easily interacts with GitHub for deploying and hosting static sites. AWS Amplify has been around for a few years now and is a toolkit for quickly building web and mobile apps (think Firebase). There are many offerings inside of Amplify, from data storage, authentication to easy serverless function setup. All of these are lovely facades over existing AWS services that Amplify makes dead simple to configure.

We have Amplify configured to look at the GitHub repo where we host this engineering blog. On PRs, Amplify will build and push up a preview site specific to that commit where we can verify formatting and any new styling or functionality. From there, any time we commit to our qa or production branches, we trigger an automatic deployment to the respective environments—all with minimal configuration of a CI/CD server or hosting infrastructure.

Launching the Ship

Taking the ship metaphor to its inevitable conclusion - an ocean-going static site is only as good as the cargo in its hold. The final step in pulling the blog together was to get over that initial hurdle of having zero content.

We addressed the content problem by sharing the vision of the blog with the entire engineering department. Then, recognizing that a request to everyone is a request to no one, we reached out individually to several people we thought might be interested in contributing an article to help launch the blog.

Securing commitments this way is critical, especially when you have a large team of busy and focused engineers.

Part of the pleasure of working at Tithe.ly is that we have a talented pool of engineers working on a large variety of projects. With so much development and learning occurring every day, there’s no shortage of information to stow away on our vessel. Whether it’s through work done on our iOS app, full-stack Rails projects, or VueJS API-backed front-ends, our engineers are constantly learning and doing something new and exciting.

As the early PRs began to trickle in, we used feedback from those contributors to better document and refine our process to make it as easy as possible for other engineers to add posts. We added this process to our blog project repo’s README file to make it easily accessible to anyone considering sharing an article.

In preparing to launch the blog, one mistake we made was not being more attentive to the state of the PRs. As it turned out, many of the posts were only partially completed. We assumed the presence of a PR indicated the post was complete when, in reality, that was not always the case. There were several reasons for this, including some of our engineers teaming up to co-write articles and people getting pulled into other high-priority work.

Finally, as we move past the blog’s initial launch, it’s important to remember that “vision leaks.” We will need to regularly bring the blog’s vision in front of the team and champion people’s contributions.

The entire blog project came together with far less effort or complexity than was initially envisioned. Thanks to choosing a simple tech stack and engineers’ efforts to create the initial posts, we are up and running and looking forward to reading what comes next.

Every day is a great day to set sail at Tithe.ly.