T&T Release Standard

Version: 1, effective date: 06-Jun-2022

Aleksandr Illarionov

---

Contents

• 1 Standard description

• 2 Document objectives and benefits

  • 2.1 Objectives
  • 2.2 Benefits

• 3 Definitions

• 4 Roles & Responsibilities

• 5 Release standard

  • 5.1 Source code branch model
  • 5.2 Release notes
  • 5.3 DevOps pipelines implementation
  • 5.4 Build pipeline
  • 5.5 Testing Pipeline
  • 5.6 Deployment pipeline
  • 5.7 Quality Gates
  • 5.8 Release testing
  • 5.9 Deployment approval

• 6 PROD deployment planning

• 7 Standard Owner

• 8 Document Control

  • 8.1 Contact Person
  • 8.2 Revision History

• 9 References

1 Standard description

This document will define the release standard of T&T business applications.

2 Document objectives and benefits

2.1 Objectives

The objective of this document is the definition of requirements to release planning and implementation processes.

2.2 Benefits

• Increase transparency of the release process
• Define release stages and approvers

3 Definitions

Abbreviation / Term	Explanation
T&T	Track and Trace
Release	Process of management, planning, scheduling, and controlling application on every stage and environment.

Please refer to IT Glossary in the IT P&P portal for further definitions.

4 Roles & Responsibilities

Accountable: Approves the activity or recommendations from a person or team.

Responsible: Responsible to do the work associated with an activity, either by completing personally or through sole accountability for a team’s output.

Consulted: Reviews the output of an activity and provides input, but has no approval authority. Provides support to activity and may be consulted by the team during the course of the activity.

Informed: Is informed about activities to aid in planning own work.

#	Activity	GDC TTDC	BTS T&T	TA
1	Define and maintain Standard	A / R	C	I
2	Apply the Standard in the T&T Implementation projects	A / R	C	I

5 Release standard

5.1 Source code branch model

Source code branches creating according to the application release plan. A branch created for a new release: “release/”, e.g.: “release/2.1”.

New code should be pushed to “feature/…” branch and then merged into the release branch via pull request.

5.2 Release notes

In case of changes in the application, leading to changes in DevOps pipeline or security model, release notes should be provided for the corresponding application version.

5.3 DevOps pipelines implementation

DevOps team implementing Build, Testing and Deployment pipelines according to application documentation. Changes in documentation or release notes may cause additional activities from DevOps team side. In this case, the release of the application should be planned according to these activities.

5.4 Build pipeline

Build pipeline used to build sources, does necessary source code checks, and publish artifacts for further deployments. After the build version of application is extended to build number (e.g. 2.1.1).

5.5 Testing Pipeline

Testing pipeline used to deploy artifacts to testing environments (QA, UAT, PrePROD etc.). In scope of testing pipeline, QA Team approves or refuses the successful pass of automated and manual tests for artifact.

5.6 Deployment pipeline

Deployment pipeline is used to deploy artifacts to each application environment. Depending on quantity of PROD environments might be separated into multiple pipelines to operate with different environments.

5.7 Quality Gates

Before publishing artifacts via build pipeline, source code should successfully pass quality gates. Level of code quality requirements should be determined by IT owner of specific application.

5.8 Release testing

Each release should pass testing (according T&T Testing Standard) performed by Testing team. Deployment pipeline should not go to the next steps until each type of testing is done:

• QA

• UAT

• Performance

5.9 Deployment approval

Application deployment to each environment should be approved by a required person. Depending on the environment type list of approval persons:

Environment	Approvers
DEV	- Development team
QA	- Testing team
PrePROD/Staging/UAT	- Testing team - IT owner
Single (Global) PROD	- IT owner - Business owner
Factory (Local) PROD	- IT owner - Business owner - Factory local IT owner

6 PROD deployment planning

Each PROD deployment should be managed by the IT owner.

Corresponding CHG in ITSP should be managed according to JTI deployment standards.

7 Standard Owner

This standard is owned by GDC TTDC.

8 Document Control

8.1 Contact Person

Questions and feedback regarding this standard should be submitted to Aleksandr Illarionov

8.2 Revision History

Version	Effective date	Purpose of change	Author
1	06-Jun-2022	First version of the document	Aleksandr Illarionov

9 References

• Change management policy: Policy: Change Management (10.017)

• Azure DevOps Release Management standard: Standard: Azure DevOps Release Management (10.166)

• T&T Testing Standard: SYS006 Testing Standard

ANY QUESTIONS?

ASK TEAM