Forem: Stelios Sotiriadis

PR & GitHub Actions updates, now synced with Linear.

Stelios Sotiriadis — Wed, 01 Oct 2025 06:56:39 +0000

Visibility is the key!

Over the past few months, I’ve been working on a project that solves a small but painful problem for my team: keeping track of DevOps events across GitHub and Linear.

We often missed important updates because they lived in GitHub while our planning and tracking lived in Linear. That disconnect caused delays, confusion, and extra manual work for all our PMs, developers and SREs.

When events started showing up in Linear instantly, everything became easier. It helped us:

Catch problems right away.
Work together as one team — PMs, Devs, and SREs all share the same view.
And since we’re chasing SOC-2 compliance, every event and violation was automatically documented for audits.

What we built

We implemented a Warestack feature that integrates GitHub and Linear. The idea was to be flexible: one team might only need PR updates, another might want GitHub Actions, and others might need to know about protection rule violations. We focused on events like GitHub issues, PRs, deployment reviews, and workflow runs.

Our decision was simple — deliver these updates as comments in the related Linear tickets. And it worked.

A simple example

Say our team opens a pull request without the required reviewers. Normally, this would slip through unnoticed until much later — probably after it caused delays or, worse, a broken release.

With Warestack, the violation is caught right away. The related Linear issue is automatically updated, and both Developers and PMs get instant visibility — no extra work required.

Easy setup

We wanted this to be frictionless. Setup takes just a couple of minutes, 1' to connect, 1' to configure and done.

Getting started

This tutorial walks you through how to:

Connect Linear.
Configure triggers.
Automatically receive DevOps updates (PRs, workflow runs, rule violations) as comments inside your Linear tickets.

👉 You can find the tutorial here.

Step 1: Connect Linear

You only need to do this once.

From the Warestack dashboard, go to Integrations to view available software connections. Click Connect next to Linear to start the installation.

Authorize Warestack in Linear by granting the requested permissions and clicking Authorize.

Once connected, you’ll see a success message confirming Linear is active.

Step 2: Activate Post Actions

Open Post actions from the left menu to configure what happens inside Linear after events are executed.

Choose Linear Integration to create your first post action and start receiving automatic comments in Linear for Warestack events. You can select your preferred combinations of events to send.

Select a team, event type, trigger conditions, and the Linear team that should receive the comments, then save the action. You can also configure additional rule violation triggers (e.g., “PRs must have at least 2 reviewers”). Configured actions will now appear in the Linear card.

Well done! 🎉 Your first trigger is live.

Step 3: Work as Usual

Continue working as you normally would. Warestack runs in the background, checking events and automatically commenting when violations occur.

Check your Linear where updated it your ticket.

Scroll down to view the comments Warestack added. Everything happening in your operational workflows is now documented directly inside your tickets.

Having trouble?

Connect with me and we’ll figure it out together.

Warestack Does Not Stop Here!

Multiple actions: You can configure multiple Linear post actions per team, repo, or rule.
Free forever: Linear integration is included in the free plan, so you can try it out with your favorite repository at no cost.
Multi-channel visibility: Combine with Slack notifications (or Jira) to keep your team in sync everywhere.
End-to-end associations: Warestack links pull requests → workflow runs → tickets → rule violations, giving you a complete DevOps activity graph inside your project management tool.

How do you catch pretty much every bug before it hits prod?

Stelios Sotiriadis — Thu, 25 Sep 2025 16:33:43 +0000

⚡ Release Code Like a Pro ⚡

If you lead a dev team, or want to code like one, this article is for you. Writing code with AI is easy; delivering it safely and reliably is where great engineers stand out.

YOU NEED TO TRY WARESTACK TODAY!

I shot a set of videos that show you how to use agentic protection rules, all in less than 10 minutes!

What agentic protection means?

Just describe your rule in plain English, turn it on, and carry on working as usual. Warestack keeps an eye on your PRs, workflows, and other events, flagging them when something doesn’t meet the rules.

What rules can I create?

Type any rule you can imagine. Here’s what other users built to keep GitHub PR changes in check.

if a .sql file changes, require a matching migration script.

Flag PRs with heavy AI-generated code.

