3.3 KiB
title, type, source-type, category, tags, date-added, video-source, audio-source, status
| title | type | source-type | category | tags | date-added | video-source | audio-source | status | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Public Cloud Learning Sessions (OpenText) - GitHub Enterprise to GitLab migration - 20240625 170052-Meeting Recording | cloud-learning | video | DevOps & SRE/10_OpenText-Series |
|
2026-04-14 | nas:///volume2/work/Public Cloud Learning Sessions/Public Cloud Learning Sessions (OpenText) - GitHub Enterprise to GitLab migration - 20240625_170052-Meeting Recording.mp4 | summarized (Gemini 摘要) |
Public Cloud Learning Sessions (OpenText) - GitHub Enterprise to GitLab migration - 20240625 170052-Meeting Recording
Source: NAS /volume2/work/Public Cloud Learning Sessions/Public Cloud Learning Sessions (OpenText) - GitHub Enterprise to GitLab migration - 20240625_170052-Meeting Recording.mp4
Type: VIDEO | Category: 10_OpenText-Series
Status: 🟡 Awaiting Whisper transcription → Summary
GitHub Enterprise to GitLab Migration
The session covers the migration of source code from GitHub Enterprise to GitLab, driven by the company's decision to standardize on GitLab as the golden standard for source control. The GitHub license is expiring at the end of December, with no intention to renew, while the GitLab license covers up to 8,500 users. The migration approach is self-serve, with teams defining their needs and transforming their pipelines, with assistance from the Build Hub team when needed.
Key points include:
- Project Thor aims to integrate micro-focus and open-text tooling, with GitLab as the centralized system for source control.
- The Build Hub team manages central tools like GitLab and provides support for software delivery pipelines.
- Each team will define what they have in GitHub today, how they're using it, and they will plan to move it and change their pipelines.
- Definition of done includes code migration, pipeline transformation, and updating PHT (Product Hub platform).
- Permissions for source repos in GitLab will be controlled by PHT, allowing self-service access management.
- Personal repos are allowed in GitLab but should not contain product source code and will not be mapped in PHT.
Migration approaches include mirroring (synchronizing GitHub repo to GitLab) and shift and lift (copying code to GitLab and transforming pipelines). Tracking will be done via PHT, with regular updates to dev managers and build advocates. Planning guidelines include inventorying GitHub assets, identifying pipelines, and understanding network connectivity.
A significant challenge is the service account standard, requiring service accounts to be linked to a person, with expiring passwords. Other standards include repo naming conventions and segregation of duties. Network connectivity challenges were addressed by creating a GitLab proxy in Brook Park, accessible through SD1. The current solution that is working and is efficient and is actually reporting to scale. Commercial instances connecting to GitLab may require an exception from the GIS team.
Implementation steps involve installing GitLab plugins, getting early access to GitLab, mapping repos to PHT, setting up service accounts, and updating pipelines. The session also touched on the importance of testing network connectivity before planning the migration.