Frequent Internal Release

The main objective of frequent internal deliveries is to provide early and frequent (e.g. sprint-based, monthly, quarterly) deliveries to internal stakeholders to gain early feedback on delivered functionality before it is brought to market.

Examples of internal stakeholders include Divisions, R&D teams within and outside of the development stream, Sales enablement, demo system setups, STT, etc. Another objective is to enable the independent release of components (component packages) so they can be bundled and included in one or more product releases (e.g. used in different product lines).

Principles

• Ensure committed release scope is distributed to the component package level
• Ensure component packages are owned by an agile team
• Establish component packages' internal release scope and plans
• Ensure component package can be independently, and internally released
• Ensure a test strategy for the component/product exists
• Ensure continuous integration and automated integration testing
• Ensure high data discipline is in place
• Ensure internal release criteria are met to release a component

Frequent Internal Release concept

• The project/product external release scope agreed upon and committed at G2 is distributed to and further refined on the component package level
• During development, components are developed, tested and continuously integrated (as often as possible) into the CI environment and tested there (Product Integration & Test)
• Once functionality development is completed, the component can be claimed as “ready” to be released
• Fulfilling defined Internal Release Criteria and obtaining approval via Internal Release Meeting allows a given component to be released internally to the preview environment and then eventually picked up by the project, bundled, and included in a project/product external release at G4 (or optionally at G3), later on, tested by STT (including RAT), and finally (after fulfilling release and gate criteria) released to the market

Note: gates are business-oriented checkpoints that involve formal decision-making to evaluate the project's value, while milestones are progress-oriented checkpoints that track the completion of specific deliverables or phases without interrupting the development flow.

Supporting and related processes

• SW Development – as described in Software Development Process
• Product Test – as described in Product Test Overview
• Continuous Integration (CI) and Product Integration & Test (PIT) – as described below in this document
• Internal Release Meeting – covering criteria and ceremonies around qualification of a deliverable (component) for internal release - as described below in this document

Detailed implementation and any deviations/tailoring from general QMS Processes referenced in this process will be described in Quality Plan documents.

Continuous Integration (CI) & Product Integration & Test (PIT)

Software developed by the agile teams is continuously integrated into a running system for continuous validation. This enables the team to build-in quality and get fast feedback on the integrated work, achieving a fast, reliable, and sustainable development pace. Continuous integration also means the system is always potentially deployable. Integration happens on multiple levels, from the component level (team level) to functional and non-functional product tests (PIT), and integration of the whole system (SIT/STT).

The figure below explains the scope, responsibilities and a variety of tests in the overall test strategy:

• In-development tests (like unit testing, module testing, component testing, etc.) are part of the Development Process and described in the Software Development Process and are the responsibility of a Development Team. Fulfillment of in-development tests is being tracked via completing defined DoD for work items.

• Product Tests (including PIT) are part of the Test Process and are described in the Product Test Overview. Completion of Product Tests is essential to qualify software (component package) for an Internal Release. The following areas/types of tests should be completed:

• Installation and deployment

• Performance & capacity testing

• UI testing

• Functional testing

• Regression testing (including smoke tests)

• Exploratory testing (optional)

• Product Integration & Test (PIT)

The Product Test Team is responsible for Product Testing. Fulfillment is tracked via results and reports provided and qualified during the Internal Release Meeting.

• System Integration Testing (SIT) and System Type Testing (STT) are part of the Test Process and are described in System Test Overview, and are the responsibility of the System Test Team. Fulfillment is being tracked via results and reports provided at Gate meetings.

Internal Release Criteria

• Work items status: All pull requests approved, features and their user stories/tasks are closed, demo performed (if planned)
• Test status: All planned tests completed (according to the agreed Test Strategy) and results provided (Test Report), this may include Unit tests, component tests, Product Integration Tests (PIT), etc.
• Bugs status: Must have criteria is to have no critical or high bugs open. An exception can be made for not closed high bugs, which should be accepted by CCB and documented in (internal) release notes (workaround exists) and planned to be fixed in the following increment.
  • The ultimate goal that teams should strive for is to have 0 bugs related to the delivered features. Product Owners should take the decision to fix the bug (fix now) or decide to never fix it (close/won`t fix).
    In case there is no agreement between PO and bug submitter, the given bug shoudl be brought to CCB to decide.
• CyberSec status:
  • All code scanning including SAST, and DAST (SonarQube, Trivy, meta defender, etc.) completed and results were verified by the team
  • Black duck hub scan (or similar – dependency bot) completed. Identified risks reviewed and application approved
  • Pre-DSAC executed with findings documented and accepted. (extended with DSAC tools)
  • MCSR reviewed and approved
• 3rd Party – updates done in DFN
• Export Control Classification
• Documentation status:
  • Internal release notes created for the component, including known issues, new functionality etc.
  • Internal communication package ready (including installation instructions, location of software, etc)
  • End user documents/manuals (drafts) updated and reviewed by PO and Documentation Lead
  • Design/architecture documented

Internal Release Meeting

Role	Description	RACI
Release Owners	Process/meeting driving & coordination	R
Product Owners(s)	Responsible for delivering component/application together with required artefacts (DoD, Test report, RN, etc.)	R
Stream Owner/Sub-Stream Lead	Process owner/Decision Maker	A
Product Manager	Main receiver of the process/delivered functionality	C
Divisions, other Teams Reps	Potential receivers interested in delivered functionality	I
Quality Control Manager	Process/quality control/compliance	C
Test Lead	Testing area expert	C
CyberSec Engineer	(Optional) CyberSec area expert	C
Configuration Manager	(Optional) Configuration management area expert	C
CST	(Optional) Customer Success Team expert	C
Documentation Lead	Documentation area specialist	C
Other Functions	(Optional) Consulted/informed if needed	I

Artifacts

Artifact​	Description​	RACI	Receiver​	Comment
Component release plan	Shows the component release plans at least for current PI	(R): Product Owner (A): Stream Owner​ (C): - (I): -	Release Owner	-
OSS Scan & Clearance Report	OSS Clearance report from Black Duck Hub	(R): Product Owner (A): Stream Owner​ (C): - (I): -	Release Owner	-
Beta build / SW integrated in Preview environment	Beta media or software integrated in Preview environment	(R): Product Owner (A): Stream Owner​ (C): - (I): -	PPM	-
Security Report	MCSR activities completed	(R): Product Owner (A): Stream Owner​ (C): - (I): -	Release Owner	-
Release Notes	Internal Release Notes	(R): Product Owner (A): Stream Owner​ (C): - (I): -	PPM	-
Draft User Documents	User Documents ready of internal use	(R): Product Owner (A): Stream Owner​ (C): Documentation Lead (I): -	PPM	-
Component / Product Test Report	Consolidation of all test results, including all levels of test prior to CIT	(R): Product Owner (A): Stream Owner​ (C): Test Lead (I): -	Release Owner	-
CIT Test Report	Report of CIT (Continuous Integration Tests) test results	(R): Test Lead (A): Stream Owner​ (C): - (I): -	Release Owner	-
3rd-party SW List	Updated 3rd-party SW List in DFN tool	(R): Product Owner (A): Stream Owner​ (C): - (I): -	Release Owner	-
Design/architecture docs	Details the high-level design and describes the component structure with modules and classes as well as internal/external interfaces.	(R): Development Team (A): Product Owner ​ (C): Architect (I): -	Development Team	-

References

• Release
• Software Development
• Test
• Quality & KPIs
• Roles

Related

• R&D Quality Criteria