WATCH THE PLAYLIST!
↓↓↓↓↓↓↓↓↓↓↓↓↓↓

Why this matters?

You know best what your team does today and where the biggest risks are. Now you know how to create the rules that matters to YOUR TEAM!

Wanna try it?

Visit: https://www.warestack.com and sign up for a month's free trial.

Do you like it? Drop me an email I will give you 6 months free access: stelios.sotiriadis@warestack.com

Agentic DevOps: The Future of Adaptive Governance

Stelios Sotiriadis — Wed, 20 Aug 2025 09:23:33 +0000

WE JUST RELEASED IN PRODUCT HUNT!

Right now, there are only two common approaches to branch protection.

For years, DevOps protection relied on these rigid, static rules. YAML configs, hardcoded scripts, forms, and CI workflows enforced guardrails, but they couldn’t keep up with today’s fast, multi-repo SaaS environments. But what if your team deploys hundreds of times per week? These outdated protections leave critical gaps, blind to urgency, team structure, or operational context.

The result? Workarounds, skipped checks, and rules drifting out of sync.

At Warestack, we believe DevOps needs to evolve. That’s where Agentic DevOps comes in. Instead of static rules, agentic governance brings adaptive, AI-driven protection that reacts in real time to developer roles, urgency, and live activity. Think of it as a process checker for your pipeline — watching every event, flagging unsafe operations, and blocking risky merges before they hit production.

We put this approach to the test.

In an experiment with 100 pull requests across major open-source repos like VSCode, React, Terraform, PyTorch, and Kubernetes, agentic governance uncovered up to 8× more violations than traditional methods, with coverage rates as high as 95%. It caught issues static rules missed — vague PR descriptions, review gaps, or unapproved changes to sensitive code paths — all while adapting across teams and repo structures without hardcoding.

What is a Agentic DevOps?

A way to define the boundaries of how your team should operate, specifying what’s allowed, what’s enforced, and where flexibility is permitted.

The impact is clear.

With Warestack, you can write protection rules in plain English, monitor every operation in a single dashboard, and generate audit-ready reports instantly. What once took hours of manual configuration now takes seconds. And with one-click integrations for tools like Slack and Linear, enforcement extends seamlessly into your daily workflows.

The future of DevOps isn’t static; it’s adaptive. Agentic DevOps ensures your pipelines are accessible, context-aware, and secure — protecting critical releases without slowing teams down. We’ve shared our full findings, lessons learned, and open-source contribution in the newly released white paper.

👉 Read the full article

Enforce DevOps best practices and eliminate production errors!

Stelios Sotiriadis — Thu, 02 Jan 2025 20:21:03 +0000

We’re developers, and we love best practices—but let’s be honest, we often bypass them.

And you know what? That’s okay! You are not alone!

This popular GitHub post resonates!

People will forget all your contributions and hard work but not the time you were forced to push into the main branch!

Why?

Because sometimes speed, urgency, or unforeseen challenges force us to take shortcuts. The real problem isn’t occasional bypassing—it’s when these bypasses go unnoticed, untracked, and unaddressed.

Best practices aren’t about perfection; they’re about consistency, visibility, and accountability.

That's why we rely on an ever-growing stack of tools to automate our processes. We trust these tools! For example:

Jenkins for CI/CD
GitHub for code management
Jira for task tracking

But here’s the issue:

These tools operate in isolation—they don’t share context.

In a recent interview, a tech leader shared:

"A failed test in GitHub doesn’t stop a Jira ticket from being marked as 'Done'."

That’s a bad practice—and it leads to teams firefighting 500 errors in production, blindfolded and in the dark.

Who knows what caused the error?

Was it a skipped test?
A broken workflow run?
A failed check?
Or maybe an impactful update, like a database migration?

Without clear visibility and actionable insights, finding answers feels impossible.

Errors don’t exist in isolation—they leave clues scattered across different tools. The challenge is connecting those dots and focusing on the right clues.

The solution: Enforceable best practices

As a team, we must always know what’s happening across our toolchains.

This means:

Best practices must be enforceable—not just referenced.
Critical steps can’t be optional; they must be monitored, enforced, and standardized.
Every skipped test, failed check, or bypassed review should trigger visibility and accountability.

