---
# System prepended metadata

title: New release model discussion

---

# New release model discussion

## Date: 18.08.2023
## Participants
* Schor, Stefan <stefan.schor@siemens-healthineers.com>
* Hofmann, Matthias <matthias.mh.hofmann@siemens-healthineers.com>
* Wübbe, Marcus <marcus.wuebbe@siemens-healthineers.com>
* Menon, Ajaykumar <ajaykumar.menon@siemens-healthineers.com>
* Dederer, Christian <christian.dederer@siemens-healthineers.com>
* Frömel, Florian <florian.froemel@siemens-healthineers.com>
* Bajpai, Shashwat <shashwat.bajpai@siemens-healthineers.com>
* Mikone Nanay, Erzsebet (ADV D EU HU OPS 5 SOL 3) (EXT) <erzsebet.mikone-nanay@evosoft.com>
* M, Manohar <manohar.m@siemens-healthineers.com>

---
* Fabisch, Tobias <tobias.fabisch@siemens-healthineers.com>
* Markl, Josef <markl.josef@siemens-healthineers.com>
* Salzer, Martin <martin.salzer@siemens-healthineers.com>
* Wang, Xiao Gao <xiaogao.wang@siemens-healthineers.com>
* Zhou, Jie <jie.jz.zhou@siemens-healthineers.com>
* Biro, Laszlo Attila <laszloattila.biro.ext@siemens-healthineers.com>
* Paroczi, Patrik <patrik.paroczi.ext@siemens-healthineers.com>


## High level thoughts

- Scaling
  - Application development which depends on field-strength, system types, ...
  - Hardware near SW which depends on concrete systwem types, platform, ...
  - Collect images needed for FDA submission
  
- Feature Freeze
  - R&D and stakeholders asseses during the feature freeze discussion the assumed feature content of the whole installed base.
  - Goal: One feature set for the whole installed base 
  - We want to asses was has really have been achieved, if something does not work,
    we want to move it to the next major version
  - It is understood that we trade a common feature set across our portfolio higher than to be fast as possible.
  - There are always features which are dedicated to specific system types / field strenths.
    They are not really scaled to the whole portfolio.
    Sometimes there are pure SW features which should be used for one system
    (e.g. Smart-UI with eMeRge)
  - The scaling of features would lead for some teams to reduced number of new innovations.
    (1 innovation for the whole portfolio vs 2 innovations for just a part of the portfolio)
  
- How do we plan to collect feedback frequently? Will we've user base categorization - Collaboration sites?
  - There is currently no plan to a increased collobaration (more updates, ...)
  - It is of interest, but not on short notice

- How are service packs/service helps addressed who dont have latest software updated?
  - The RM has a yearly cadence. This should also be the default for bug fixes for customer.
    Do we need to be faster than this cadence?
  - We can reuse a step 4 as bug-fix (aka service pack) for the systems of step 1
    (but the time between is very short)
  - the VB20A build does support a operation mode VB10 so that this version can be released as `NFJ` as VB10B (service pack for VB10A)
  - Worst Case: Create a service pack like today (Service Pack M300 on the release branch of e.g. VB10A Step 1)
  - Maybe there are improvements related to security patches possible, but maybe we stick to the current solution of deliver patches for the 90 day Security Deliveries 


- Is there an architectural acceptance to take modularization on priority?
    - Backward compatibility becomes more important with the new release model
    - Prove/Optimize V&V that we not changed code for xxx if we scaled for yyy.
      => Modularization can help to reduce V&V and Test-For-Regression efforts by the simple fact that one module has not been changed at all 

- Will customers accept the update frequency?
    - Sometimes customers are waiting for new desired freatures (e.g. deep resolve)
    - But this will not be true for every customer
        => we have to invest in customer communication (advantages, ...)
        => we have to invest in faster and more stable updates

- Business model should change over the time
    - Every customer should get a software for free (bug fixes) but without extra customer features
    - Advance-Now customer should get the software for free but also new customer value
    - The difference between both must be clarified
    - This approach would reduce the preassure to create service packs of a long period of time.


## What do we expect to be changed on day-day basis for IDP teams?

- Many more branches (short-lived)
    - Many more builds - not well known team branches like today
    - More full release pipelines executed for those branches
    - One River night build with one release pipeline will change to multiple "full" builds per day and 3-4 releaes pipelines for those full builds
- Support shift-left activities - frequent performance tests, stability tests
  - More and more tests will be developed which creates pressure towards IDP to be still fast with our builds
- Infastructure scaling should just be limited by the hardware budget, not engineers
- Evolve IDP to handle complete devops infinity loop (long term)
- Maybe we investigate solutions where not always all tests are executed


## What enablers (features) are required in the train?

- Invest for infrastructure as code
  - Make maintaining of the infrastructure cheaper (more automation)
  
- Maybe we need tools to understand the changes between two versions of the mainline to derive which parts of V&V must be repeated
  
- Enable Monitoring of our infrastructure to proactivly improve 
  (e.g. more machines required, build becomes slower, ...)
  
- Invest in faster error investigations
  (e.g. code change the reason for a build problem or an infrastructure problem (e.g. license server))

- Drop handling must be improved
  (more dev branches leads to a lot of binaries on the drop, how to get the binaries removed?, ...)
  
- Monitor how long branches are active. 

- Starting with VB20A, each build needs to be tested with two operation modes:
  VB10 and VB20
  
  In worst case;
  Three operation modes: VB10, VB20 and VB30 => Three release pipelines

  How do we support special long-term devleopment like Michelson?

- Build inside of containers
    - Easier side-by-side support of different compiler verisons
    - Easier to maintain
    - Will be installed on demand, as required vs pre-installed globally
   

## What enablers (features) are required in other trains (e.g. other teams must contribute)?


## What else is required (non-features – e.g. how we do something, …)?

- Complete transition to git has also consequences for non-develoeprs:
  Example: The cs number on formal documents. Maybe the PDP has templates with a change-set number in it
  
- Trainings needs to be organized
    - How we use git with Numaris
      (focus for our specialities like test-data, big repo, tools, ...)
    - Feature Toggle handling -> Architecture Team

- Foster the change towards smaller and short-lived branches. Merge smaller batches.

- How to detect flaky tests (e.g. fit tests)?
  Who is monitoring a FIT test across all branches?
  
- General approach how to handle flaky tests
  (isolation, ...)
 
 