I found myself recently explaining the technical details of how I publish The Daily Commit (that’s the name of this mailing list you’re reading now, for those who stumbled upon this in the archives or social media). I then decided to share here, as I apply many DevOps principles, and use quite a bit of automation, but also quite a lot of systemetized manual labor.

First, the goals my setup aims to achieve:

1. Facilitate the writing and sending of daily emails to subscribers.
2. Automatically post the content to my @jhall_io twitter account, my LinkedIn profile, and possibly other social media in the future.
3. Keep an online archive of all posts, for future reference, and perhaps one day to drive SEO traffic to the page.
4. Minimize the number of tools I must manage, and the amount of daily toil required to do the above steps.

So with those goals in mind, my basic approach (which I’ve borrowed from others smarter than myself) is to treat my daily list as blog posts on my web site. This limits the number of tools required, as there’s no need to add a new writing platform. It also automatically provides the online archive I want.

All popular blogging software supports the ability to generate an RSS feed of your blog posts, and this is precisely what I’ve done with Hugo. Drip (as well as most other popular email managing software) can read an RSS feed, and automatically turn new posts into emails.

With just a little bit of glue, provided by Zapier, I’m able to easily turn that RSS feed into automated posts to Twitter and LinkedIn, and I could easily expand to other social platforms or content syndication sites (as long as they support RSS or have a Zapier integration) if/when I so desire.

With this in place, my daily routine looks something like this:

1. Create a branch in my web site’s git repository.
2. Run a script that copies my daily email template to a new file, and sets the date.
3. Write my content. Optionally set a banner image (used when posted to social media), description, tags.
4. Commit the changes and push to GitLab, where my site’s source is hosted.
5. The branch is automatecally run through some automated CI tests, which ensure the site generates valid HTML, there are no broken links, etc.
6. After reviewing my own merge request, I merge.

The entire process can take as little as 5 minutes per day. If I’m on a roll, I’ll bang out 3 or 4 days worth of content in one sitting in 20 minutes or so.

From there, the rest is automated:

• Every morning, an automated GitLab-CI job runs to publish that morning’s version of the site (any future-dated posts are otherwise ignored). This allows me to schedule batches of daily email content all at once.
• Within minutes, Zapier will notice the new item in the RSS feed, and post to Twitter and LinkedIn.
• Every day at a schedule time Drip checks for new content, and creates the daily email from that.