How can Warestack help you monitor and enforce best practices?

Warestack is a free DevOps tool that helps teams monitor and enforce best practices across events like issues, pull requests, and deployment reviews.

We do this in three simple steps:

Step 1: Connect your tools

Integrate tools like GitHub, Jira, and more to access key events as a team directly from Warestack.

Step 2: Enable best practices to monitor

Enable and customize pre-built best practices—or suggest new ones!

Examples:

Require at least two reviewers per pull request.
Enforce conventional commit message formats.
All required status checks must pass before merging.
Deployments must be reviewed by someone other than the requestor.

Customize rules to match your team’s workflow, and pick severity and minimum assignees!

Step 3: Monitor violations

Head to the Monitoring dashboard to see flagged violations, complete with severity levels. Access info such as who, when, what.

Example: Pull request review

PR has no reviewers assigned (minimum required: 2).
PR was merged without required reviews.
Commit message doesn’t follow the standard format.

Everyone on the team can access the dashboard and stay aware of potential production risks.

Example: Deployment review

This deployment was self-approved by the same person who initiated it—a clear bad practice!

What’s Next for Warestack?

We’re currently focusing on enforcement, such as canceling events with unmet conditions. For example, force-cancel a deployment if it was self-approved by the same person who initiated it. This will force the initiator to request the deployment review from a different team member to ensure independent verification. This ensures accountability and visibility. That release will come out soon!

Also, we will soon support custom best practices and evaluating them against industry standards. Soon, we’ll help you identify if your team’s custom standards align with global best practices.

Further, DORA metrics are a key focus for us! Soon, we’ll help you monitor critical metrics like deployment frequency, lead time, and change failure rate and take proactive decisions to prevent issues. For example, if a GitHub workflow run fails, Warestack can automatically move the associated ticket back to "In Progress" and notify the team on Slack!

Do you like what we are building?

Then we’d love your help!
We’re also looking for pilot users!

No payment is required.
No hidden commitments.
Just honest feedback from developers like you.

We're creating a community hub where anyone can suggest a best practice.

If you’re interested, reach out, and let’s chat!

Thanks for reading,

Stelios

Automate GitHub operations with best-practices

Stelios Sotiriadis — Sun, 08 Dec 2024 10:53:55 +0000

Thank you for taking the time to read this post! We’re a small team of developers passionate about creating a tool that helps teams seamlessly manage best practices in their daily operations. After speaking with over 50 developers about their challenges, we found a common theme: following best practices consistently can solve critical problems and enable faster, more confident releases. That’s why we built Warestack. Warestack is free for developers and small teams!

Please try it out and let us know what you think!

Warestack: Manage every code change with best practices

Warestack is a developer tool that automates operational tasks triggered by code changes, highlighting best practices at every step.

Think of Warestack as an extra team member dedicated to keeping your team on track. It reminds you of essential tasks and guides you through critical processes like pull request reviews, code merges, and other workflow-driven activities.

How does `Warestack` work?

Connect your GitHub operations: Install the Warestack GitHub App and import the repositories you need to monitor—all within a single, centralized space.
Monitor key events:Warestack consolidates all workflows and events across your codebase, including issues, pull requests, deployment reviews, and workflow runs.

Best of all, Warestack is free for all developers!

How to Get Started

Visit Warestack.com and create an account.
Install the Warestack GitHub App and select the repositories you want to monitor.
Start using Warestack!

We recommend importing your past issues, pull requests, and deployment reviews to access everything from your personalized overview page.

Your overview page at a glance

Here’s an example of the Warestack overview page. It offers a unified view of all your workflow runs, even if they’re spread across different repositories. You can see issues, PRs, deployment reviews, and workflow runs from all imported repositories in a single space!

If a workflow run fails, fix it quickly by identifying the error and reviewing the details. Warestack ensures you follow best practices in resolving issues efficiently. Open the failed run in the assistant or create an issue.

Simplify issue management with best practices

Let's create an issue! Warestack automatically generates detailed issues with recommended assignees, labels, and descriptions, aligning with best practices.

If you decide to use the assistant, Warestackprovides actionable recommendations to resolve issues, ensuring you follow to industry best practices.

