CI Team Structure

问题描述

过去一到两年来的软分析表明，在 CI 中着手进行重大新功能和特性是困难的，并且不断涌现的问题会造成干扰。每个人都孤立地从事自己的工作、特性或生产链的某个部分，几乎没有时间进行周到的同行评审和协作开发。

策略

目标

  • 提高开发人员的专注度，减少干扰、中断和时间切片。

  • 鼓励协作团队开发。

  • 更好、更快的代码审查

团队结构

  • The Ruck

  • The Rover

  • The Sprint Team

The Ruck

每周会有一人站在前线，报告在 CI 中发现的故障。Ruck 和 Rover 在 sprint 的第二周交换角色。

  • 主要关注点是观察 CI、报告错误、改进调试文档。

  • 不参与 sprint

  • 参加团队需要代表的会议

  • 响应 #oooq / #tripleo 上的 ping，关于 CI

  • 审查和改进文档

  • 尽可能参加小组会议

  • 为了识别，使用 irc 昵称 $user|ruck

The Rover

Ruck 的主要备份。Ruck 应该捕获 CI 中的所有问题，并将问题传递给 Rover 进行更深入的分析或错误解决。

  • Ruck 的备份

  • 工作负载来自 tripleo-quickstart 错误队列，Rover 不监控 CI

  • 次要的工作输入是 Trello 板上定义的的技术债务。

  • 参加 sprint 会议，但不负责任何 sprint 工作

  • 帮助对传入的 gerrit 审查进行分类

  • 响应 irc #oooq / #tripleo 上的 ping

  • 如果 Ruck 对其任何职责感到不堪重负，Rover 是主要备份。

  • 为了识别，使用 irc 昵称 $user|rover

The Sprint Team

团队的定义是在 sprint 开始时根据可用性确定的。团队成员应尽可能专注于 sprint epic。团队成员应将 80% 的时间用于 sprint 目标，将 20% 的时间用于任何其他职责，例如代码审查或 Rover 无法单独处理的传入高优先级错误。

  • 尽可能将中断移交给 Ruck 和 Rover

  • 作为一个团队专注于 sprint epic

  • 与其他 sprint 团队成员协作

  • 寻求关于 sprint 工作的同行评审

  • 每天更新 Trello 板

    • 可以在站立会议上指向 Trello 卡片以了解状态

The Squads

小队作为 sprint 团队的一个子单元运作。每个小队将使用相同的流程和程序，并由团队催化剂管理。

  • 当前小队
    • 持续集成 (CI)

      • 负责 TripleO CI 系统（非基础设施）和构建验证。

    • Tempest

      • 负责 tempest 开发。

Team Leaders

The team catalyst (TC)

团队中负责组织小组的成员。团队将选举或任命每个发布版本的团队催化剂。

  • 组织和计划 sprint 会议

  • 收集状态并发送状态电子邮件

The user advocate (UA)

团队中负责帮助确定工作优先级。团队将选举或任命每个发布版本的用户倡导者。

  • 组织和确定 sprint 规划中的 Trello 板

  • 监控 sprint 期间的板

  • 确保正在完成正确的工作。

The Squads

CI 团队有两个小队。

  • tripleo ci

  • tempest 开发

每个小队都有一个 UA，并且共享一个 TC。两者都参与 Ruck 和 Rover 轮换。

Rocky 的当前领导者

  • 团队催化剂 (ci, tempest) - Matt Young

  • 用户倡导者 (ci) - Gabriele Cerami

  • 用户倡导者 (tempest) - Chandan Kumar

Sprint Structure

sprint 的目标是在协作方式下定义一个狭窄且集中的功能，称为 epic。未在 sprint 中完成的工作将被添加到 Trello 的技术债务列中。

注意：每个 sprint 都需要一个明确的完成定义，该定义记录在用于 sprint 的 epic 中。

Sprint Start ( Day 1 ) - 2.5 hours

  • sprint 持续三周

  • Ruck 和 Rover 参加全体团队会议

  • 审查休假

  • 审查 Ruck/Rover 需要覆盖的任何会议

  • UA 将提出 sprint epic 的选项

  • 讨论 epic，轻微地分解每个 epic

  • 投票选择 epic

  • 投票可以使用 doodle 表格完成

  • 将 sprint epic 分解为卡片

  • 审查每张卡片

    • 每张卡片必须有一个明确的完成定义

    • 作为一个小组，在卡片中包含尽可能多的细节，以便为几乎没有任务背景的工程师提供足够的信息。

Sprint End ( Day 15 ) - 2.5 hours

  • 回顾

    • 仅限团队成员、ruck 和 rover

  • 记录 sprint 中剩余的任何技术债务

  • Ruck / Rover 交接

  • 分配 Ruck 和 Rover 职位

  • sprint 演示 - 如果可用

  • irc 上的工作时间

Scrum meetings - 30 Min

  • 规划会议，视频会议

  • Sprint End，视频和 irc #oooq 在 freenode 上

  • 每周 2 次现场视频会议

    • sprint 站立会议

  • 其他日期，将状态发布到团队的 Trello 板和/或卡片

TripleoO CI Community meeting

  • 应每周举行一次社区会议。

  • 会议应理想地安排在 TripleO 社区会议（OFTC）之后立即举行，以便于安排。

  • CI 会议应作为 TripleO 社区会议的一部分进行公布，以鼓励参与。

替代方案与历史

过去，CI 团队以个人或成对的方式为 CI 系统的不同部分和某些功能工作。两者都未能成功地以定期节奏交付功能。

实现

主要作者：Wes Hayutin weshayutin at gmail

其他贡献者

  • Ronelle Landy rlandy at redhat

  • Arx Cruz acruz at redhat

  • Sagi Shnaidman at redhat

里程碑

本文档可能会根据 sprint 回顾中讨论的反馈而演变。在每个上游周期结束时应进行深入的回顾。

参考资料

Trello

将使用 Trello 板来组织工作。预计团队每天都会更新板和他们的卡片。

Dashboards

使用多个仪表板来监控 CI

Team Notes

Bug Queue

修订历史

修订版

发布名称

描述

Rocky

2018 年 4 月 16 日

注意

本作品采用知识共享署名 3.0 非移植许可协议授权。 http://creativecommons.org/licenses/by/3.0/legalcode