Does a vertical slice mean a single merge request?

Question

Let's suppose we're talking about the microservices architecture. And let's say that after refinement, we ended up with a feature (vertical slice) that implies making changes in two microservices - is it common?

Further, we can NOT deliver such a feature in a single merge request because two repositories are involved. So we need to break the feature into two tasks (and two merge requests in two repositories) which by themselves don't necessarily have business value and do not represent User Stories. When should we commit acceptance test then?

Or do we need to do this differently?

Answer 1

It feels like there's a (potentially well intended) motivation to set how development and architecture should work based on agility principles.

As well meant as it could be, the way the question is framed it implies this may not be working. I'll approach the technical aspects (merge, commit, pull request, repo) from engineering perspective. The "agility" part is explained separately (and in this way I hope you have enough context to evaluate it with different audiences you might be working with).

TL;DR: Do not try to standardise development practices solely based on agility aspects. Or if you do, make sure you have the inputs from a senior developer that consider such practices will help, not hamper, the development practices.

Why it may not work from Engineering perspective

One of the greatest advantages of microservices architecture is that it arranges an application as a collection of loosely-coupled services. It is not a problem per se to have a feature spanning across several microservices. The problem is trying to couple them into a single commit. It may lead to a gigantic pull request, and may often not even be possible (due to repo restriction).

The feature should be built considering the needs in both microservices, but each of them should be able to build, release and run independently.

Why it may not be giving the expected agility in your process

You're implying that one User Story -> one repo -> one PR -> (potentially) one commit. That may be the start of the problem.

I'll take a wild guess: you may be start to experimenting with a framework like SAFe? If that's the case, you might want to read again what SAFe says about Features - the key aspects to observe, which might not be aligned with your deliverable, are:

• Features are visible ‘units’ of business intent that the customer recognizes, and it’s at this level of detail that the customer is able to prioritize their needs.
• Features may span multiple user roles, stories and use cases.

TL;DR: You have a User Story disguised as a Feature.

Answer 2

TL;DR

You're conflating engineering and architectural domains (and especially source code management tooling) with business and project management concerns. There's no direct mapping between product increments and merge requests, especially in large or complex systems.

Think of a vertical slice as the thinnest piece of coherent, full-stack, multi-layered functionality you can produce as a product increment and you'll be closer the intent. You'll also find very thin vertical slices easier to deliver if you divorce that what from the how of it.

Analysis and Recommendations

Does a vertical slice mean a single merge request?

No. A vertical slice is usually a process or business objective that crosses multiple segments or layers of a product while still meeting INVEST criteria. For example, a microservices-based feature might involve small increments that affect multiple services (each of which might or might not have its own source code repository) as well as touching multiple functions or layer within each service.

Furthermore, from a project management perspective, whether a story or feature is implemented through a squashed merge request in a monolithic repository, 518 tiny commits that are fast-forwarded onto a single Git branch, or cherry-picking commits into multiple branches or repositories are strictly engineering and team-workflow concerns. In fact, if the team decides to transfer the code by semaphore to be chiseled onto stone tablets in a remote location is entirely irrelevant to the question of whether that code represents a thin vertical slice or not.

Trying to map agile notions like story points into units of time, or vertical slicing into tool-constrained views of what constitutes a feature or task, is always a project implementation smell. It's whiffy because the conceptual mapping is fundamentally misguided. A task is not intrinsically a source code commit, a merge request, or even a service implementation. A task is simply something you need to do that's on the critical path to delivering a cohesive increment of the product.

In Scrum, your Sprint Goal is your cohesive increment. In DevOps, your development-to-production delivery of a successful change is your cohesive increment. Cohesive doesn't mean monolithic, though, so discard the faulty mapping you've created between merge requests and stories/features. Instead, focus on how you will demonstrate the cohesive increment, regardless of how many moving parts it has.