Update nexus: fix conflicts and sync local changes
This commit is contained in:
Shen Wei
@@ -1,62 +1,62 @@
|
||||
---
|
||||
title: "CTP Topic 15 Working with Renovatebot"
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/06_CI_CD_GitOps"
|
||||
tags:
|
||||
- Renovatebot
|
||||
- Dependency-Update
|
||||
- GitOps
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 15_ Working with Renovatebot.mp4"
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 15 Working with Renovatebot
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 15_ Working with Renovatebot.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** ✅ 已完成（Gemini 摘要）
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 本次会议由 Paul Hopkins 主讲，核心围绕如何利用 **Renovate Bot** 自动化管理云原生基础设施中的依赖项更新。在复杂的云架构中，依赖项无处不在，包括 Docker 基础镜像、Maven 依赖、Terraform 模块、Kubernetes Helm Charts 等。Paul 指出，团队在维护大量基于 Gruntwork 的 Terraform 模块和 Terragrunt 配置时，面临着手动更新版本号耗时耗力且极易滞后的挑战。
|
||||
|
||||
> 为了解决这一“依赖地狱”问题，团队引入了 Renovate Bot。该工具能够实时扫描代码库，识别过时的版本标签（Semantic Versioning），并自动发起拉取请求（Pull Request）。Paul 详细展示了 Renovate 的核心功能，如 **Dependency Dashboard**（依赖仪表板），它能在一个 GitHub Issue 中列出所有待更新的项，提供全局视角。在实施层面，团队通过在仓库中配置 `renovate.json` 文件来定义管理策略，并支持 Terraform、Terragrunt、Docker 以及 pre-commit 钩子等多种技术栈。
|
||||
|
||||
> 目前，该方案已集成到 Jenkins 流水线中，虽然在初期遇到了 GitHub Enterprise 适配及 Jenkins 处理大量并发 PR 的性能瓶颈，但通过本地 Podman 容器化运行和合理的速率限制（Rate Limiting）配置，团队成功实现了依赖更新的自动化与标准化。这不仅提升了基础设施的安全性（及时修复漏洞），也确保了开发环境与生产环境配置的一致性。
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
- **Renovate Bot**: 一款开源的依赖自动化更新工具，通过扫描代码并自动提交 PR 来保持依赖项处于最新状态。
|
||||
- **Dependency Management**: 依赖管理，指对项目中引用的外部库、模块或镜像的版本进行跟踪、更新和维护的过程。
|
||||
- **Terragrunt**: 一个 Terraform 的轻量级封装层，用于处理多环境配置、减少重复代码（DRY）并管理远程状态。
|
||||
- **Semantic Versioning (SemVer)**: 语义化版本控制，通常采用 `主版本号.次版本号.修订号` 的格式，Renovate 依据此规则判断更新级别。
|
||||
- **Dependency Dashboard**: Renovate 在 GitHub 仓库中自动创建的一个 Issue，用于汇总所有依赖状态、待处理的 PR 以及更新选项。
|
||||
- **Managers**: Renovate 中的插件机制，用于识别和处理特定类型的依赖文件（如 `terraform` 经理处理 `.tf` 文件，`dockerfile` 经理处理镜像标签）。
|
||||
- **Rate Limiting**: 速率限制，为了防止自动化工具瞬间产生过多 PR 导致 CI/CD 系统崩溃，Renovate 允许限制每小时或同时开启的 PR 数量。
|
||||
- **Pre-commit Hooks**: 在提交代码前运行的脚本工具，Renovate 同样可以自动更新这些钩子插件的版本。
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> [!info]+ 交叉引用
|
||||
> [[Pre-commit Hooks and Linting Sessions]] — Paul 在视频中提到 Neurangin 曾讲解过 pre-commit 的格式化与安全扫描，Renovate 也负责其版本更新。
|
||||
> [[Terraform and Terragrunt Best Practices]] — 本视频深入探讨了如何自动化维护这些基础设施即代码（IaC）工具的模块引用。
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: "CTP Topic 15 Working with Renovatebot"
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/06_CI_CD_GitOps"
|
||||
tags:
|
||||
- Renovatebot
|
||||
- Dependency-Update
|
||||
- GitOps
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 15_ Working with Renovatebot.mp4"
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 15 Working with Renovatebot
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 15_ Working with Renovatebot.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** ✅ 已完成（Gemini 摘要）
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 本次会议由 Paul Hopkins 主讲，核心围绕如何利用 **Renovate Bot** 自动化管理云原生基础设施中的依赖项更新。在复杂的云架构中，依赖项无处不在，包括 Docker 基础镜像、Maven 依赖、Terraform 模块、Kubernetes Helm Charts 等。Paul 指出，团队在维护大量基于 Gruntwork 的 Terraform 模块和 Terragrunt 配置时，面临着手动更新版本号耗时耗力且极易滞后的挑战。
|
||||
|
||||
> 为了解决这一“依赖地狱”问题，团队引入了 Renovate Bot。该工具能够实时扫描代码库，识别过时的版本标签（Semantic Versioning），并自动发起拉取请求（Pull Request）。Paul 详细展示了 Renovate 的核心功能，如 **Dependency Dashboard**（依赖仪表板），它能在一个 GitHub Issue 中列出所有待更新的项，提供全局视角。在实施层面，团队通过在仓库中配置 `renovate.json` 文件来定义管理策略，并支持 Terraform、Terragrunt、Docker 以及 pre-commit 钩子等多种技术栈。
|
||||
|
||||
> 目前，该方案已集成到 Jenkins 流水线中，虽然在初期遇到了 GitHub Enterprise 适配及 Jenkins 处理大量并发 PR 的性能瓶颈，但通过本地 Podman 容器化运行和合理的速率限制（Rate Limiting）配置，团队成功实现了依赖更新的自动化与标准化。这不仅提升了基础设施的安全性（及时修复漏洞），也确保了开发环境与生产环境配置的一致性。
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
- **Renovate Bot**: 一款开源的依赖自动化更新工具，通过扫描代码并自动提交 PR 来保持依赖项处于最新状态。
|
||||
- **Dependency Management**: 依赖管理，指对项目中引用的外部库、模块或镜像的版本进行跟踪、更新和维护的过程。
|
||||
- **Terragrunt**: 一个 Terraform 的轻量级封装层，用于处理多环境配置、减少重复代码（DRY）并管理远程状态。
|
||||
- **Semantic Versioning (SemVer)**: 语义化版本控制，通常采用 `主版本号.次版本号.修订号` 的格式，Renovate 依据此规则判断更新级别。
|
||||
- **Dependency Dashboard**: Renovate 在 GitHub 仓库中自动创建的一个 Issue，用于汇总所有依赖状态、待处理的 PR 以及更新选项。
|
||||
- **Managers**: Renovate 中的插件机制，用于识别和处理特定类型的依赖文件（如 `terraform` 经理处理 `.tf` 文件，`dockerfile` 经理处理镜像标签）。
|
||||
- **Rate Limiting**: 速率限制，为了防止自动化工具瞬间产生过多 PR 导致 CI/CD 系统崩溃，Renovate 允许限制每小时或同时开启的 PR 数量。
|
||||
- **Pre-commit Hooks**: 在提交代码前运行的脚本工具，Renovate 同样可以自动更新这些钩子插件的版本。
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> [!info]+ 交叉引用
|
||||
> [[Pre-commit Hooks and Linting Sessions]] — Paul 在视频中提到 Neurangin 曾讲解过 pre-commit 的格式化与安全扫描，Renovate 也负责其版本更新。
|
||||
> [[Terraform and Terragrunt Best Practices]] — 本视频深入探讨了如何自动化维护这些基础设施即代码（IaC）工具的模块引用。
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,50 +1,50 @@
|
||||
---
|
||||
title: "CTP Topic 2 Git"
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/06_CI_CD_GitOps"
|
||||
tags:
|
||||
- Git
|
||||
- VCS
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 2_ Git.mp4"
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 2 Git
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 2_ Git.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: "CTP Topic 2 Git"
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/06_CI_CD_GitOps"
|
||||
tags:
|
||||
- Git
|
||||
- VCS
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 2_ Git.mp4"
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 2 Git
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 2_ Git.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,64 +1,64 @@
|
||||
---
|
||||
title: CTP Topic 3 Deploy and maintain infrastructure
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/06_CI_CD_GitOps
|
||||
tags:
|
||||
- IaC
|
||||
- Deployment
|
||||
- CI/CD
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 3_ Deploy and maintain infrastructure.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 3 Deploy and maintain infrastructure
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 3_ Deploy and maintain infrastructure.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## Deploying and Maintaining Infrastructure
|
||||
|
||||
The session focuses on deploying and maintaining infrastructure, clarifying Terraform, Terragrunt, modules, and service catalogs within the landing zone context. It emphasizes the structure of Git repositories and how Terraform and Terragrunt files interact.
|
||||
|
||||
When a landing zone is provisioned, product teams are grouped, each having a landing zone and workload accounts. A product team, such as DevTools, deploys infrastructure to meet specific requirements across accounts like Artifactory and Active Directory. This involves multiple Git repositories, including the core landing zone repository, Terraform service catalog, and a product team service catalog.
|
||||
|
||||
A service module consists of a main.tf file that references other repositories, grouping modules to fulfill a business requirement, such as an active directory or DNS service. *When deploying infrastructure, Terragrunt HCL files are used to reference these services, targeting specific versions rather than the master branch.* These files may include dependencies to reference values across services, favoring dependencies over reading state files.
|
||||
|
||||
When referencing modules within the current codebase, a relative path can be used, but the preferred approach is to have a dedicated service catalog with a modules directory. This allows for independent release cycles and better maintainability. Modules can be used within one account, reused within a product team (in the product team service catalog), or used across product teams (in the Terraform service catalog).
|
||||
|
||||
*A service is a business requirement, while a regular module is a technical requirement.* A service deploys a set of multiple modules, abstracting them. The higher up the chain, the less configuration options are available, similar to an object-oriented approach.
|
||||
|
||||
Terragrunt fetches all references before running, using a Terragrunt cache directory to store cloned repositories. Terragrunt can be run at the directory level, considering dependencies, but applying without verification is discouraged. Jenkins jobs can be enhanced for debugging, and documentation should be comprehensive, referencing Gruntwork as a model. Versioning modules should follow major, minor, and patch conventions.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 3 Deploy and maintain infrastructure
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/06_CI_CD_GitOps
|
||||
tags:
|
||||
- IaC
|
||||
- Deployment
|
||||
- CI/CD
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 3_ Deploy and maintain infrastructure.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 3 Deploy and maintain infrastructure
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 3_ Deploy and maintain infrastructure.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## Deploying and Maintaining Infrastructure
|
||||
|
||||
The session focuses on deploying and maintaining infrastructure, clarifying Terraform, Terragrunt, modules, and service catalogs within the landing zone context. It emphasizes the structure of Git repositories and how Terraform and Terragrunt files interact.
|
||||
|
||||
When a landing zone is provisioned, product teams are grouped, each having a landing zone and workload accounts. A product team, such as DevTools, deploys infrastructure to meet specific requirements across accounts like Artifactory and Active Directory. This involves multiple Git repositories, including the core landing zone repository, Terraform service catalog, and a product team service catalog.
|
||||
|
||||
A service module consists of a main.tf file that references other repositories, grouping modules to fulfill a business requirement, such as an active directory or DNS service. *When deploying infrastructure, Terragrunt HCL files are used to reference these services, targeting specific versions rather than the master branch.* These files may include dependencies to reference values across services, favoring dependencies over reading state files.
|
||||
|
||||
When referencing modules within the current codebase, a relative path can be used, but the preferred approach is to have a dedicated service catalog with a modules directory. This allows for independent release cycles and better maintainability. Modules can be used within one account, reused within a product team (in the product team service catalog), or used across product teams (in the Terraform service catalog).
|
||||
|
||||
*A service is a business requirement, while a regular module is a technical requirement.* A service deploys a set of multiple modules, abstracting them. The higher up the chain, the less configuration options are available, similar to an object-oriented approach.
|
||||
|
||||
Terragrunt fetches all references before running, using a Terragrunt cache directory to store cloned repositories. Terragrunt can be run at the directory level, considering dependencies, but applying without verification is discouraged. Jenkins jobs can be enhanced for debugging, and documentation should be comprehensive, referencing Gruntwork as a model. Versioning modules should follow major, minor, and patch conventions.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,51 +1,51 @@
|
||||
---
|
||||
title: CTP Topic 3 Deploy and maintain infrastructure
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/06_CI_CD_GitOps
|
||||
tags:
|
||||
- IaC
|
||||
- Deployment
|
||||
- CI/CD
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 3_ Deploy and maintain infrastructure.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 3 Deploy and maintain infrastructure
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 3_ Deploy and maintain infrastructure.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 3 Deploy and maintain infrastructure
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/06_CI_CD_GitOps
|
||||
tags:
|
||||
- IaC
|
||||
- Deployment
|
||||
- CI/CD
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 3_ Deploy and maintain infrastructure.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 3 Deploy and maintain infrastructure
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 3_ Deploy and maintain infrastructure.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,61 +1,61 @@
|
||||
---
|
||||
title: CTP Topic 32 Using Atlantis CICD for infrastructure deployments
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/06_CI_CD_GitOps
|
||||
tags:
|
||||
- Atlantis
|
||||
- CI/CD
|
||||
- IaC
|
||||
- Terraform
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 32_ Using Atlantis CICD for infrastructure deployments.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 32 Using Atlantis CICD for infrastructure deployments
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 32_ Using Atlantis CICD for infrastructure deployments.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## Atlantis CICD: Replacing Jenkins for Infrastructure Deployments
|
||||
|
||||
The presentation introduces Atlantis, a new automation tool designed for teams to collaborate on Terraform code, aiming to replace Jenkins for infrastructure deployments. Atlantis addresses the speed and complexity issues of the current pipeline. *The current pipeline is practically very slow* due to significant initialization time, multiple code cloning, sequential testing, and ECS deployer provisioning. The existing pipeline's complexity stems from continuous tweaking to integrate more features and cover edge cases, leading to fragility and drift.
|
||||
|
||||
Atlantis is standalone, self-hosted, free, and open source, with an active community. It offers a better collaboration model, simplified networking, and cost savings by removing the need for numerous VPC endpoints. Atlantis applies changes before merging, ensuring code in sync with infrastructure. The workflow is simplified, allowing direct communication with Atlantis from GitHub via comments on pull requests, eliminating the need for separate accounts and integrations.
|
||||
|
||||
Atlantis is hosted on a single EC2 instance in each landing zone's shared account, notified by GitHub Enterprise using webhooks. It uses service accounts to interact with GitHub, post comments, do merges, and close PRs. Cross-account access is managed through deployed key roles in each account, utilized for both simple and cross-account module deployments. User management is controlled on GitHub, and build logs are stored in comments for auditing. Atlantis enforces apply requirements, such as mergeability and peer approval, before applying changes. Auto-merge is enabled for automatic merging upon successful application. Parallel builds are supported, running plan and apply commands concurrently for multiple modules.
|
||||
|
||||
Atlantis locking prevents conflicts by locking the directory of each module when a plan is run, until the pull request is merged, closed, or the plan is discarded. *When a plan is run, the directory of each module is locked until the pull request that is that has this folder locked is merged or closed, or the plan is manually discarded.* Modules and data file dependencies can be declared to trigger plans when dependencies change. Documentation, troubleshooting guides, and a list of migrated repositories are available to assist users.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 32 Using Atlantis CICD for infrastructure deployments
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/06_CI_CD_GitOps
|
||||
tags:
|
||||
- Atlantis
|
||||
- CI/CD
|
||||
- IaC
|
||||
- Terraform
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 32_ Using Atlantis CICD for infrastructure deployments.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 32 Using Atlantis CICD for infrastructure deployments
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 32_ Using Atlantis CICD for infrastructure deployments.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## Atlantis CICD: Replacing Jenkins for Infrastructure Deployments
|
||||
|
||||
The presentation introduces Atlantis, a new automation tool designed for teams to collaborate on Terraform code, aiming to replace Jenkins for infrastructure deployments. Atlantis addresses the speed and complexity issues of the current pipeline. *The current pipeline is practically very slow* due to significant initialization time, multiple code cloning, sequential testing, and ECS deployer provisioning. The existing pipeline's complexity stems from continuous tweaking to integrate more features and cover edge cases, leading to fragility and drift.
|
||||
|
||||
Atlantis is standalone, self-hosted, free, and open source, with an active community. It offers a better collaboration model, simplified networking, and cost savings by removing the need for numerous VPC endpoints. Atlantis applies changes before merging, ensuring code in sync with infrastructure. The workflow is simplified, allowing direct communication with Atlantis from GitHub via comments on pull requests, eliminating the need for separate accounts and integrations.
|
||||
|
||||
Atlantis is hosted on a single EC2 instance in each landing zone's shared account, notified by GitHub Enterprise using webhooks. It uses service accounts to interact with GitHub, post comments, do merges, and close PRs. Cross-account access is managed through deployed key roles in each account, utilized for both simple and cross-account module deployments. User management is controlled on GitHub, and build logs are stored in comments for auditing. Atlantis enforces apply requirements, such as mergeability and peer approval, before applying changes. Auto-merge is enabled for automatic merging upon successful application. Parallel builds are supported, running plan and apply commands concurrently for multiple modules.
|
||||
|
||||
Atlantis locking prevents conflicts by locking the directory of each module when a plan is run, until the pull request is merged, closed, or the plan is discarded. *When a plan is run, the directory of each module is locked until the pull request that is that has this folder locked is merged or closed, or the plan is manually discarded.* Modules and data file dependencies can be declared to trigger plans when dependencies change. Documentation, troubleshooting guides, and a list of migrated repositories are available to assist users.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,52 +1,52 @@
|
||||
---
|
||||
title: CTP Topic 32 Using Atlantis CICD for infrastructure deployments
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/06_CI_CD_GitOps
|
||||
tags:
|
||||
- Atlantis
|
||||
- CI/CD
|
||||
- IaC
|
||||
- Terraform
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 32_ Using Atlantis CICD for infrastructure deployments.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 32 Using Atlantis CICD for infrastructure deployments
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 32_ Using Atlantis CICD for infrastructure deployments.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 32 Using Atlantis CICD for infrastructure deployments
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/06_CI_CD_GitOps
|
||||
tags:
|
||||
- Atlantis
|
||||
- CI/CD
|
||||
- IaC
|
||||
- Terraform
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 32_ Using Atlantis CICD for infrastructure deployments.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 32 Using Atlantis CICD for infrastructure deployments
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 32_ Using Atlantis CICD for infrastructure deployments.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,72 +1,72 @@
|
||||
---
|
||||
title: CTP Topic 33 An introduction to GitOps
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/06_CI_CD_GitOps
|
||||
tags:
|
||||
- GitOps
|
||||
- CI/CD
|
||||
- Git
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 33_ An introduction to GitOps.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 33 An introduction to GitOps
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 33_ An introduction to GitOps.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> Victor Etkin presents an introduction to GitOps, explaining how it complements DevOps. GitOps applies software development principles to deployment processes, potentially resolving challenges like failed deployments and configuration inconsistencies.
|
||||
|
||||
Key benefits of GitOps:
|
||||
* Increased developer productivity using familiar tools.
|
||||
* Minimized failed deployments with easy rollback capabilities.
|
||||
* Faster feature releases.
|
||||
* Real-time auditing and improved security through Git's features.
|
||||
|
||||
GitOps uses Git workflows, CD pipelines, and infrastructure as code. Observability is crucial for ensuring the desired and actual states align. GitOps is often used with Kubernetes but can be applied elsewhere.
|
||||
|
||||
The four principles of GitOps: declarative configuration, version control, CD process separation, and incremental infrastructure implementation. Git serves as the primary tool, storing deployment infrastructure and application configurations. A GitOps controller reconciles the Git state with the actual system state. *The only tool a developer needs to know is Git.*
|
||||
|
||||
The goal is full automation, with code changes deployed safely in minutes. CI and CD should be decoupled. A basic GitOps workflow for Kubernetes involves developers committing code, creating container images, storing deployment configurations in Git, monitoring changes via a GitOps agent, and rolling out images to environments.
|
||||
|
||||
CI focuses on building and analyzing code, while CD focuses on deploying binaries. Separating CI and CD enhances security. CD tools can run inside container platforms like Kubernetes for added security.
|
||||
|
||||
GitOps enables on-demand incremental deployment, benefiting microservices architectures. CD processes require an IDEMPOTENT platform like Kubernetes. *An IDEMPOTENT operation is one that can be applied multiple times without changing the result beyond the initial application.*
|
||||
|
||||
CD processes can be implemented using push or pull models. The pull model, which monitors both Git and the target system, is recommended for GitOps. Human intervention is still needed for issues like resource failures. GitOps simplifies operations, allowing developers to focus on more valuable activities.
|
||||
|
||||
GitOps is a logical evolution of DevOps, simplifying adoption and enhancing portability. Git commit logs become audit trails, streamlining compliance.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 33 An introduction to GitOps
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/06_CI_CD_GitOps
|
||||
tags:
|
||||
- GitOps
|
||||
- CI/CD
|
||||
- Git
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 33_ An introduction to GitOps.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 33 An introduction to GitOps
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 33_ An introduction to GitOps.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> Victor Etkin presents an introduction to GitOps, explaining how it complements DevOps. GitOps applies software development principles to deployment processes, potentially resolving challenges like failed deployments and configuration inconsistencies.
|
||||
|
||||
Key benefits of GitOps:
|
||||
* Increased developer productivity using familiar tools.
|
||||
* Minimized failed deployments with easy rollback capabilities.
|
||||
* Faster feature releases.
|
||||
* Real-time auditing and improved security through Git's features.
|
||||
|
||||
GitOps uses Git workflows, CD pipelines, and infrastructure as code. Observability is crucial for ensuring the desired and actual states align. GitOps is often used with Kubernetes but can be applied elsewhere.
|
||||
|
||||
The four principles of GitOps: declarative configuration, version control, CD process separation, and incremental infrastructure implementation. Git serves as the primary tool, storing deployment infrastructure and application configurations. A GitOps controller reconciles the Git state with the actual system state. *The only tool a developer needs to know is Git.*
|
||||
|
||||
The goal is full automation, with code changes deployed safely in minutes. CI and CD should be decoupled. A basic GitOps workflow for Kubernetes involves developers committing code, creating container images, storing deployment configurations in Git, monitoring changes via a GitOps agent, and rolling out images to environments.
|
||||
|
||||
CI focuses on building and analyzing code, while CD focuses on deploying binaries. Separating CI and CD enhances security. CD tools can run inside container platforms like Kubernetes for added security.
|
||||
|
||||
GitOps enables on-demand incremental deployment, benefiting microservices architectures. CD processes require an IDEMPOTENT platform like Kubernetes. *An IDEMPOTENT operation is one that can be applied multiple times without changing the result beyond the initial application.*
|
||||
|
||||
CD processes can be implemented using push or pull models. The pull model, which monitors both Git and the target system, is recommended for GitOps. Human intervention is still needed for issues like resource failures. GitOps simplifies operations, allowing developers to focus on more valuable activities.
|
||||
|
||||
GitOps is a logical evolution of DevOps, simplifying adoption and enhancing portability. Git commit logs become audit trails, streamlining compliance.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,51 +1,51 @@
|
||||
---
|
||||
title: CTP Topic 33 An introduction to GitOps
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/06_CI_CD_GitOps
|
||||
tags:
|
||||
- GitOps
|
||||
- CI/CD
|
||||
- Git
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 33_ An introduction to GitOps.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 33 An introduction to GitOps
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 33_ An introduction to GitOps.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 33 An introduction to GitOps
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/06_CI_CD_GitOps
|
||||
tags:
|
||||
- GitOps
|
||||
- CI/CD
|
||||
- Git
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 33_ An introduction to GitOps.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 33 An introduction to GitOps
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 33_ An introduction to GitOps.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,66 +1,66 @@
|
||||
---
|
||||
title: CTP Topic 56 Automated infrastructure testing
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/06_CI_CD_GitOps
|
||||
tags:
|
||||
- Testing
|
||||
- IaC
|
||||
- Automation
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 56_ Automated infrastructure testing.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 56 Automated infrastructure testing
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 56_ Automated infrastructure testing.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## Automated Infrastructure Testing
|
||||
|
||||
Mark Francis discusses automated infrastructure testing, emphasizing its value and practical application for engineers. The session aims to provide actionable insights for immediate use.
|
||||
|
||||
Key points covered:
|
||||
|
||||
* Integration tests are crucial for validating deployed infrastructure functionality, going beyond syntax checks to ensure the actual deployment matches expectations.
|
||||
* *I think the bottom quote, just I think let's leave the repetitive things for the computers to do and use our brains for the complex human things.*
|
||||
* TerraTest, a Golang library, automates the apply-test-destroy cycle, streamlining testing processes.
|
||||
* Test-driven development (TDD) involves writing tests before implementing features, ensuring focused development and building a comprehensive test suite.
|
||||
* A new workflow is proposed, integrating test writing as a primary step and removing manual validation, aiming for automated validation suites and increased confidence in deployments.
|
||||
|
||||
The presentation introduces TerraTest and its role in automating infrastructure testing. It highlights a repository with basic examples, demonstrating how TerraTest applies Terraform configurations, validates outputs, and destroys resources. The benefits of this approach include automating manual checks, testing complex modules, and increasing confidence in code changes.
|
||||
|
||||
The discussion also covers the challenges of infrastructure testing, such as time investment and the maturity of testing tools. However, it argues that the long-term benefits, including reduced bugs and increased confidence, outweigh the initial difficulties. The session concludes with a proposed workflow that integrates testing as a core component of infrastructure development, emphasizing the importance of treating tests as first-class citizens. *I'm just extending the value of putting stuff as code.*
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 56 Automated infrastructure testing
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/06_CI_CD_GitOps
|
||||
tags:
|
||||
- Testing
|
||||
- IaC
|
||||
- Automation
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 56_ Automated infrastructure testing.mp4
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 56 Automated infrastructure testing
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 56_ Automated infrastructure testing.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> ## Automated Infrastructure Testing
|
||||
|
||||
Mark Francis discusses automated infrastructure testing, emphasizing its value and practical application for engineers. The session aims to provide actionable insights for immediate use.
|
||||
|
||||
Key points covered:
|
||||
|
||||
* Integration tests are crucial for validating deployed infrastructure functionality, going beyond syntax checks to ensure the actual deployment matches expectations.
|
||||
* *I think the bottom quote, just I think let's leave the repetitive things for the computers to do and use our brains for the complex human things.*
|
||||
* TerraTest, a Golang library, automates the apply-test-destroy cycle, streamlining testing processes.
|
||||
* Test-driven development (TDD) involves writing tests before implementing features, ensuring focused development and building a comprehensive test suite.
|
||||
* A new workflow is proposed, integrating test writing as a primary step and removing manual validation, aiming for automated validation suites and increased confidence in deployments.
|
||||
|
||||
The presentation introduces TerraTest and its role in automating infrastructure testing. It highlights a repository with basic examples, demonstrating how TerraTest applies Terraform configurations, validates outputs, and destroys resources. The benefits of this approach include automating manual checks, testing complex modules, and increasing confidence in code changes.
|
||||
|
||||
The discussion also covers the challenges of infrastructure testing, such as time investment and the maturity of testing tools. However, it argues that the long-term benefits, including reduced bugs and increased confidence, outweigh the initial difficulties. The session concludes with a proposed workflow that integrates testing as a core component of infrastructure development, emphasizing the importance of treating tests as first-class citizens. *I'm just extending the value of putting stuff as code.*
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,51 +1,51 @@
|
||||
---
|
||||
title: CTP Topic 56 Automated infrastructure testing
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/06_CI_CD_GitOps
|
||||
tags:
|
||||
- Testing
|
||||
- IaC
|
||||
- Automation
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 56_ Automated infrastructure testing.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 56 Automated infrastructure testing
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 56_ Automated infrastructure testing.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: CTP Topic 56 Automated infrastructure testing
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/06_CI_CD_GitOps
|
||||
tags:
|
||||
- Testing
|
||||
- IaC
|
||||
- Automation
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 56_ Automated infrastructure testing.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 56 Automated infrastructure testing
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 56_ Automated infrastructure testing.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,51 +1,51 @@
|
||||
---
|
||||
title: "CTP Topic 9 CI CD with Gruntwork"
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/06_CI_CD_GitOps"
|
||||
tags:
|
||||
- CI/CD
|
||||
- Gruntwork
|
||||
- IaC
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 9_ CI_CD with Gruntwork.mp4"
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 9 CI CD with Gruntwork
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 9_ CI_CD with Gruntwork.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: "CTP Topic 9 CI CD with Gruntwork"
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/06_CI_CD_GitOps"
|
||||
tags:
|
||||
- CI/CD
|
||||
- Gruntwork
|
||||
- IaC
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 9_ CI_CD with Gruntwork.mp4"
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 9 CI CD with Gruntwork
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 9_ CI_CD with Gruntwork.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
@@ -1,38 +1,38 @@
|
||||
---
|
||||
title: "Public Cloud Learning Sessions- Ollie Workflow and The Demand Process - 20240416 160113-Meeting Recording"
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/06_CI_CD_GitOps"
|
||||
tags:
|
||||
- Workflow
|
||||
- Demand-Process
|
||||
- Agile
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/Public Cloud Learning Sessions- Ollie Workflow and The Demand Process - 20240416_160113-Meeting Recording.mp4"
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# Public Cloud Learning Sessions- Ollie Workflow and The Demand Process - 20240416 160113-Meeting Recording
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/Public Cloud Learning Sessions- Ollie Workflow and The Demand Process - 20240416_160113-Meeting Recording.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## Oli Workflow and Demand Process
|
||||
|
||||
The session covers the Oli workflow process for hyperscaler spend approval, demand management, and request fulfillment. The current mandate requires written approval from MUI or Shannon for any hyperscaler spend, regardless of the amount, for engineering lab space or commercial workload space. The Oli workflow process is being transitioned to the FinOps team under Tom Bice, who are working on integrating it into SMACs.
|
||||
|
||||
The base instructions for lab requests, commercial requests, and the general OLLI form guide are available in Confluence. *If justification details are not provided, requests are subject to immediate rejection.* The workflow process includes reviews by the presenter, the requester's manager, M5, lab services director, infrastructure M5, cloud services infrastructure, cloud services, and finally, approval by Shannon or Muwe. The requester is responsible for advocating for their workflow to be approved.
|
||||
|
||||
The request form pulls employee name and manager information from the corporate AD. The VP M5 level within their reporting structure requires validation that the workflow is properly requested, legitimate, raised for the right project and resourcing, and is budgeted. The organization is selected from a dropdown. Cost center information can be found in Talent Central. The workflow is geared towards engineering, with requests for budgetary review every six months. A critical field is whether the request is a budget increase or a new lab space. The cloud provider is selected, and if it's a budget increase, the existing account name is required. The project type is selected from a dropdown list. The region requested must be on the active regions list. Justification questions are submitted in the comment section.
|
||||
|
||||
The proposed workflow involves three steps: feasibility validation by FinOps, technical feasibility validation by cloud services, and budget availability validation by the FPNA team. The workflow then goes through the requester's leadership, manager, M5 VP level, and finally, the engineering chief product officers VP. The Oli system allows users to view their assignments and generate in-flight CSV reports. The reports provide information on workflow statuses, requesters, cost centers, monthly costs, and the current step in the process.
|
||||
|
||||
The ITIL framework divides business processes into service strategy, design, transition, operation, and improvement phases. The approval process is the first stage of request fulfillment. A master catalog of combined cloud products is being developed. Demand management is necessary to balance requests against available capacity. The OpenText way of fulfilling cloud requests is a request submission process.
|
||||
|
||||
The end-to-end process includes the approval stage, demand management, and definition work. Business units can submit requests directly into Octane or through a Qixi interface. The goal is to simplify the process for business units to identify and request services from the catalog. The master catalog of products and services will be embedded within SMACS. The Enterprise Iton project for the standard OT SMACS tenant is on hold. The ADM and ITOM Demand Planning Meetings capture what is needed, how many are required, and the release they are required in. The goal is for business units to self-select what they need 80% of the time. *Machines should do what machines can do, enabling an automated fulfillment process.*
|
||||
---
|
||||
title: "Public Cloud Learning Sessions- Ollie Workflow and The Demand Process - 20240416 160113-Meeting Recording"
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/06_CI_CD_GitOps"
|
||||
tags:
|
||||
- Workflow
|
||||
- Demand-Process
|
||||
- Agile
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/Public Cloud Learning Sessions- Ollie Workflow and The Demand Process - 20240416_160113-Meeting Recording.mp4"
|
||||
audio-source: ""
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# Public Cloud Learning Sessions- Ollie Workflow and The Demand Process - 20240416 160113-Meeting Recording
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/Public Cloud Learning Sessions- Ollie Workflow and The Demand Process - 20240416_160113-Meeting Recording.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## Oli Workflow and Demand Process
|
||||
|
||||
The session covers the Oli workflow process for hyperscaler spend approval, demand management, and request fulfillment. The current mandate requires written approval from MUI or Shannon for any hyperscaler spend, regardless of the amount, for engineering lab space or commercial workload space. The Oli workflow process is being transitioned to the FinOps team under Tom Bice, who are working on integrating it into SMACs.
|
||||
|
||||
The base instructions for lab requests, commercial requests, and the general OLLI form guide are available in Confluence. *If justification details are not provided, requests are subject to immediate rejection.* The workflow process includes reviews by the presenter, the requester's manager, M5, lab services director, infrastructure M5, cloud services infrastructure, cloud services, and finally, approval by Shannon or Muwe. The requester is responsible for advocating for their workflow to be approved.
|
||||
|
||||
The request form pulls employee name and manager information from the corporate AD. The VP M5 level within their reporting structure requires validation that the workflow is properly requested, legitimate, raised for the right project and resourcing, and is budgeted. The organization is selected from a dropdown. Cost center information can be found in Talent Central. The workflow is geared towards engineering, with requests for budgetary review every six months. A critical field is whether the request is a budget increase or a new lab space. The cloud provider is selected, and if it's a budget increase, the existing account name is required. The project type is selected from a dropdown list. The region requested must be on the active regions list. Justification questions are submitted in the comment section.
|
||||
|
||||
The proposed workflow involves three steps: feasibility validation by FinOps, technical feasibility validation by cloud services, and budget availability validation by the FPNA team. The workflow then goes through the requester's leadership, manager, M5 VP level, and finally, the engineering chief product officers VP. The Oli system allows users to view their assignments and generate in-flight CSV reports. The reports provide information on workflow statuses, requesters, cost centers, monthly costs, and the current step in the process.
|
||||
|
||||
The ITIL framework divides business processes into service strategy, design, transition, operation, and improvement phases. The approval process is the first stage of request fulfillment. A master catalog of combined cloud products is being developed. Demand management is necessary to balance requests against available capacity. The OpenText way of fulfilling cloud requests is a request submission process.
|
||||
|
||||
The end-to-end process includes the approval stage, demand management, and definition work. Business units can submit requests directly into Octane or through a Qixi interface. The goal is to simplify the process for business units to identify and request services from the catalog. The master catalog of products and services will be embedded within SMACS. The Enterprise Iton project for the standard OT SMACS tenant is on hold. The ADM and ITOM Demand Planning Meetings capture what is needed, how many are required, and the release they are required in. The goal is for business units to self-select what they need 80% of the time. *Machines should do what machines can do, enabling an automated fulfillment process.*
|
||||
|
||||
@@ -1,50 +1,50 @@
|
||||
---
|
||||
title: "Public Cloud Learning Sessions- Ollie Workflow and The Demand Process - 20240416 160113-Meeting Recording"
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/06_CI_CD_GitOps"
|
||||
tags:
|
||||
- Workflow
|
||||
- Demand-Process
|
||||
- Agile
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/Public Cloud Learning Sessions- Ollie Workflow and The Demand Process - 20240416_160113-Meeting Recording.mp4"
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# Public Cloud Learning Sessions- Ollie Workflow and The Demand Process - 20240416 160113-Meeting Recording
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/Public Cloud Learning Sessions- Ollie Workflow and The Demand Process - 20240416_160113-Meeting Recording.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
---
|
||||
title: "Public Cloud Learning Sessions- Ollie Workflow and The Demand Process - 20240416 160113-Meeting Recording"
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/06_CI_CD_GitOps"
|
||||
tags:
|
||||
- Workflow
|
||||
- Demand-Process
|
||||
- Agile
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/Public Cloud Learning Sessions- Ollie Workflow and The Demand Process - 20240416_160113-Meeting Recording.mp4"
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# Public Cloud Learning Sessions- Ollie Workflow and The Demand Process - 20240416 160113-Meeting Recording
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/Public Cloud Learning Sessions- Ollie Workflow and The Demand Process - 20240416_160113-Meeting Recording.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
|
||||
Reference in New Issue
Block a user