The Codacity Great
Software Delivery Pipeline

We start solving problems by recognizing that software engineering is not just about architecting great products to run in production. It is also about architecting delivery pipelines, comprising of people, processes, and tools, that ensure these great products can be delivered and remain great over time.

Our software delivery pipeline represents a lean factory that is built for:

  • Early Feedback
  • Small, Predictable Releases
  • Facilitation and Collaboration
One Trunk or two?

All our projects follow a trunk-based model, where new development is done on a single trunk. “Bug fix-only” branches may exist for production, and perhaps a branch soon to be released if the test cycle is long.  

Feature branching is not a continuous process

Compare that to the standard approach done the world over where features are delivered using the branching technique (below)
Feature branching is a sign that the feature under development is too large to be delivered in one sprint (or maybe even project), and so is broken up by dev team. This creates the need to merge those features back into the main trunk that will cause regressions, as any manual testing needs to be redone. The size of such merges create potential risks given their size. Regressions slow down delivery and create potential conflicts in the source code version control.

Codacity’ s take

At Codacity we hold the view that large features are a sign of lack of domain understanding which if estimated will lead to inconsistent team velocity and schedule slippage. We follow the INVEST model for defining scope and our product managers will groom the backlog to ensure we deliver to our commitment. Unlike most of our peers, our Agile process will not slow you down.