DEV Community: Pavlo Maksymov

Pull Request Notification Automation

Pavlo Maksymov — Fri, 14 Mar 2025 14:41:39 +0000

TL;DR

Recently I've released a new version of my GitHub Pull Request Notification Bot and enabled it for the internal tech team in the company. The project manages Slack messages based on the GitHub Pull Request events. Over the last two weeks, it has worked perfectly for our team and saved some time for us.

In this article, I will share the details about the project and how it works.

Like it? Let's dive into the details.

Motivation

Automate or do things manually? The answer is always "Automate!", even if it is a small task.

In my team, we emphasize agile development and frequent releases. Code reviews are a key part of our workflow, and we actively use Slack for communication. As a result, it has become a daily routine for the author of a pull request (PR) to manually notify the team in a Slack channel and keep the message updated so others can easily see whether the PR needs review or has already been merged or closed.

So, I spent some time over the weekend building a simple application to automate it.

You might wonder why we don’t just use GitHub’s Slack integration. The reason is straightforward: it generates excessive noise by sending separate messages for every event. There’s no way to update messages, format them properly, or tag users, making it less effective for our needs.

Basic concept and functionality

In general, the application is a simple web server that listens to the GitHub webhooks posts messages to Slack, and creates as little noise as possible. At the same time, it must be flexible and configurable so every team can set up the application according to their needs.

Functionality:

Post a message to the Slack channel when a new PR is created.
Update message in the Slack channel when PR is merged or closed.
Delete message in the Slack channel when PR is moved from Ready for Review to Draft.
Post message to the Slack channel when PR is moved from Draft to Ready for Review.
Tag users or groups in the Slack message.
Multiple Slack channels.
Multiple GitHub repositories.
(Optional) Reactions to the messages in the Slack channel when the PR is merged or closed.

Application Details

As you can see on the schema above, the application requires having an SQLite database. You might ask "Why do you need a database?". The answer is "To keep Slack message ID for future updates". Another reason to have a database is to store the configuration for each repository and Slack channel.

Configuration

Take a look at the configuration item

+------------------+---------------+--------------------------------------+
| Repository       | Slack Channel | Mentions                             |
+------------------+---------------+--------------------------------------+
| owner/repository | C12312312111  | <@U08ENEE1ZPW>, <!subteam^S12312312> |
+------------------+---------------+--------------------------------------+

As you can see you can set up channel and mentions for each repository. This is quite useful when you have multiple teams, channels, and repositories.

To manage the configuration three cli commands were created:

gsm:write - to create or update the configuration to the database. The first argument (owner/repository) is used as an identifier. Example:
```
    php bin/console gsm:write owner/repository SLACK_CHANNEL_ID '<@USERID>,<!subteam^GROUPID>'
```
gsm:list - to list the configuration from the database. Example:
```
    php bin/console gsm:list
```
gsm:remove - to remove the configuration from the database. Example:
```
    php bin/console gsm:remove owner/repository
```

Note: the gsm abbreviation in the command stands for GitHub Slack Mapping.

In addition, via environment variables, you can enable/disable reactions and set the emojis for the reactions. Please, visit the configuration documentation for more details.

GitHub Webhook

To receive the GitHub events you need to set up the webhook in the GitHub repository settings. I described the GitHub Webhook registration process in the GitHub webhook registration article. Please note, that there is no need to send all the events, "Pull request" events are enough. The application will filter out all unnecessary events.

Slack Integration

To post messages to the Slack channel you need to create a Slack bot and get the token. The token should be set as an environment variable. You can find the detailed instructions here.

Use cases

Use case 1: A new PR is created.

The application posts a message to the Slack channel.
The application stores the message ID in the database and relates it to the repository and PR.

Use case 2: A new draft PR is created.

No action is taken.

Use case 3: PR is moved from "Draft" to "Ready for Review" state.

The application posts a message to the Slack channel.
The application stores the message ID in the database and relates it to the repository and PR.

Use case 4: PR is moved from "Ready for Review" to "Draft" state.

The application deletes the message in the Slack channel.
The application removes the message ID from the database.

Use case 5: PR is merged.

The application updates the message in the Slack channel with the "[Merged]" message prefix.
(optional) The application adds a reaction to the message.

Use case 6: PR is closed.

The application updates the message in the Slack channel with the "[Closed]" message prefix.
(optional) The application adds a reaction to the message.

How is it used in our team?

In my team, we have one team which consists of frontend and backend developers. Frontend developers work on the React application using a separate repository and backend developers work on the API application using another repository. For the sake of limiting the number of channels, we decided to use one channel for both repositories and tag the team members who maintain the repository.

After the bot application was set up I created configuration items in the database using the gsm:write command. Also, I registered a webhook in both repositories and invited the bot to the channel.

As a result when the frontend app repository has opened PR the message tags @fronend developers and if a PR is created in api app repository the @backend developers are tagged.

And this is the result overview of what we have now:

Conclusion

The application is super simple. It automated everyday routines and made team communication more effective.

If you found this project useful, please give it a star on GitHub and share it with your friends.