The assistant also helps manage daily tasks such as reviewing pull requests, generating workflows, and onboarding repositories. It ensures you're always up-to-date with the latest changes by indexing your repository's state.

Generate workflows with high standards

Let's try an example! Generate a GitHub Action that triggers whenever a user pushes code to a new feature branch. This action will notify your development channel in Slack, following best practices for team collaboration.

Let's explore another example. Set up a GitHub Action to run automated tests when a pull request is opened. This ensures code quality by adhering to best practices and providing feedback directly in the pull request comments.

Warestack's assistant gives you access to over 10,000 GitHub Actions, recommending the most relevant and widely-used ones based on best practices.

There are more!

You can explore our documentation at https://www.warestack.com/documentation on how to efficiently create issues and manage PRs and deployment reviews.

Help us make it better!

We’re constantly improving Warestack, and your feedback is invaluable. If you encounter a bug or have a feature suggestion, please contact us:

General Inquiries: stelios.sotiriadis@warestack.com
Support: support@warestack.com

Join us on this journey to make DevOps automation smarter, faster, and aligned with the best practices in the industry!

Messaging in distributed systems using ZeroMQ

Stelios Sotiriadis — Wed, 06 Nov 2024 15:20:19 +0000

Messaging in distributed systems using ZeroMQ

Let's use Python to develop the different messaging patterns.

You will need to watch the following video to follow the step by step commands.

Take your time; make sure you double-check the commands before you run them.

The following video demonstrates the commands used in this tutorial.

I run this tutorial on my GCP VM, but feel free to run it locally ✅

This tutorial introduces the concepts of sockets in Python3 using ZeroMQ. ZeroMQ is an easy way to develop sockets to allow distributed processes to communicate with each other by sending messages.

In its simplest form, a socket (node) “listens” on a specific IP port, while another socket reaches out to form a connection. Using sockets, we can have on-to-one, one-to-many and many-to-many connection patterns.

The patterns of messaging that we will examine today are the following:

Pair: Exclusive, one to one communication, where two peers communicate with each other. The communication is bidirectional and there is no specific state stored in the socket. The server listens on a certain port, and the client connects to it.

Client – Server: A client connects to one or more servers. This pattern allows REQUEST – RESPONSE mode. A client sends a request “zmq.REQ” and receives a reply.

Publish/Subscribe: A traditional communication pattern where senders of messages, called publishers, send messages to specific receivers, called subscribers. Messages are published without the knowledge of what or if any subscriber of that knowledge exists. Multiple subscribers subscribe to messages/topics being published by a publisher or one subscriber can connect to multiple publishers.

Push and Pull sockets (aka Pipelines): Let you distribute messages to multiple workers, arranged in a pipeline. A Push socket will distribute sent messages to its Pull clients evenly. This is equivalent to producer/consumer model, but the results computed by consumer are not sent upstream but downstream to another pull/consumer socket.

🚨 Note: Working with Sockets could be tricky, running again and again the same code, using the same port number/same socket, could lead to a connection that “hangs” (the server looks like it is running, but it cannot accept connections). This happens because we did not close and destroy the previous connections correctly.

The most appropriate way to address this is to close the socket and destroy the ZeroMQ context. Refer to try – catch blocks of Phase 2 and Phase 3 for more details.

In this tutorial, you might experience such issues, e.g., running multiple times the same server in the same port. If you face hanging problems, you are advised to kill the Python process, clean the TCP port number, and run the server once more (see step 11).

Phase 1: Pairing a server to a client

Let us start by creating a new VM, then we will install Python3.

Keep a copy of the VM internal IP, for this tutorial we will use the internal IP address.
1. Open a new terminal connection and run the following commands (one after the other). The last command installs ZeroMQ.

$ sudo apt update
$ sudo apt install software-properties-common
$ sudo apt install python3.8
$ sudo apt-get -y install python3-pip
$ pip3 install pyzmq

Type: Y when prompted.

Many applications these days consist of components that stretch across networks, so messaging is essential. Today we will use TCP for message transferring.

You can access your VM using VSC, or you can run the commands using the SSH and edit files with pico, in my case I will use SSH.

