Example materials
For materials related to this use case, see umodel_and_codes.zip.
Note: The following architecture and implementation methods are examples. Adjust and optimize them based on your business needs.
Design principles
1. Business-oriented
-
Center the entity design on actual DevOps business flows to ensure it reflects real-world scenarios.
-
Support end-to-end business flow tracking and analysis.
-
Focus on problem-solving. Ensure key business information is searchable and available.
2. Scalability
-
Design entity fields to accommodate future expansion.
-
Support adaptation for different technology stacks and toolchains.
-
Reserve extension fields to avoid frequent schema changes.
3. Standardization
-
Follow UModel design specifications and best practices.
-
Maintain naming and structure styles consistent with existing application performance management (APM) and K8s domains.
-
Ensure that field types and constraints are appropriate.
Low-level entity design
1. Developer entity (devops.developer)
Business background
Developers are core participants in the DevOps flow, handling code development, system maintenance, and troubleshooting. This entity clarifies accountability and makes issue resolution more efficient.
Field design
|
Field name |
Type |
Required |
Filterable |
Sortable |
Description |
Business value |
|
work_no |
string |
Yes |
Yes |
Yes |
Employee ID |
A unique identifier that serves as the primary key and connects to the corporate personnel system. |
|
name |
string |
Yes |
Yes |
Yes |
Developer name |
Identifies personnel at a glance. |
|
|
string |
Yes |
Yes |
Yes |
Email address |
A contact channel used for alert notifications. |
|
team |
string |
Yes |
Yes |
Yes |
Team name |
Enables team-level collaboration analysis and management. |
|
role |
string |
Yes |
Yes |
Yes |
Role |
Used for role and responsibility analysis, such as developer, tester, or O&M. |
|
department |
string |
Yes |
Yes |
Yes |
Department |
Used for organizational structure analysis and tracking cross-department collaboration. |
2. Code repository entity (devops.code_repository)
Business background
A code repository is central to source code management, tracking a project's technical implementation and history. This entity enables centralized management of code assets and traceability from services back to their source.
Field design
|
Field name |
Type |
Required |
Filterable |
Sortable |
Description |
Business value |
|
repo_id |
string |
Yes |
Yes |
Yes |
Repository ID |
A unique identifier that serves as the primary key. |
|
repo_name |
string |
Yes |
Yes |
Yes |
Repository name |
The business identifier for the repository, which usually corresponds to the project name. |
|
repo_url |
string |
Yes |
Yes |
Yes |
Repository URL |
The endpoint for accessing code. Supports multiple Git protocols. |
|
git_provider |
string |
Yes |
Yes |
Yes |
Git provider |
The Git service provider, such as GitLab or GitHub. |
|
language |
string |
Yes |
Yes |
Yes |
Programming language |
The main programming language, used for technology stack analysis. |
|
framework |
string |
Yes |
Yes |
Yes |
Technology framework |
The technology framework used, such as Spring or React. |
|
description |
string |
No |
No |
No |
Repository description |
Describes the repository's purpose for easier management. |
|
default_branch |
string |
Yes |
Yes |
Yes |
Default branch |
The name of the default branch, which is usually main or master. |
3. Code release entity (devops.code_release)
Business background
A code release records the process of transforming source code into a deployable artifact, serving as the key link between development and O&M. This entity enables version management, change tracking, and rollback analysis.
Field design
|
Field name |
Type |
Required |
Filterable |
Sortable |
Description |
Business value |
|
release_id |
string |
Yes |
Yes |
Yes |
Release ID |
A unique identifier that serves as the primary key. |
|
repo_id |
string |
Yes |
Yes |
Yes |
Repository ID |
Associates with a specific code repository. |
|
repo_name |
string |
Yes |
Yes |
Yes |
Repository name |
The repository name for easy identification. |
|
tag |
string |
Yes |
Yes |
Yes |
Release tag |
A version identifier that supports semantic versioning. |
|
commit_sha |
string |
Yes |
Yes |
Yes |
Commit SHA |
The Git commit hash for precise code change location. |
|
release_notes |
string |
No |
No |
No |
Release notes |
A detailed description of the changes in the release. |
|
release_time |
timestamp |
Yes |
Yes |
Yes |
Release time |
Enables version management and analysis based on time. |
|
status |
string |
Yes |
Yes |
Yes |
Release status |
The status of the release, such as success, failed, or pending. |
|
release_type |
string |
Yes |
Yes |
Yes |
Release type |
The type of release, such as major, minor, or patch. |
|
author |
string |
Yes |
Yes |
Yes |
Publisher |
The person who performed the release operation. |
4. Image repository entity (devops.image_registry)
Business background
An image repository is a central hub for storing and distributing container images, handling image security, version management, and access control. This entity enables unified management of image assets.
Field design
|
Field name |
Type |
Required |
Filterable |
Sortable |
Description |
Business value |
|
registry_id |
string |
Yes |
Yes |
Yes |
Repository ID |
A unique identifier that serves as the primary key. |
|
registry_name |
string |
Yes |
Yes |
Yes |
Repository name |
The business identifier for the repository, used for management and identification. |
|
registry_url |
string |
Yes |
Yes |
Yes |
Repository address |
The network address for accessing images. |
|
registry_type |
string |
Yes |
Yes |
Yes |
Repository type |
The category of the repository, such as Harbor, ACR, or ECR. |
|
provider |
string |
Yes |
Yes |
Yes |
Repository provider |
The service provider for the image repository. |
|
region |
string |
Yes |
Yes |
Yes |
Region |
The geographical region where the image repository is located. |
|
description |
string |
No |
No |
No |
Repository description |
Describes the repository's purpose for easier management. |
|
is_public |
boolean |
Yes |
Yes |
Yes |
Is public |
The access permission setting for the repository. |
5. Container image entity (devops.image)
Business background
A container image is the basic unit for deploying applications, containing the complete runtime environment and dependencies. This entity provides full traceability from code build to container deployment.
Field design
|
Field name |
Type |
Required |
Filterable |
Sortable |
Description |
Business value |
|
image_id |
string |
Yes |
Yes |
Yes |
Image ID |
A unique identifier that serves as the primary key. |
|
image_name |
string |
Yes |
Yes |
Yes |
Image name |
The business identifier for the image, which usually corresponds to the application name. |
|
image_tag |
string |
Yes |
Yes |
Yes |
Image tag |
A version identifier that supports multi-version management. |
|
image_digest |
string |
Yes |
Yes |
Yes |
Image digest |
The SHA-256 hash, which ensures image integrity. |
|
registry_id |
string |
Yes |
Yes |
Yes |
Repository ID |
Associates with a specific image repository. |
|
full_image_name |
string |
Yes |
Yes |
Yes |
Full image name |
The full image name, including the repository address. |
|
build_time |
timestamp |
Yes |
Yes |
Yes |
Build time |
A record of when the image was built. |
|
size |
long |
Yes |
Yes |
Yes |
Image size |
The size of the image file, used for storage optimization analysis. |
|
architecture |
string |
Yes |
Yes |
Yes |
Architecture |
The CPU architecture, such as amd64 or arm64. |
|
os |
string |
Yes |
Yes |
Yes |
Operating system |
The base operating system, such as Linux or Windows. |
|
build_status |
string |
Yes |
Yes |
Yes |
Build status |
The build status, such as success, failed, or building. |
Entity relationship design
Core relationship types
|
Relationship type |
Semantic meaning |
Typical scenario |
|
manages |
Management relationship |
Accountability, access control |
|
sourced_from |
Source relationship |
Change tracking, impact analysis |
|
uses |
Usage relationship |
Dependency analysis, risk assessment |
|
contains |
Containment relationship |
Resource inclusion, version management |
Principles for selecting relationship types
-
Clear semantics: The relationship type name clearly expresses its business meaning.
-
Directionality: Define the direction of each relationship to support directed graph analysis.
-
Consistency: Keep relationship types consistent across different domains.
-
Extensibility: Allow for the addition of new relationship types.
Internal relationships in the DevOps domain
-
A developer manages a code repository (devops.developer_manages_devops.code_repository).
Business value:
-
Clear accountability: Quickly locate the owner of a code repository.
-
Permission management: Assign permissions based on the management relationship.
-
Workload analysis: Analyze the number and complexity of repositories managed by a developer.
-
A developer manages an image repository (devops.developer_manages_devops.image_registry).
Business value:
-
O&M responsibility: Clarify the O&M owner for the image repository.
-
Security management: Configure security policies based on the management relationship.
-
Resource optimization: Support resource allocation optimization based on the owner.
3. A code release is sourced from a code repository (devops.code_release_sourced_from_devops.code_repository).
Business value:
-
Version traceability: Quickly locate the source code for a release version.
-
Change analysis: Analyze the impact of code changes on a release.
-
Quality tracking: Track quality end-to-end, from source code to release.
4. An image is sourced from a code release (devops.image_sourced_from_devops.code_release).
Business value:
-
Image traceability: Trace a container image back to a specific code change.
-
Security tracking: Quickly locate the impact scope of a security vulnerability.
-
Rollback decisions: Formulate rollback strategies based on code change history.
-
An image repository contains an image (devops.image_registry_contains_devops.image).
Business value:
-
Resource location: Quickly find the storage location of an image.
-
Capacity management: Analyze the storage usage of each repository.
-
Access control: Manage permissions based on the storage location.
Cross-domain relationship design
Integration with the K8s domain
-
A pod uses an image (k8s.pod_uses_devops.image)
-
A deployment uses an image (k8s.deployment_uses_devops.image)
-
A StatefulSet uses an image (k8s.statefulset_uses_devops.image)
-
A DaemonSet uses an image (k8s.daemonset_uses_devops.image)
Business value:
-
Deployment tracking: Quickly locate the image version used by a K8s workload.
-
Update analysis: Analyze the impact of image updates on K8s workloads.
-
Rollback support: Roll back K8s workloads based on the image version.
Integration with the APM domain
-
A service is sourced from a code repository (apm.service_sourced_from_devops.code_repository)
-
A service is sourced from a code release (apm.service_sourced_from_devops.code_release)
-
Developer Management Service (devops.developer_manages_apm.service)
Business value:
-
Issue location: Quickly trace a performance issue to its source code.
-
Team collaboration: Connect the data views of O&M and developer teams.
-
Accountability: Clarify the owner responsible for service issues.
-
Alert routing: Route alert notifications based on the management relationship.