---
title: "Public Cloud Learning Sessions (OpenText)- Product Hub (PHT) Overview and Q&A - 20240806 170251-Meeting Recording"
type: cloud-learning
source-type: video
category: "DevOps & SRE/10_OpenText-Series"
tags:
  - Product-Hub
  - PHT
  - OpenText
date-added: 2026-04-14
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/Public Cloud Learning Sessions (OpenText)- Product Hub (PHT) Overview and Q&A - 20240806_170251-Meeting Recording.mp4"
audio-source: ""
status: summarized (Gemini 摘要)
---

# Public Cloud Learning Sessions (OpenText)- Product Hub (PHT) Overview and Q&A - 20240806 170251-Meeting Recording

**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/Public Cloud Learning Sessions (OpenText)- Product Hub (PHT) Overview and Q&A - 20240806_170251-Meeting Recording.mp4`

**Type:** VIDEO | **Category:** 10_OpenText-Series

**Status:** 🟡 Awaiting Whisper transcription → Summary

---

## Product Hub (PhD) Overview and Q&A

The session provides an overview of the Product Hub (PhD), also known as the Product Hierarchy Tracker. PhD gathers product-related information, driven by product or development managers. It stores official products and their divisions, including business units and lines of business, differing from master products in the official product naming registry.

A product is a software distribution with its own CI/CD pipeline or release cycle. *A product may also be part of another parent product, but if that particular product has its own cycle, like its own CACD pipeline or its own distribution, then we may treat that particular component or module as a product in PhD.* Each product consists of metadata like attributes, source reports, artifact reports, and user information, integrated into external applications like PSMQ, P2M, ITLS, and Backstage. Components are libraries without CI/CD pipelines and may or may not be part of a product. If a component needs ITLS review or scanning, it should be created as a product.

PhD has hierarchy levels: business units, lines of business, and products. Business units have engineering and PM leaders, while lines of business have owners and PM leaders. Products are managed by product and development managers and relate to a master product. Requesting a new product is a self-serve process; after submission, it goes to LOB approval, where the line of business owner reviews it. Active products have regular releases; maintenance mode indicates only hotfixes or bug fixes, and inactive means no releases. Product information includes business unit, line of business, product name, product manager, development manager, and status. Attributes store metadata like alternate names, build advocates, and release gate mechanisms (e.g., P2M). Source and artifact repos are mapped for source control permissions, managed through PhD. Related products and components specify relationships, with source repo permissions shared to child products with read-only access.

PhD integrates with applications like Jira, Value Edge, PSMQ, and OSS. Source repo creation in GitLab takes 24 hours to reflect in PhD, and empty groups/repositories cannot be searched. Artifact repo permissions are enabled for new structures. For product name/status changes, contact erphd@opentext.com; for technical questions, contact aangetoolsupport@opentext.com. The demo covered filtering products, hierarchy levels (business units, lines of business, master products, products), and creating new products. *Requesting for a new product is a self-serve process.* The process includes filling in BU, LOB, product name, and manager information. Attributes like release gate mechanism are mandatory. Source repos and artifact repos can be mapped, with source repo ownership taken by the product. Dependencies can be specified, and product teams/guests can be mapped for access control. Teams can be created with engineering (right access) or moderator (maintainer access) types. Components are created by role managers and do not have CI/CD pipelines or approval processes.