🚨 Make sure you copy code carefully.

We will need to create our first ZeroMQ server, the server will allow binding with only one client at a time.

Create a new file called pair-server.py, then enter the following code.
The code creates a new socket using the zmq.PAIR pattern, then binds the server to a particular IP port (that we already openned in GCP). Note that the server will not stop running until we stop it.
Have a look at the comments to understand how this works.
Make sure that you change the ; that is the internal IP address of the GCP VM; the client port should be the same with the server.

# import the library
import zmq
import time
# Initialize a new context that is the way to create a socket
context = zmq.Context()
# We will build a PAIR connection
socket = context.socket(zmq.PAIR) # We create a PAIR server
# Do not worry about this for the moment...
socket.setsockopt(zmq.LINGER, 0) 
# Create a new socket and "bind" it in the following address
# Make sure you update the address
socket.bind("tcp://<INTERNAL_VM_ADDRESS>:5555") # IP:PORT
# Keep the socket alive for ever...
while True:
    # Send a text message to the client (send_string)
    socket.send_string("Server message to Client")
    # Receive a message, store it in msg and then print it
    msg = socket.recv()
    print(msg)
    # Sleep for 1 second, so when we run it, we can see the results
    time.sleep(1)

Do not run the server yet, first let us create the client.

Create the client and take a minute to examine the comments. I will call it pair-client.py.

Make sure that you change the ; the port should be the same as in the server.

import zmq
import time
# Same as before, initialize a socket
context = zmq.Context()
socket = context.socket(zmq.PAIR) # We create a PAIR server
socket.setsockopt(zmq.LINGER, 0)
# Connect to the IP that we already bind in the server
socket.connect("tcp://<INTERNAL_VM_ADDRESS>:5555")
# A counter will help us control our connection
# For example connect until you send 10 messages, then disconnect...
count = 0
while count<10:
    msg = socket.recv()
    print(msg)
    socket.send_string("Hello from Client")
    socket.send_string("This is a client message to server")
    print("Counter: ",count)
    count+=1
    time.sleep(1)
# Destroy the context socket and then close the connection
context.destroy()
socket.close()

We will need two terminal windows to run the PAIR example. We will run the server on one window and the client on the other. Now, run it as follows.

Run the server

$ python3 pair-server.py

Run the client

$ python3 pair-client.py

Examine the output, we just created a new PAIR socket.

The script will terminate when the client completes its connection. Then stop the server (ctrl + c) and kill it.

We will need to clear the TCP connection before we run it again. To do this, use the following command.

$ sudo fuser -k 5555/tcp # 5555 refers to your port number

🚨 Notes:

We can run only one PAIR at a time, this mean that we cannot have multiple clients, remember this is a PAIR, the first client will lock the socket.

If we run the server once, and the client twice, the second client will “hang”, this means that the second client it will wait for a new server to connect.

If we want to run the pair more than once, we will need to kill the server and clear the TCP connection.

PAIRs are ideal when a client needs to have exclusive access to a server.

We can have multiple servers to multiple clients as PAIRs, but we will need to use different PORT numbers for the connections.

Each phase is independent of each other, so, stop the server, clear the TCP ports, and move to the next phase.

Phase 2: Pairing a server to multiple clients

Let us create a client-server connection, where multiple clients will connect to a single server. This is the most popular messaging pattern.

Let’s create a server in the context of REP-REQ (reply to a request) pattern.
We will call the server rep-server.py, using port 5555.

import zmq
import time
try: # Try to create a new connection
    context = zmq.Context()
    socket = context.socket(zmq.REP) # We create a REP server
    # Here we set a linger period for the socket
    # Linger 0: no waiting period for new messages
    socket.setsockopt(zmq.LINGER, 0)
    socket.bind("tcp://<INTERNAL_VM_ADDRESS>:5555")
    while True: # Wait for next request from client
        message = socket.recv()
        print("Received request: ", message)
        time.sleep (1)  
        socket.send_string("Hi from Server")
except KeyboardInterrupt: # “ctr+c” to break and close the socket!
    context.destroy()
    socket.close()

Now we will develop two Clients that will be identical in terms of their functionality.