Please note that it's still under development, and I'm open to any suggestions or contributions.

Check out more articles on my blog.

Shades of Technical Debt

Pavlo Maksymov — Mon, 10 Feb 2025 10:59:01 +0000

TLDR;

Do you recognize yourself in the picture above? Or perhaps it's something new to you? Either way, this post is for you, regardless of your role in IT. Throughout my career, I've encountered Technical Debt numerous times, studied various approaches to managing it, and took part in the implementation of different solutions. Now, I'm eager to share these insights with you.

What is Technical Debt?

Technical Debt is a metaphor introduced by Ward Cunningham that compares the cost of development to the cost of borrowing money.
Continuing with the metaphor, we can split Technical Debt into two parts:

The Debt: The original money you borrowed. This includes all the important work you put off, such as refactoring existing code, updating dependencies, and updating documentation, in favor of delivering features faster.
The interest: The interest you pay on a loan that grows over time. This is the extra work you have to do now because of the Debt. It's harder to connect systems, data gets messy, and you need workarounds. This slows down delivery and costs more money.

Okay, so we understand the idea of Technical Debt. Let's summarize it using more Technical terms:

Technical Debt represents the future costs and complexity that result when we intentionally or unintentionally choose quick solutions over better-designed approaches to software development.

Shades of Technical Debt.

Reading the definition, you may ask what I mean by "intentional or unintentional"?
Well, sometimes we are not aware of possible Debt due to a lack of experience or knowledge. These two terms are mostly about awareness of debt.
Diving deeper into the shades of Technical Debt I want to refer to Martin Fowler's Technical Debt Quadrant,
we can see that it is divided into four sections: Deliberate (Intentional), Inadvertent (Unintentional), Reckless, and Prudent.

Let's break it down:

Reckless/Deliberate Debt happens when the team underestimates the consequences of the fast solution.

Reckless/Inadvertent Debt happens when the team is not aware of the Debt because of a lack of knowledge or experience.

Prudent/Deliberate Debt is when the team is aware of the Debt, and care about it.

Prudent/Inadvertent Debt is when the team is not aware of the Debt.

You might say, isn't Prudent/Inadvertent Debt is the same as Reckless/Inadvertent Debt? Well, not exactly.
The difference is that as soon as the Prudent team discovers unintentional Technical Debt, they take action to fix it,
whereas the Reckless team does not.

Continuing to learn about the shades of Technical Debt, let's discuss the areas in which Technical Debt can occur.

Code Debt: Represents poor coding practices, a lack of standardization, and outdated techniques. It hinders maintenance and scalability.
System Design Debt: Results from bad or outdated architecture or design, including overly complex designs, misuse of patterns, and lack of modularity. This Debt hinders scalability and adds new features.
Documentation Debt: Involves insufficient or outdated documentation, making it difficult for team members to understand the system and decision rationale, impacting maintenance and development efficiency.
Testing Debt: This occurs when there is insufficient testing, including unit tests, integration tests, and overall test coverage. This increases the risk of defects and bugs in production, leading to system failures and customer dissatisfaction.
Infrastructure Debt: Outdated servers, poor deployment practices, or lack of disaster recovery plans, leading to performance issues and downtime.
Technical Skills Debt: Results from lacking necessary skills or knowledge, leading to suboptimal solutions. Mitigate by investing in training and development.
Dependency Debt: Using outdated or unsupported libraries, frameworks, or tools, leading to security risks and integration issues.
Process Debt: Inefficient or outdated development processes, poor communication, lack of agile practices, and insufficient collaboration tools.
Skills Debt: Results from lacking necessary skills or knowledge, leading to suboptimal solutions. Provide training and development opportunities to shift your team from Reckless/Inadvertent to Prudent/Deliberate.

Another important shade of Technical Debt is the size of it. It can be small, medium, or large.

Small: easy to fix, usually takes up to few hours, rarely one day. The Boy Scout rule works well here: leave the code cleaner than you found it.
Medium: can be fixed by one sprint or during feature development that involves a part of the application or system that has tech Debt. This one requires more careful development cycle planning because the team needs to allocate time to update dependencies and improve code structures.
Large: To tackle this one, the team needs to plan way ahead because the solution may involve a complete system redesign or overhaul. A quarterly planning meeting is a good place to discuss such issues. Show the roadmap affected(slowed down) features, show how much time it takes to fix it, and how much time it will save in the future.

Why is it important to manage Technical Debt?

According to the McKinsey research, actively managing Technical Debt can free up engineers to spend up to 50% more
time on work that supports business goals. For instance, the CIO of a leading cloud provider noted that by reinventing
their Debt management, they reduced the time engineers spent addressing Technical Debt from 75% to 25%, significantly
enhancing their operational capabilities.

Stripe also researched this topic. Their report, The Developer Coefficient: Software engineering efficiency and its $3 trillion impact on global GDP, found that annual global GDP (Gross Domestic Product) losses from developer inefficiency amount to ~$300 billion. Impressive, isn't it?

