Supporting typical change scenarios: new feature, defect fix, dependency update, release

Why such a scenario is needed

Even within a single project, changes differ in meaning and risk. A new feature, a defect fix, a dependency update, and a release should not go through the same route without distinction. If the pipeline and change processing rules do not account for the context of the trigger, the team either overloads a simple scenario with unnecessary steps or, conversely, does not sufficiently verify higher-risk changes.

In this scenario, GitFlic is used so that the same engineering contour supports different typical routes:

it reacts differently to a new commit, a merge request, and a tag-triggered run;
it takes into account which branch the pipeline is associated with;
it runs the necessary stages and jobs depending on the type of change;
it remains understandable to the team, even if there are multiple scenarios.

Who this is especially useful for

One process — different trigger points

The basis of this scenario is that the pipeline is viewed not as a single immutable route, but as a mechanism that behaves differently depending on the trigger source. In GitFlic, this is especially evident already at the manual trigger point: a pipeline can be tied either to a branch or to a tag.

Further, the process logic is determined by exactly which type of change is passing through the repository: a regular commit to a working branch, a merge request, delivery to the main branch, or a version release by tag. Therefore, the goal of this article is not to list all CI/CD settings, but to show how one common process is divided into several typical engineering routes.

Scenario 1. New feature

A new feature is typically characterized by the longest and most complete verification route: changes first live in a working branch, then undergo building and testing, after which they enter a merge request and continue through review rules and mandatory checks.

The practical meaning of this route is that a new feature almost always affects more code, has a greater impact on system behavior, and more often requires a full verification cycle. Therefore, for such a scenario, the goal is not to accelerate merging at all costs, but to ensure a complete and managed path for the changes.

For details on managed integration via merge requests, see the article Managed change integration via merge requests.
For details on automating building, testing, and publishing results, see the article Automation of building, testing, and publishing results via CI/CD.

Scenario 2. Defect fix

A defect fix typically requires a shorter and more operational route, but this does not mean abandoning manageability. On the contrary, the more urgent the change, the more important it is that the process does not turn into a set of manual decisions.

For such a scenario, the pipeline can use the same common contour, but with a clearer priority: quickly build the change, perform mandatory checks, conduct the merge request according to specified rules, and, if necessary, verify the integration result before reaching the main branch.

For details on integration predictability and mandatory pre-merge checks, see the article Improving release predictability and integration quality.

Scenario 3. Dependency update

A dependency update often looks like a simple change, but in fact carries a separate type of risk: the change may not directly affect business logic, but can impact the build, compatibility, library behavior, and the stability of subsequent releases.

For such a scenario, it is especially important that the team does not make a decision "by eye", but sees the verification result in the normal engineering flow:

whether the build passes correctly;
whether tests break;
whether behavior changes during the integration stage;
whether the current route is sufficient or the change requires stricter approval.

This is precisely why a dependency update in GitFlic should go through the same managed contour, and not be perceived as a "minor technicality" that can be merged without the common process.

For details on publishing verification results and artifacts, see the article Automation of building, testing, and publishing results via CI/CD.
For details on delivery automation and intermediate environments, see the article Reducing manual operations in the delivery (deployment) pipeline.

Scenario 4. Release

A release differs from the previous scenarios in that not only the next pipeline run is important, but also the formalization of the version itself. At this stage, the trigger point becomes a tag, and the process changes its meaning: now the team needs not only to verify the changes, but also to formalize the release as a separate result.

For this scenario, it is useful to view the release route as a separate branch of the common process: the code is already prepared, verified, and approved, after which a tag-triggered run or a tag-associated release formalizes the final version as a completed result.

For details on version pinning, tags, and formalizing a release, see the article Forming a reproducible release contour.

How routes differ depending on the trigger

To avoid mixing typical scenarios, it is important to maintain a simple logic:

a new commit triggers the normal technical verification cycle;
a merge request transitions the change into a managed integration route;
a tag-triggered run links the process to a version release;
the branch context determines which additional stages and jobs should be included.

This means that the same repository supports not one "universal" pipeline, but several understandable working routes within a common engineering model. As a result, the process remains unified but does not become overly rigid and identical for all types of changes.

What the team and business gain

Supporting typical scenarios provides several practical effects:

a new feature goes through a complete verification route without manually complicating the process;
a defect fix can be carried out faster without leaving the managed contour;
dependency updates are evaluated based on actual technical results, not on an assumption of "low risk";
a release trigger becomes a separate and understandable route;
the team works not with a set of disparate exceptions, but with a predictable map of typical changes.