* **Client 1** will send a “Client 1 Hello world” request

* **Client 2** will send a “Client 2 Hello world” request to the server. 
* Let us create a file called `req-client1.py`, then edit as follows, again make sure you change the <INTERNAL_VM_ADDRESS>.

import zmq
import time
context = zmq.Context()
socket = context.socket(zmq.REQ) # We create a REQ client (REQUEST)
socket.setsockopt(zmq.LINGER, 0)
socket.connect("tcp://<INTERNAL_VM_ADDRESS>:5555")
for request in range (1,10):
    print("Sending request Client 1 ", request,"...")
    socket.send_string("Hello from client 1")
    message = socket.recv()
    print("Received reply ", request, "[", message, "]")
socket.close()
context.destroy()

Let us create a copy of this client and edit it accordingly. Run the following command to make a new copy.

$ cp req-client1.py req-client2.py

Then edit the req-client2.py and change client 1 to client 2.

Let's edit the print and socket messages (lines 8 and 9)

import zmq
import time
context = zmq.Context()
socket = context.socket(zmq.REQ) # We create a REQ client (REQUEST)
socket.setsockopt(zmq.LINGER, 0)
socket.connect("tcp://<INTERNAL_VM_ADDRESS>:5555")
for request in range (1,10):
    print("Sending request Client 2 ", request,"...")
        socket.send_string("Hello from client 2")
    message = socket.recv()
    print("Received reply ", request, "[", message, "]")
socket.close()
context.destroy()

To run this example, we will need three terminal windows, one for the server and two for the clients. Run the following in the first terminal.

Let's start the server

$ python3 rep-server.py

Let's start the first client

$ python3 req-client1.py

Let's start the second client

$ python3 req-client2.py

Check the output of the windows, we just created two clients talking to one server. You can have as many clients as you want, you will need to make clients, even with different functionalities that connect to one server.

🚨 Notes:

Client – Server is the most widely used pattern, we already used it in class 1 when we installed and ran the Apache HTTP server.

Stop the server and clean TCP port 5555

Kill the server:

bash $ sudo fuser -k 5555/tcp

Phase 3: Pairing a server to a client

The publish – subscribe pattern is a very common way to control broadcasting of data to many clients that are subscribed to a context, in a way that servers send data to one or more clients.

* To run multiple servers, we need to map each server to a PORT number.

* In this pattern, messages are published (broadcasted) without knowing that subscribers exist, or if there are any subscribers of this context. 

* It is the task of the subscribers to make connections and filter out the incoming data.

* We usually say: Subscribers, subscribe to a specific context.

Let us first create a simple example.

* We will create two servers that generate weather data, and one client that it is subscribed to both instances to collect data about a particular context:

* The context is: **Client will only “listen” the context related to New York City weather data (postal code 10001)**.

* The first instance of our server will run in port `5555`.

  * This instance generates a topic with an ID.

  * For testing purposes, the topic represents a postcode (in our example, that is a random value between 9999 and 10005).
  * Each time a topic is generated the server also generates weather data e.g., temperature, that actual forms our message.

* The second instance of our server will run in port `5556` and will provide the same functionality.

* This instance generates similar topics and messages. 

* **The assumption here is that both instances represent sensors that send weather data from various areas in different cities.**

* We will create the server code and make it easy to replicate, as you might noticed the only parameter to change is the PORT number.

Let us create a new file, call it pub_server.py.

* The server will accept two arguments from the command line, that will be the IP and the PORT value.
  * For accepting command line arguments we use the `sys` Python library.

* By this way we can run multiple servers, and each time we run the script we will just have to pass IP and PORT number as arguments to the code. For example:

$ python3 pub_server.py <internal-ip> <port>

This command will instruct python to run a server in specific and

import zmq
import random
import sys
import time
try:
    # Port value is the first argument from the command line
    ip = sys.argv[1]
    port = sys.argv[2]
    context = zmq.Context()
    socket = context.socket(zmq.PUB)
    socket.bind("tcp://"+ip+":"+port) 
    while True:
        # Topic is the post code, randomly generated 9999-10005
        topic = random.randrange(9999,10005)
        # Let us generate the message data (temperature)
        messagedata = random.randrange(1,215)-80
        # Print the data
        print("%d %d" % (topic, messagedata))
        socket.send_string("%d %d %d" % (topic, messagedata, int(port)))
         # Each sensor generates data each second
        time.sleep(1)