Another important aspect is that Technical Debt is not spread evenly. Like a poorly maintained building, some parts of a system may be in excellent condition while others are falling apart. For example, core business logic might be well-structured and maintained, while supplementary features accumulate significant Debt. This uneven distribution makes it crucial to identify and prioritize areas where Technical Debt poses the greatest risk to system stability, maintainability, or business growth.

And the last thing that I'd like to mention is that Technical Debt accumulates interest over time. The longer you wait to address it, the more it will cost you in the future. It's like a snowball rolling down a hill, getting bigger and harder to stop.

How to deal with Technical Debt.

Here are some steps to help you manage Technical Debt:

Acknowledge and Identify Technical Debt.
This must be done at the business level, otherwise it will be hard to get resources to fix it. It is the responsibility of the team to communicate it to the business, clarify the impact, and propose solutions. Make sure you are using business terms when talking to the business. In this case metaphor of Technical Debt will serve you well here. Don't forget to add new terms to the company glossary so you speak the same language. If you don't have one, it is time to create one.
Measure and Prioritize.
Use metrics to quantify Technical Debt, such as code complexity, bug rates, performance bottlenecks, or business risk. Prioritize tasks based on their impact on system stability, performance, or business goals. If you require more specific tools try CodeScene or look for similar approaches.
Make Technical Debt Part of Engineering Work.
- General recommendations: Allocate time in every development cycle to address Technical Debt. Include Tech Debt tasks in the backlog and prioritize them alongside new features. Apply the Boys Scout rule: leave the code cleaner than you found it. Also, worth mentioning that regular code review and pair programming often prevent Technical Debt.
- Personal recommendations: There is no silver bullet here. You must adapt technical debt resolution to your development process. Many organizations run dedicated technical debt sprints, while others prefer setting aside one or two days every few weeks. Another approach is to include technical debt work in feature estimates. Alternatively, teams might track debt through special epic tickets or labels in their project management system. A few companies even use specialized tools for debt management. Find what works best for your team - there's no one-size-fits-all solution.
Automate and Improve Processes. Use tools for code quality analysis such as static analysis and linters, automated testing, and CI to have fast feedback and catch issues early.
Create a Sustainable Culture. Encourage a culture of continuous improvement, knowledge sharing, and collaboration. Invest in training and development to keep skills up to date and increase awareness of Technical Debt shifting the team from Reckless to Prudent.
Track Progress and Iterate. Regularly review and update Technical Debt metrics by organizing regular meetings to revisit previous progress and plan future improvements.

Conclusion.

In conclusion, Technical Debt is a common challenge in software development that can slow down delivery, increase costs, and limit innovation. If a team manages their Technical Debt, they can improve system stability, maintainability, and overall productivity. It's essential to be aware of Technical Debt, measure and handle it, make it part of engineering work, and track progress over time.

References.

Enjoying this content? Visit My Blog to explore more insights and ideas!

Learning a New Language with Advent of Code

Pavlo Maksymov — Mon, 02 Dec 2024 13:48:45 +0000

Are you looking for a fun and challenging way to sharpen your coding skills or learn something new? This article is about leveraging Advent of Code, a popular annual programming event, to begin the journey of learning a new programming language.

Learning is crucial for everyone in the IT world. Development is no exception to this rule. Every line of code we write and every error we debug helps us improve, yet there’s always more to learn—and that’s what makes this process so rewarding.

Last year I mastered Golang, this year, I decided to learn Java. There’s something exciting about diving into something new, and discovering what a language has to offer. But where to start? In my opinion, the best way is to start with the Advent of Code.

If you’ve never heard of Advent of Code, let me introduce you to one of the most engaging ways to level up your coding skills. Advent of Code is a series of daily programming puzzles that run from December 1st to December 25th. Each day unlocks a new challenge, and trust me, they’re as fun as they are amazing. These puzzles are designed for everyone — from beginners learning their first loops to seasoned engineers looking to flex their problem-solving muscles. Learn more about it here.

I'm writing this article on the 2nd of December, just completed the first challenge of Advent of Code 2024. If you are interested it is high time to start your journey. To start your challenge visit the Day 1 page.

The beauty of Advent of Code is that it meets you where you are. Want to learn a new language? Great! Want to focus on optimization, and algorithm design, or just have some festive fun with code? It’s perfect for that too.

Some personal tips for those who are just starting their journey with Advent of Code:

Don't use AI to solve puzzles. Cheating leads to nothing.
Do not google the solution. It is better to spend a couple of hours solving the puzzle than to copy the solution. And again, cheating leads to nothing.
Reserve a couple of hours each day to solve the puzzle.
Google basic things about the syntax or read the official documentation if you are stuck.
It is ok if you can't solve the puzzle. The main goal is to learn something new. You can always come back to the puzzle later.

So, here’s my plan: 25 days, 25 puzzles, and 25 chances to improve my Java skills. Let’s see how much I grow by the time Christmas arrives. If you’re participating too, I’ll see you on the leaderboards. Let’s make this December a month of learning, one puzzle at a time!

🌟 Let’s code 💻, let’s learn 📚, and let’s grow 🌱. 🚀