Track and Trace DevOps Standard
Version: 1, effective date: 04-Oct-2021
Contents
1 Standard Description
This document will define the standard approach to DevOps of T&T business applications.
Check list:
-
Planning process defined
-
Code storage/collaboration defined
-
Environment defined
-
Build process defined
-
Testing process defined
-
Artifacts storing defined
-
Deployment process defined
2 Document Objectives and Benefits
2.1 Objectives
The objective of this document is to uniform customization of development, testing, and deployment processes for applications.
2.2 Benefits
-
Reduce the time from the beginning of development to implementation (time-to-market)
-
Increase transparency and predictability of process steps
-
Define control points and areas of responsibility
-
Automate application deployment as much as possible
3 Definitions
T&T – Track & trace
DevOps – Development and Operations
Please refer to IT P&P portal search page for more 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 an activity and may be consulted by 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 DevOps Practices
5.1 Scope of DevOps
In the T&T DevOps covers:
-
Provision of tools for task planning
-
Provision of tools for developer’s collaboration
-
Organization of environment
-
Automate application build
-
Providing platform for testing
-
Store application artifacts
-
Automate deployment
5.2 Tasks Planning
Agile model is used for scheduling tasks.
5.2.1 Task Creation
Recommended but not limited to use the following types of task:
5.2.1.1 Epic
Something so big it probably won’t fit into a sprint, is not clearly understood in terms of customer requirements, and should be broken down into stories.
Usually defined during initial product roadmapping and decomposed into stories in the product backlog as more is learned.
5.2.1.2 Story (Feature)
Something actionable and small enough to fit in a sprint.
Usually created throughout product development, more so leading up to iteration planning and also during higher level product roadmapping.
5.2.1.3 Task
Decomposed parts of a story that get into how the story will be completed
Can be hour estimated if desired.
Usually defined by the people doing the work (developers, QA, etc)
5.2.2 Sprint Running
Team chooses stories from backlog for implementation in the sprint on the eve of the start.
In the process of spring, work performers mark statuses of tasks.
At the end of sprint all unfinished tasks moved to next sprint or backlog.
Recommended to do backlog grooming and team retrospective after sprint.
5.3 Code Storage/Collaboration
GIT version control system is used to store source code.
A source code workflow is used to enable developers to collaborate.
Source code (include libraries) should be enough to build, deploy and run application.
Interaction between developers, analysts and testers is carried out through the status of tasks.
Code connects to tasks for status tracking and overall progress.
5.4 Environment
Different sets of environments can be used depending on the complexity of the application, the number of participants and the needs for the tasks.
It is necessary to choose the configuration of the environment in such a way as to perform the necessary and sufficient verification measures on it to make sure that the application meets all the requirements set for it.
Minimum recommended set: QA and PROD.
5.5 Build
During the build process of the application, various checks are carried out:
-
No errors / warnings
-
Static code analysis
-
Level of coverage with unit-tests and success of their passing
Level of unit-test coverage should be at least 80%.
The build can be triggered manually or by event.
At the end of the building process, artifacts are formed, which are enough for deployment to environments and run on it.
5.6 Artifacts Store
Artifacts ready for deployment should be kept for a specified time which can be changed by application and defined in application implementation document.
It is required to keep minimum two previous versions.
5.7 Testing
Testing is part of the DevOps process with the responsibility of the testing team by Testing Standards.
All applicable types of tests should be included in pipeline.
Recommended to automate tests as much as possible.
Test results should be linked with build and artifact.
5.8 Deployment
Deployment is the installation of an artifact to a specific environment.
Each environment (or specific part of environment) may have its own person in charge, who can confirm the start of the deployment.
According to the pipeline, deployment is carried out sequentially between environments with executing of certain actions in each environment.
All necessary deployment and application run actions should be carried out automatically.
It should also be possible to manually rerun the deployment.
Order of release deployment must follow Azure DevOps Release Management standard (10.166)
6 Standard Owner
Provide here information about the role who owns the standard
7 Document Control
7.1 Contact Person
Questions and feedback regarding this standard should be submitted to the Illarionov, Aleksandr
7.2 Revision History
| Version | Effective date | Purpose of change | Author |
|---|---|---|---|
| 1 | 04-Oct-2021 | First version of the document | Aleksandr Illarionov |
8 References
- Azure DevOps Release Management standard: Standard: Azure DevOps Release Management (10.166)
- Testing Standards: Testing Standards
ANY QUESTIONS?