I helped a product team streamline their software release process.

From 16 manual actions per release to making 1-2 releases daily with a single Slack command. But most importantly, the team isn't afraid to make a release anymore.

A case study 👇

Team uses Gitflow, and we don't want to change it. For release automation, we focus on 3 main Gitflow branches:

~ main: production code
~ develop: ongoing work
~ release/*: code of specific version, to be merged into main

More about Gitflow: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

In the team context, *deploy* and *release* are almost the same. Deployed work is instantly available to end customers.

In a team, *deploy* relates to a single service, while *release* means deploying all 3 maintained services.

More about the difference: https://www.streamlined.engineering/p/se5-deploy-release

The team follows 4 steps to initiate and complete the release process, whether it is manual or automatic:

🚀 Initialize the release
✅ Wait for the green light to proceed
⚙️ Push all changes to the *main* branches
🏁 Wait for deployments and inform everyone

🚀 To initialize the release, we create a release branch and open a pull request to *main* for each service.

The Slack command sends a webhook to trigger an automation. The automation performs GitHub operations. The pull request workflow updates a version in package.json.

✅  After initialization, we wait for QA approval and code review before merging pull requests to ensure they are mergeable. 

QA approves via Slack thread, saving the approving person for history. An approve triggers automation to merge PRs or enable auto-merge if needed.

⚙️ When a pull request is merged and changes are pushed to the *main* branch, we create a git tag with a version number. The GraphQL API doesn't support GitHub releases yet 🙁

We then open a back-merge PR to ensure all release changes are incorporated into the *develop* branch.

🏁 Once the deployment is complete, we will provide all the necessary information. 

If it was the last service in the queue, we will notify everyone of the successful release and clean up everything to prepare for the next release in the future. 

After automation, the team makes releases with one Slack command, requiring pull request reviews for merging.

In this example, we count 16 manual steps for 3 services. More repositories will mean more manual work.

Most importantly, automation eliminates human errors, ensures consistency in steps, and removes the fear of releases.

After a few iterations and improvements, the team can confidently make a release from their phone, knowing it will function just as before.

In a real project where this automation is implemented, there are absolutely no issues related to incorrect deployments or releases. 

It's running smoothly for almost 2 years, and people are happy with it.

Streamlining Software Release Process: A Case Study

We have a Firestore collection and a few rows in an Airtable table. The job is to merge the reference arrays from both sources and update them in Firestore.

It's not a common case, but it could arise when you aim to enhance your database with external data 🧵

We start by fetching all the data. Make offers a solid Firestore (we'll address a mapping issue later) and we easily connect to Airtable.

It's important to save the reference prefix for later use, since Firestore requires the full document path for references.

Next is the crucial step: aggregate responses from Airtable into a single array, adding the prefix from the initial step.

Then, we merge both arrays and deduplicate values. By using custom functions, this process becomes much quicker and requires fewer operations.

This is our final array, merged and containing only unique values.

Now, we encounter our first challenge — Firestore integration makes it easy to select values, but how do we map our array here?

To understand this, we must explore how Make sends an update request to Firestore.

By utilizing Make's Dev Tools, we can observe the following:

We map our merged array by aggregating and parsing JSON to create the final array in the correct structure: an array of objects with a "referenceValue" field.

While mapping this in the Firestore module, we encounter an error.

After conducting some documentation research, I discovered that we should avoid using the same structure as in the HTTP body because Make prepares the payload automatically.

All we need to do is provide "valueType" and "value," and Make takes care of the rest.

And it works! 🎉

Here's how the entire scenario looks: It requires 11 operations per run, and this operation count does not depend on the amount of data we process.

If you like this thread, consider following @jurijtokarski for more content like this. 

Usually, I write about business operations automation, using Make with APIs/Apps/AI from my and my clients' experience. 

Merging Firestore References with Airtable Data

If you are running a productized agency and need to create a Trello board for a client after they successfully make a payment, this process can be easily automated:

1. Listen for Stripe events
2. Filter "checkout.session.completed"
3. Filter for a payment link

👇

First, set up a Stripe events webhook in Make.

The event you'll likely be interested in is "checkout.session.completed," which provides the payment link ID and client reference/email.

Secondly, filter for specific payment links. If possible, I would recommend storing them as organization variables.

Next, create a Trello board. If you have a demo board, include it here and it will be copied.

This is also a good opportunity to invite the client by email to join the board, as well as for you to self-join the board.

In my example, I used Make, Stripe, and Trello. However, I believe that the general process would be similar with other tools. 

For instance, Zapier offers a convenient integration between Stripe and Trello. Creating boards in other management tools should also be easy too.

Automated Trello Board Creation for Productized Agencies

Automating the distribution of blog content to social media is easy.

Here's all we need:

— A blog with an RSS feed
— An Airtable database to manage feeds and posts
— A Make scenario to check for new content
— A Make scenario to distribute the content

👇

First, we set up a database in Airtable to efficiently manage RSS feeds and their corresponding social channels.

It's important to have a "LastCheck" field in the feeds table so that we will know which content is new.

Secondly, we add tables to store historical posts. This allows us to easily access and review past content that was fetched from the blog.

"IsPublished" is a flag telling us that this post has already been processed with automation, so we will not fetch it next time.

Now, let's create a new content check scenario in Make. This scenario will run every 30 minutes, although this frequency can be adjusted based on the frequency of new content being added to each blog.

An RSS feed often lacks the necessary formatted information for publishing on social platforms. For instance, it rarely includes an image URL.

To address this, when we come across new content, we rely on the Open Graph tags. These tags define how URLs are presented when shared.

When we have RSS information and Open Graph data, we can save the post. We need to consider two scenarios:

— The happy path, where we have all the necessary data.
— A fallback scenario for when we are unable to obtain Open Graph data due to various reasons.

Another workflow in Make involves checking for unpublished posts in the Airtable database.

We start with the Airtable view "Not Published," which shows all posts marked as unpublished.

Once we have the posts, our next step is:

— Search for channels through the post feed.
— Iterate through the channels and publish a post into each of them.
— Use router filters to determine how to distribute the post, checking the channel type.

To accommodate the unique posting requirements of each platform, we create specific templates for Telegram, Twitter, and Instagram.

In case we need more social platforms, it's just a new channel type and router route to publish a post with a specific template.

The solution is quite generic: we can connect various social channels to a single feed and manage multiple feeds.

To enhance the experience, we could introduce a new Airtable interface that allows clients to conveniently manage their feeds and channels as needed.

Setting up such automation may take a few hours initially, but it can save countless hours in the long run.

It is especially beneficial when scheduling blog posts in advance, as we no longer need to remember to prepare assets and manually publish them on each platform.

Streamlining Software Release Process: A Case Study

Merging Firestore References with Airtable Data

Automated Trello Board Creation for Productized Agencies

Automating Blog Content Distribution with Airtable and Make