They Use Mergify: Pepperize

Mathieu Poissard 07 Dec 2023

Every day, many projects use Mergify to automate their GitHub workflow. Independently of their team size, the one thing they all have in common is that the project leads are willing to let their developers focus on what's important—code. So, we decided to meet with some of them to learn more about their challenges and discover how Mergify helps them be more efficient regarding pull requests. This time, we talked to Patrick Florek and Andreas Forster, founders, maintainers and main contributors to the Pepperize project.

Can You Tell Us more About You and your Project?

We are software developers, working as independant consultants in a variety of different companies. We are do a lot of AWS development in our daily life. Unfortunately, we have observed that it can be really hard and time-consuming for companies to get started with AWS.

We first met at TUI a couple of years ago. At the time we were working on an application and it would have profited having Redis in it. To get it, we had to apply for the setup of Redis on one of the virtual machines. It took more than one and a half years, and nothing happened.

We were therefor very happy when the TUI decided to transition from on premise to the cloud and to use AWS. With AWS we would be able to add infrastructure ourselves.

As with a lot of other on-premise companies, software development and server operations were located in separate teams. Each team lacked the skills the other team had, but to transition to the cloud you should ideally have DevOps teams with both skill-sets. Building the necessary skill-set in an existing teams while still maintaining the legacy setup is challenging. Obviously, it would have been great to have had some expert help to jump-start the cloud transition.

We then founded Pepperize with the aim to help companies to get to the cloud faster and easier.

For our projects we use the AWS CDK to define our infrastructure with Typescript. CDK also also has language bindings for other languages, e.g. Python, Java, Go etc. CDK is a generator of .yaml configuration files for the AWS CloudFormation service. When I discovered this, I said to myself that we couldn't not use CDK. Deploying infrastructure via CDK saves development time. The other great thing about CDK is that you can organize your infrastructures as constructs. Constructs bundle common infrastructure definitions that you can reuse or share between projects as common packages.

And that's what we make available to our users via Pepperize.

Are You Alone on this Project?

We are the founders of the project, and most of the work on Pepperize is done by two of us.

It's still a small, human-scale project.

But it depends on which Constructs you are talking about.

Not all Constructs are created equal, and some are more widely used than others. In all, there are around ten projects.But I'm often the top contributor.

Most people will use what we develop, but they're not active contributors. On average, we should have 2 or 3 contributors a month, at most. They are users who need a particular feature and develop it themselves.

Generally speaking, our users are more likely to spot a gap and create an issue waiting for us to work on it.

In fact, this is because we only cover edge use cases. That the main project - called Projen - doesn't address. It's quicker and easier to manage these cases outside the main project via shared Community Constructs.

What Were your Pain Points?

As part of this project, we need to update our dependencies with certain libraries on a regular basis. The Javascript and Typescript ecosystems are evolving very rapidly. So we have to update them continuously.

We update them on a daily basis, which may be a little overkill given the size of the project. A weekly or even monthly update would probably be sufficient. In the meantime, Dependabot generates a lot of pull requests to merge on a daily basis. Between 50 and 100 monthly, for each project. That's a lot. And Mergify handles and merge them automatically.

Not only that, but the Merge Queue ensures that all our projects are always up. As soon as a pull request is approved, we know it will be rebased, tested and merged if all the checks pass.

In concrete terms, Mergify improves our productivity and allows us to concentrate on engineering and development rather than monitoring the work of one or the other. We work in the same way, and we trust each other, so approving Pull Requests goes quickly, and then Mergify automates the rest of the work right up to the merge.

Can You Tell Us more about How You Found Mergify?

Launching a project is clearly not a problem for us: all you need to do is define a good dependency management system, write a read.me and off you go. On the other hand, when there are two, three, four or five projects running in parallel with a dedicated repo. Or multiple micro-services in a large project, each with its own repo. It gets complicated. And that's where you need something resembling a repository generator, or a project skeleton, a standard. This is what CDK and Constructs allow you to do.

In the CDK ecosystem, some of the core developers have launched a project to not only generate a skeleton, but also a generator to maintain the project's configuration and maintain dependencies. It's called projen - for Project Generator.

And on the projen project, one of the developers had installed and integrated Mergify as a part of the configuration. That's how we discovered Mergify and we started to use it.

Was It Easy to Setup?

In the beginning, we used Mergify but didn't configure it ourselves.

We went through projen, which had installed and configured it. Mergify is automatically installed on projects generated with projen.

When we needed to modify the configuration, I opened an issue with the projen managers or I made a pull request to ask for a modification in the Mergify configuration.

It was a great collaborative experience, but it wasn't the most efficient way to go about it.

We then took Mergify in hand ourselves and installed it on all our projects. Very quickly and easily.

Did Mergify Help You with your Pain Points?

Of course, Mergify is helping us a lot with this project.

As explained earlier, Mergify automates a large number of rather tedious tasks. This frees up our time to devote to more interesting tasks.

What's more, Mergify ensures that all our projects are always up to date with their dependencies.

I also use Mergify to spot new bugs. For example, when I see that the queue is filling up abnormally and that many pull requests are being blocked: that's my personal alarm. I know it's a recent problem, probably due to an update to the CDK ecosystem. I then take the time to track down the bug and open a new issue.

To put it simply, Mergify lets us keep the number of pull requests linked to dependencies at zero. And if this is not the case, it means that an update has introduced a bug or a breakage.

What Is the Main Benefit of Mergify?

We no longer need to interact with pull requests or GitHub. So I can concentrate on what I want to do.

Without Mergify, we'd have to change the way we work and our workflow. Without the Dependabot and Mergify alliance, once a month I'd have to work only on dependency updates.

On top of that, I can see which dependency updates are likely to cause problems, so I can anticipate them. It helps us a lot.