Automating Email Template Deployment

 | 

Background

 Livongo has been partnering year over year with Kleiner Perkins’ Silicon Valley Fellows program. Lauren joined us as a software engineering intern through this program for the summer of 2018. This post is about one of Lauren’s summer projects to automate email template deployment. Her work is currently being used as part of our production deployment.

Automating Email Template Revisions

Livongo currently uses SendGrid as a transactional email service. Using this platform, email templates are stored with parameters that allow us to later customize these messages for our members. These templates are subject to change and sometimes new templates need to be added.

The Old way

Previously, Livongo used a single production level SendGrid account, and older email templates were manually stored by a designated archiver for the purposes of version control. However, this method of email template revisioning had a number of flaws.

Inefficient Workflow

Although SendGrid has its own code editor that allows users to create templates directly on its website, many developers choose to use a source code editor of their choice during development. While it is easy enough to copy and paste their work into SendGrid, this still provides an extra step that breaks up the usual flow of work. Other hassles include having to navigate through SendGrid’s UI to find the correct templates as well as manually perusing through old versions in the case one needs to be reactivated. These inefficiencies add up to an amount that cannot be disregarded.

Dependent Version Control

While SendGrid has the capability to store multiple versions per email template, the `Updated` date/time associated with each version can be modified in such a way that makes it chronologically unreliable for version control. Thus, with the previous revisioning system, the older versions of the templates were stored manually. The developer would have to notify the one in charge of archiving before any changes could be made, which created a chain of needless dependency.

Single Environment

Another flaw of the old system was that template changes and additions would have to be done through the one production-level SendGrid account. This lack of a formal environment separation made it difficult for QA to test and validate the email templates.

The New way

Automated Script

To combat these problems, a new system has been put in place. All of the email templates are placed in a repository on GitHub. For security reasons, Livongo manages completely separate service environments for “production”, “pre-production” and “integration.” Developers only have privileged access to the integration environment, and the other two are managed by our dedicated DevOps/SRE team.

A SendGrid account was created by our DevOps team for each of the different environments. The script runs as part of the Jenkins job that builds and deploys to these specific environments. The code doesn’t know which environment its running on for security reasons. It picks up the API credentials as configured for that specific build by our DevOps team.

Using the SendGrid Python Library, we have developed a script that pulls these templates, hashes the contents, and compares them to those stored on SendGrid. It determines the appropriate changes, such as creating a new template, creating a new version to an existing template, or reactivating an older version.

What Is Gained

Committing email templates to GitHub allows our developers to modify or create new templates as part of their usual work flow. No need to go through SendGrid’s website anymore, business as usual. This also serves as our new version control system for the templates since GitHub tracks all commits. With this inherent version control, we have phased out the middle man for manual record keeping, making the process more efficient.

By virtue of having a separate SendGrid account for each environment, we have also ensured a safer testing process. Whichever environment is being used for building and deploying is the same environment account in which the email templates are being updated, syncing the email template revision process with the tried and tested structure of how our codebase is reviewed. In other words, email template revisions have become fully automated in the standard pipeline for deployment on every environment.

Leave a Reply