# Integration strategy for Numaris/X

## Use cases

**Integration and Feedback:** (PR gate)
As a developer, I want an automated process to merge changes from my short-lived branch to the main branch, triggering comprehensive system tests for immediate feedback on the entire application's functionality.

**Pre-Integration Testing:**
As a developer, I need a robust pre-integration test suite to validate and ensure the stability of our team's changes before merging them into the main branch, preventing disruptive updates for other developers.

**Bug Fix Integration:**
As a developer, I aim to resolve reported issues from the main branch's install base by promptly fixing bugs and selectively applying these fixes to relevant release branches, maintaining stability across versions.

**Code Quality Checks:**
As a developer, I require an automated code quality assessment tool integrated into our workflow to enforce predefined coding standards and ensure compliance before any code merges into the main branch.

**Testing Feedback:**
As a developer, I seek automated and prompt feedback through a comprehensive suite of unit and integration tests for my code changes, enabling a quicker and more efficient approval process.

**Code Reviewer Requirements:**
As a code reviewer, I need a comprehensive report comprising static code analysis results, unit test outcomes, and integration test results to validate and approve code changes before merging into the main branch.

**Work in Progress Development:**
As an Idea developer, I require a designated environment to develop and experiment with work-in-progress (WIP) packages exclusively for research and experimental purposes.

**Platform Integration Workflow:**
As an IDP developer, I seek an automated process that integrates changes from the Num/X platform immediately upon availability of a new D&A release, without direct merging to the main branch but ensuring synchronization with my platform.

**Local Testing for Platform Integration:**
As a developer, I need tools and documentation to conduct local tests for platform integration, enabling verification of bug fixes from the n/s platform to resolve issues within my platform's context.

**Release Versioning:**
As a Project Lead, I require clear guidelines and procedures to tag Git commits for releases, ensuring distinct versioning for V&V and customer releases, promoting better management and traceability.

**Stay in Sync with Main Branch:**
As a developer, I need reminders and automated checks to ensure continuous synchronization with the main branch, reducing the likelihood of conflicts during code merges.

**Branch Management and Deletion:**
As a developer, I suggest establishing specific lifecycles for branches, setting timeframes for feature and fix/bug-related branches to prevent accumulation of untracked or stale branches, promoting a clean repository structure.

**Ability to Rollback Changes:**
As a developer, I require a well-defined process or toolset to facilitate the rollback of changes on the integration/main branch when necessary, ensuring quick recovery from problematic updates.

Other corner cases:

**Bypass**
As a developer, in urgent and time critical scenarios, I should be able to bypass gate check violations after due approvals so that we can fix and test the problems immediately

## Requirements from the feature

- We want that our main branch has a very high quality. It should be so high that we can install bays from it, without wasting expensive bays because of bugs
- We want a fast reverse integration duration from the feature-branches to main
- We want frequent reverse integrations from the feature branches to main (~ every 24h to 48h)
- We want a simple integration model, easy do understand
- We want a fast pull request from the feature branch to the main branch (direct main?)
- We don't want to revert / rollback changes from many developers because of a problem introduced by changes of a single developer
- We don't want to create difficult situations where developers have to push own changes again because of problems of other developers
- We don't want a difficult integration process where we have to develop own scripts/tools

### Thoughts - Ajay

- What is the current use case for bypass checkin in the current system?
- We need to define mechanism/criteria for promoting commits from dev branch to main and from release branches to main and Dev.
- Do we need to think of end-of-life for a release branch. (Branching strategy and LTA?)
- Enforce squash commit?
- Current system: Team branches -> Gated build -> Nightly build -> Release pipeline with FIT -> RI to River. How do we bring this level of quality checks to the GIT world where everyone commits to dev branch? (PR build that does all this? How do we control pr build duration?)
- Lock primary builds (e.g. River.Night) from being triggered from non primary branches (e.g. feature branch)

## Remarks of Andreas

- Stick with the standard format of a user story. This is easier to read.
- Num/X developer => developer for brevity. IDP is about NUMARIS/X only (at least at the moment...)
- We should define our standard personas for user stories => let's talk with Stefan

Now for the content:

As a developer
I want to integrate changes from my shortlived branch to main
so that I can get faster feedback by running whole system tests.

As a developer
I want to test my/our team changes before integrating to main
so that I can avoid breaking changes passed to all developers.

**I would object to this:** As a Num/X developer, I would like to perform bug fix changes for the problems reported from the install base on the main branch so that I can cherry pick these changes to release branches

Why? Because it is already included in the above user stories and it indicates the bad practice of continuing development on release branches. There should actually be no release branches. Only release tags on main.

As a developer
I want to have quality gates
So that my code is checked against standard code quality measures before merged to main.

As a developer
I want to receive feedback for my code changes with unit and integration tests before code changes are approved.

**I would object to this:** As a Num/X Code reviewer, I would like to get static code analysis feedback, unit and integration test feedback before approving the changes to be merged to main

Why? Because as a code reviewer I expect that the results of static code analysis, unit and integration test have already been automatically checked by the gate build. Possible exception where manual inspection is required: have the sufficient integration tests been executed?

As an Idea developer
I want to develop WIP packages for research purpose.

As a developer
I want to perform n/s platform integration to Num/X as soon as a new release is avaialable from D&A without merging to changes to main.

**I would object to that:** As a Num/X developer, I would to perform a local test for n/s platform integration so that I can verify if bug fixes from n/s platform solves MR problem or not

Why? Because the test does not have to be local, it can and should be on the server, but on your short-lived integration branch. I can use the same short-lived-branch integration mechanisms as everyone else.

As a Project Lead
I want to mark a git commit for a release to V&V and also for customer release.

**Objection:** As a Num/X developer, Maintain a clear versioning strategy. Each release branch can have its own version number or tag.

Why? We will not have release branches.

As a developer
I want to stay in sync with main branch all the time
so that I can avoid merge conflicts when integrating.

We need to think more about this:

Let's keep specific time/days for a branch. If it's regarding a feature give them more time to build a feature from that feature, if it's a some kind of fix/bug related let's give it less days and then proceed with merge or deletion. In this way we can avoid unwanted and stale branches. Since Branches are lightweight in git people will create branches and forget about tracking it and in the end we will have 1000's of branches which are untracked and unwanted.

I am hesitant to put up complex rules about branch life cycles. They will be worked around anyway.

But: we definitely need an automated process to clean up stale branches.