1-Commit Per Pull Request Workflow

Software development workflow at Woovi

At Woovi we focus a lot on speed. To ensure speed while development code, we have a lot of automation set in place.
We use conditional build to make sure we only test and build what is needed, providing a fast feedback loop for our developers, Fast CI/CD for Monorepos
We split tests in many containers to make tests run even faster, Test Splitting in CI/CD.
We use domain driven design to decouple our code, DDD in Monorepos.
We have automated tests, feature flags, and we use continuous integration for our Git branching model, How to ship faster to production
We also don't have required code review,
What developers merge when nobody is looking
All these enable our developers to iterate faster with small commits and pull requests.
One developer can have more than 100 commits per day.

One Commit Per Pull Request Workflow

We are decoupling our monolithic architecture in well-defined domains in our monorepo, each domain has their own package with its public interface.
We are using codemods to help us move code from one package to another, this codemods can modify more than 100 files at the same time, but they are safe as we have many tests around them.
As we share the same monorepo, to avoid having git conflicts all the time, we work in small commits, usually 1 commit per pull request.

Here is how works in practice a workflow to change some code change in Woovi monorepo

• write your backend/frontend code
• manually test it once
• write automated tests to validate the code works as expected and handle know edge cases
• when done, get the latest version of main branch - git pull origin main
• create a new branch - git checkout feat/webhook
• add your code to git - git add .
• commit files - git commit -m "feat(webhook): awesome webhooks"
• open pull request - gh pr create --fill

This is Woovi 1-commit per pull request workflow

In Summary

At Woovi, we are crafting and rethinking every aspect of each process that affects our operational work. This tiny optimization does not make sense for small scale, but it payoffs a lot at scale

---

Woovi
Woovi is a Startup that enables shoppers to pay as they like. To make this possible, Woovi provides instant payment solutions for merchants to accept orders.

If you want to work with us, we are hiring!

Comments

[Myles]

While I understand the intent, it sounds like this should be used as a stepping stone to a trunk-based workflow. PRs are a useful tool for reviewing code, but it can slow up flow if you're constantly having to either find someone to review your PR or work through reviews of open PRs before you can pick up anything new. This is usually offset by the fact that it only happens once a day to once every few days for a given dev (sometimes even less if you're working on a spike), but this format doesn't have that economy of scale.

I think the next step for your team is to look at why you need PRs in your workflow and then see if there are other ways to approach it (e.g. pair/mob programming when you want a second pair of eyes).

[Raja Anbazhagan]

Some of our repos have CODEOWNERS configured to groups and we take review SLAs seriously (as every teams should). Also we have pipelines that validate tests, SCA, linting etc so the reviewer gets a heads-up.