Recently I’ve been developing an internal project related to continuous integration and publishing of content to Trailhead.com–Salesforce’s fun, free, innovative, and hands-on learning experience platform.

We define metadata about modules and trails in a custom Salesforce app, then writers commit their content to Git, and then our current build system does ✨ magic ✨ and our release managers are alerted of any issues. If all goes well, then about once a week you all enjoy new badges to gain new skills and grow your careers. 💪

It takes a lot of people a lot of time, energy, and Trailheart ❤️ to pull this off well.

If there are any build issues then the release managers notify the writers. Manually. ⏳

So one of the goals of this project is to reimagine our continuous integration pipeline to make the build faster and provide feedback to our writers quicker (among other business objectives). 🎯

Inspiration

Also, recently, I’ve been doing a lot with Salesforce DX and continuous integration to automate validating my code changes in pull requests. For example, I presented at TrailheaDX ’19 how to use GitLab Pipelines to automate the creation and deployment of unlocked packages, and I connected CircleCI to my open source app Mass Action Scheduler.

What I enjoy about CI/CD for GitHub, GitLab, and Bitbucket is that developers get near real-time feedback on the validity of their pull requests. There’s no other system that the developers need to go check. The feedback is contextual at the point where the developer submitted their changes.

In GitHub, this feedback can surface itself as checks.

And developers can explore those checks to see details about why their pull request passed or failed.

Vision

My vision for this internal CI/CD project for Trailhead content publishing is to provide our writers a similar experience that developers get when using CI/CD services with GitHub, GitLab, or Bitbucket.

As writers commit their changes to our private GitHub instance, a new custom GitHub App I’m developing will validate their content (a mix of linting and querying other internal services) then provide near real-time feedback as “checks” on their pull requests.

The tech stack for this proof of concept involves Salesforce, Node.js, Heroku, GitHub Apps API, and Redis.

This project is a lot of fun, and over the next few weeks I’ll be blogging about the technical highlights and things I learn along the way that I think you all might find interesting.

First up is that I learned how to use Postman to generate SHA1 signed signatures to mimic headers in GitHub webhook payloads to test my web service which verifies the request based on the expected signature.