except KeyboardInterrupt:
    context.destroy()
    socket.close()

Create a new file pub_client.py.
* The script accepts three arguments from the command line (that are the IP and the two ports).

import sys, zmq
try:
    ip = sys.argv[1]
    port1 =  sys.argv[2] # Take port1 from command line
    port2 =  sys.argv[3] # Take port2 from command line
    context = zmq.Context()
    socket = context.socket(zmq.SUB)
    print("Collecting updates from weather servers...")
    socket.connect ("tcp://"+ip+":"+port1) 
    socket.connect ("tcp://"+ip+":"+port2)
    topicfilter = "10001"  # Subscribe to postal code e.g. NYC, 10001
    # Subscribe to topicfilter: 10001, WE CARE ONLY FOR NYC!
    socket.setsockopt_string(zmq.SUBSCRIBE, topicfilter)
    total_value = 0
    # Lets collect up to 5 subscriptions 
    # Then we will calculate the average of 5 temperatures from NYC
    for update_nbr in range (1,10):
        data = socket.recv()
        topic, messagedata,port = data.split()
        total_value += int(messagedata)
        print("Topic: '%s', message: '%d' on port '%d' "%
              (topic, int(messagedata), int(port)))
        print("Average messagedata value for topic '%s' was %dF" % 
                 (topicfilter, total_value / update_nbr))
except KeyboardInterrupt:
    context.destroy()
    socket.close()

We are ready to run our pub-sub application! We will need three terminal windows. In the first terminal run:

$ python3 pub_server.py <internal-ip> 5555

In the second terminal run:

$ python3 pub_server.py <internal-ip> 5556

Each server generates weather data. For example:
- The postal code, e.g.: 10001
- The temperate, e.g.: -68

Let’s run the client to connect and subscribe to data by postal code e.g., 10001 (NYC). Remember the client script subscribes to both server instances. Run the next command:

$ python3 pub_client.py <internal-ip> 5555 5556

When you finish kill the servers (ctrl+z) and clear the TCP ports running the next commands:

  $ sudo fuser -k 5555/tcp

  $ sudo fuser -k 5556/tcp

Phase 4: Push/Pull: Using a Pipeline pattern**

Push/Pull sockets let you distribute messages to multiple workers, arranged in a pipeline. This is very useful for running code in parallel. A Push socket will distribute messages to its Pull clients evenly, and the clients will send a response to another server, called collector.

This is equivalent to producer/consumer model, but the results computed by consumer are not sent upstream but downstream to another pull/consumer socket.
We will implement the following functionality.
The producer will PUSH random numbers from 0 to 10 to the consumers.
Two instances of the same consumer will PULL the numbers and will perform a heavy task.
The task could be any heavy calculation e.g., matrix multiplication.
For simplicity, our “heavy task” will just return the same number.
The consumers will PUSH the individual results (heavy task calculations) to a Result Collector, that will aggregate the results.
For simplicity, an instance of the Result Collector will PULL the results and calculate the partial sum of each consumer. We can easily sum the two partial sums if needed.
Let us see a simple example.
- Producer generates [1,2,3,4,5].
- Consumer 1 receives [2,4], then calculates a heavy task and forwards results to the Result Collector.
- Consumer 2 receives [1,3,5], then calculates a heavy task and forwards results to the Result Collector.
- The result collector calculates the counts and partial sums e.g.:
- Consumer1[2,4], this means 2 numbers received from Consumer1 and their sum is 6.
- Consumer2[1,3,5], that means 3 numbers received from this Consumer2 and their sum is 9.
This example demonstrates the potential of distributed processing for parallel processing.

Firstly, let us create the producer called producer.py running on port 5555 make sure you adapt your .

import time
import zmq
import random

