Does a vertical slice mean a single merge request?



  • 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?



  • 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 https://en.wikipedia.org/wiki/INVEST_(mnemonic) . 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.




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2