WebOps Workflow Spotlight: ThinkShout

Agency partners are key to the ongoing success of our business here at Pantheon—it’s why we exist and why we are continually iterating on our development tools for agencies. While we think we’ve built a pretty solid system for team collaboration, we know how each agency works on Pantheon varies quite a bit. We've started interviewing some of our agency partners on their internal workflows and look forward to sharing their stories with the rest of our community. 

ThinkShout is a Portland based development agency that takes on big projects for mission-driven organizations, primarily nonprofits. Over the past five years, they’ve developed a team of 26 top developers, strategists, and designers pushing out award-winning sites annually. We took time with CEO Lev Tsypin and CTO Tauno Hogue to talk about just how big projects get done at ThinkShout, and how they use a variety of tools to keep things rolling.

Image

Open Source Chops

ThinkShout is dedicated to giving back to the open source community. To date, they've got around 70,000 Drupal sites running on their contributions and the number keeps climbing. Notable Drupal integrations include Salesforce, Mailchimp, Entity Registration, and even their own native Drupal CRM for nonprofits called RedHen.

With all of this to manage along with client work, organization and repeatable processes need to be a priority. Lev and Tauno walked us through how they start and maintain their client sites through ThinkShout’s established internal development workflow.

Feature Branch Philosophy Through GitHub Workflow

ThinkShout starts all Drupal 7 projects with a lightweight common codebase called TS Build. This starting point is customized for each project into an install profile specific to the site. GitHub serves as version control master to all projects. The GitHub repository is lean, consisting of only the custom code and theme for the site without Drupal core or any contributed modules or libraries. To turn this repository into a full Drupal site and deploy it to Pantheon, TS has two helper scripts that fire off a Drush Make build of a site and push the code out to Pantheon.

ThinkShout’s developers work locally and commit their changes to feature branches in the GitHub repository. Master in ThinkShout’s GitHub repo is essentially their release branch. A deploy script pushes code from master into their development environment on Pantheon. Feature and release branches are frequently deployed to Pantheon Multidev environments for QA or client review. Only work that has been reviewed and approved in release branches is merged into master and deployed to the development environment. This allows for hotfixes to be easily deployed to the live site without having to release in-progress work. This is the ideal, but Lev and Tauno were quick to let us know that process tweaks happen as projects require them.

Iterating on the Process for Drupal

ThinkShout has launched two new Drupal 8 sites on Pantheon in the last month and has embraced Composer, Robo, and CircleCI for their development workflow. Taking lessons from their Drupal 7 build scripts, they are now building Drupal 8 sites using a customized “drupal-project” Composer project template that incorporates Robo as a task runner to assist with building, installing, deploying, and running tests. To further simplify deployments, CircleCI is being used to automatically deploy code changes in the GitHub repository to a Pantheon environment with a matching branch name (or create a new environment using terminus if one doesn’t exist).

“Standardizing on Composer and Robo has simplified our development workflow and allows developers to focus on what they do best—building sites—rather than debugging cryptic Bash scripts ”  

— Tauno Hogue, ThinkShout CTO

Incorporating Clients Into the ThinkShout Workflow

This workflow process seems pretty solid, but we were curious how it plays out in more complicated client situations—so we asked just that. ThinkShout’s client, The Forum of Regional Associations of Grantmakers, takes the need for feature branching to the next level.

Like many of the nonprofits they work with, The Forum of Regional Association of Grantmakers has a parent site with individual sites for each of their 36 regional associations. Some standards need to be maintained for the sake of the larger organization, but it is important for each regional association to own and iterate on their site as needed. This helps keep ongoing maintenance and development costs under control, and ThinkShout notes how fortunate it is to have a client with the technical know-how to contribute to ongoing development.

For this case, ThinkShout built a Drupal distribution using the build scripts and tools they use on other Drupal 7 projects. The distribution is hosted on GitHub and deploys to a custom Pantheon upstream. From here, each association has the ability to apply updates from the distribution and incorporate their own custom themes and modules using Pantheon’s development tools.

The individual regional associations have extensive customizations within their Pantheon repos, but are built on top of the single upstream ThinkShout has created. ThinkShout's work lives in profiles/ and the client's work exists in sites/all/. Feature branching and QA’ing upstream releases with the client is essential to ensure the stability of the upstream that all of the regional associations rely on.

“We’ve worked closely with them [Forum of Regional Associations of Grantmakers] to review feature requests for inclusion in the distribution. By including features in the distribution, many organizations benefit from the work being done.”

— Tauno Hogue, ThinkShout CTO

Advice to Other Agencies

ThinkShout has certainly created a solid workflow to fit their team and clients, proven further by it holding up and evolving for their Drupal 8 projects. We know this didn’t happen overnight, so we asked Lev and Tauno what advice they’d give to agencies who are still trying to nail down a solid workflow for their team.

"Minimize the number of steps involved in each stage of development and deployment. The following are options for triggering a stage in a development workflow, starting from the most preferred option:

1. Fully automated. Commit your code to the right branch and the rest happens auto-magically.

2. Push a button.

3. Run a script.

4. Run a set of prescribed commands.

5. Do it yourself.

You can imagine the increased room for human error that's introduced with each of those approaches."

— Lev Tsypin, ThinkShout CEO

"Make your development/deployment workflow as simple and environment-independent as possible. Doing so will make using continuous integration services and tools considerably easier."

— Tauno Hogue, ThinkShout CTO

Thanks to ThinkShout for taking the time to chat with us, we think our partners are doing some pretty cool things in their day-to-day workflows and are excited to share them. Not a Pantheon partner? See what Pantheon for Agencies has to offer.