def producer():
    mysum = 0
    context = zmq.Context()
    zmq_socket = context.socket(zmq.PUSH)
    zmq_socket.bind("tcp://<internal-ip>:5555") # UPDATE THE IP!
    # Generates 10 numbers
    for num in range(10):
        val = random.randint(1,5) # Random numbers: 1 to 5
        work_message = {'num' : val}
        zmq_socket.send_json(work_message)
        print(work_message)
        mysum = mysum+val
        time.sleep(1)
    return mysum

print(producer())

Then create the consumer.py is as follows. Do not forget to change the two s in code.

import time
import zmq
import random
def heavyTask(i):
    # Perform a heavy task
    # Here we can perform any heavy calculation e.g. i**100+i*200
    return i # For simplicity we return the same value...
def consumer():
    consumer_id = random.randrange(1,10005)
    print("I am consumer #%s" % (consumer_id))
    context = zmq.Context()
    # receive work from producer (port 5555)
    consumer_receiver = context.socket(zmq.PULL)
    # UPDATE THE IP!
    consumer_receiver.connect("tcp://<internal-ip>:5555")
    # send work to collector (port 5556)
    consumer_sender = context.socket(zmq.PUSH)
    # UPDATE THE IP!
    consumer_sender.connect("tcp://<internal-ip>:5556") 
    while True:
        work = consumer_receiver.recv_json()
        data = work['num']
        result = {'consumer' : consumer_id, 'num' : heavyTask(data)}
        print(result)
        consumer_sender.send_json(result)
consumer() # Run the consumer

Finally, let us develop the collector.py, again change the .

import zmq
import pprint
context = zmq.Context()
# Pull the results from port 5556 (consumers)
results_receiver = context.socket(zmq.PULL)
results_receiver.bind("tcp://<internal-ip>:5556") # UPDATE THE IP!
collecter_data = {}
data = {}
asum=0
for x in range(10):
   result = results_receiver.recv_json()
   print(result['num'])
   if result['consumer'] in collecter_data:
      # This is how to count and sum items in a dictionary...
      collecter_data[result['consumer']][0] = collecter_data[result['consumer']][0] + 1
      collecter_data[result['consumer']][1] = collecter_data[result['consumer']][1]+result['num']
   else:
      collecter_data[result['consumer']] = [1, result['num']]
pprint.pprint(collecter_data)

Make sure you don’t have an indentation error!

* Let us run it and examine how the pipeline works.

* We will need **four** terminal windows.

Firstly, we need to run the collector.py, the collector will be waiting for data to be collected until we start the producer.

$ python3 collector.py

Then, we will start the consumers one by one, run each command in a different terminal window.

$ python3 consumer.py

Run the same command in another terminal.

$ python3 consumer.py

Finally, we will start our producer that will start sending data to our pipeline.

$ python3 producer.py

Well done! 🏁 You used ZeroMQ to develop messaging patterns!

Forem: Stelios Sotiriadis

PR & GitHub Actions updates, now synced with Linear.

Visibility is the key!

What we built

A simple example

Easy setup

Getting started

Step 1: Connect Linear

Step 2: Activate Post Actions

Step 3: Work as Usual

Having trouble?

Warestack Does Not Stop Here!

How do you catch pretty much every bug before it hits prod?

⚡ Release Code Like a Pro ⚡

What agentic protection means?

What rules can I create?

Why this matters?

Wanna try it?

Agentic DevOps: The Future of Adaptive Governance

Enforce DevOps best practices and eliminate production errors!

These tools operate in isolation—they don’t share context.

The solution: Enforceable best practices

How can Warestack help you monitor and enforce best practices?

Step 1: Connect your tools

Step 2: Enable best practices to monitor

Step 3: Monitor violations

Example: Pull request review

Example: Deployment review

What’s Next for Warestack?

Do you like what we are building?

Automate GitHub operations with best-practices

Warestack: Manage every code change with best practices

How does Warestack work?

How to Get Started

Your overview page at a glance

Simplify issue management with best practices

Generate workflows with high standards

There are more!

Help us make it better!

Messaging in distributed systems using ZeroMQ

Messaging in distributed systems using ZeroMQ

Phase 1: Pairing a server to a client

Phase 2: Pairing a server to multiple clients

Phase 3: Pairing a server to a client

Phase 4: Push/Pull: Using a Pipeline pattern**

How does `Warestack` work?