devops最佳实践

在过去的几个月中，我一直在写一些个人可以逐步提高成功的小规模渐进式行为。 本月，我想强调一下我认为对于取得小小的成功至关重要的团队行为。 我曾在Red Hat的AtomicOpenShift（AOS）团队（ ）中度过了一段时间。

尽管我在AOS团队中花费了大量时间，但我很少有机会直接与Cockpit合作。 今年年初我们在布尔诺时，我很幸运有机会和他们一起坐了一段时间。 从局外人的角度来看，团队之间的交流很轻松-涉及技术主题和个人主题-都会引起您的注意。 实际上，您可能已经假定它们都在同一办公室一起工作。 但是，团队中的所有五名工程师和设计师分布在欧洲和美国。

我很高兴在本月初与 ，Dominik Perpeet，Lars Uebernickel，Marius Vollmer，Peter Volpe和交谈。 我们谈论了很多事情，但是在采访中形成了三个中心主题：

• 了解你的目标
• 使用反馈循环
• 致力于开放透明的沟通

在接下来的三个月中，我的专栏文章将重点讨论这些主题以及您可以如何与团队一起逐步改进。 本月，我邀请您与在Cockpit项目上工作的团队一起度过时光，一窥他们所做的使他们共同成功的事情。

驾驶舱团队拥有广泛的持续集成/持续部署（CI / CD）系统。 它如何帮助您一起工作？

Dominik Perpeet（DP）：首先，它使我们可以更加专注于“有趣的东西” —开发令人兴奋的新功能。 如果在合并之前对所有内容进行了测试，则可以将错误与特定更改绑定在一起，则更容易查看某些内容。 坦白说：如果没有自动化，我们将无法按照我们现在交付的速度交付。 另外，告诉其他人也非常有动力：“嘿，我们刚刚合并了您的东西。下周您将在Fedora上看到它以及其他所有人！”

（SW）： Cockpit项目取决于您的计算方式，可在任何地方使用多达100个不同的系统API，并将它们集成到一致的体验中。 每个方面都在不断变化，而集成至关重要。 没有持续的自动化集成，这将是团队中每个人的唯一工作。 这是项目的关键部分。 要考虑的另一件事是，定期和快速交付是开源和敏捷的关键部分。 它在贡献者中循环。 集成测试允许这种情况发生。

中的许多团队参与了Scrum的严重修改版本。 你们在很大程度上避免了该过程，但现在您正在寻求将部分工作流程纳入工作流程中。 是什么引发了变化？

记者：最近，我们采用了sprint时间表，但没有考虑scrum的所有方面。 主要目标是缩短我们自己开发过程中的反馈循环。 我们希望能够回顾给定冲刺期间我们所完成的任务，并为计划，回顾和迭代提供清晰的划定点。

Andreas Nilsson（AN）：我一直碰到的一件事是，我从各种各样的地方得到了很多不同的任务，却没有一种很好的方法来确定优先级。 冲刺帮助我专注于重要的事情，并提供了更好的估算方法。 如果有其他事情要进入，则需要从优先级列表中删除其他内容。

Stef经常谈论 。 它如何帮助您实现目标？

DP：当我们花时间从“顶部”（设计角度）着手时，我们在整体上浪费的时间更少，从团队中的其他人身上受益最多，并且整个开发过程都不会那么混乱。

解答：它使我们可以在整个开发过程中就正在构建的东西达成更好的协议，从写下我们正在构建的东西和为谁着手，根据这些需求创建临时角色，并根据这些需求制作线框。这些角色的工作流程。 与将时间浪费在昂贵的代码迭代上相比，它使我们可以更快地进行实验和迭代。

南方周末：它也可以帮助我们跨项目协调。 首先拥有设计和故事时，可以轻松地与其他项目一起实现给定的目标。 目标很明确。 没有它，讨论没有目标的实现细节通常是徒劳和令人沮丧的。

告诉我更多有关跨社区工作的信息- 。 是什么让您的工作成功了？

DP：就目标（无论是我们的，他们的目标还是共同的目标）进行公开交流，以及在无处可走或存在其他缺陷的情况下放弃工作的意愿。 我认为几乎所有跨社区工作都改善了。 我们并不是孤立的-实际上恰恰相反-因此与他人的每次交互都意味着对内部和外部视图的更多校准。

南方周末：设计驱动的开发，用户案例和线框已经产生了巨大的变化。 当目标明确的用户故事时，其他社区则更愿意参与，他们可以提供有关该故事的反馈和迭代。

沟通如何影响团队的工作？

DP：沟通是我们工作的重要组成部分。 我们彼此相距遥远，因此交流感觉更加有意识和有针对性。 我们使用任何可用的模式，并为我们想要实现的目标而工作—面对面或面对面的视频聊天（当我们想要见面时），语音聊天进行头脑风暴，IRC（如果需要公开讨论），电子邮件为了保持记录和异步， 进行设计或代码讨论。 我认为所有这些还取决于心情和涉及的人。

时区是一个挑战，但可以控制。 它们还导致安静的工作时间，这还不错。 但是，我相信，如果我们不亲自见面，我们将无法发挥团队的作用。

南方周末：开源工作是天生的。 每当实施分布式工具或系统时，都会产生非零的开销。 对于代码，微服务或开放源代码来说都是如此。 但是，这里的主要目标是可以扩展分布式系统，但是我也同意Dominik的看法，我们对此非常务实，而且在大多数人不在的时候，有时在IRC上进行讨论。 开会讨论总体有助于我们对要完成的工作建立基本的了解，并使我们保持同步。

并非所有事情都很棒。 您作为团队目前面临的挑战是什么？

Marius Vollmer（MV）：我们开始专业化，这增加了上下文切换成本，并增加了在处理不熟悉的代码段时发生事情的风险。 我们获得了更多反馈，这是很棒的，但是也许我们没有做好足够的React。

SW：让开源社区进一步参与进来。 我们确实有来自团队外部的贡献，但是尝试并帮助其成长是一个挑战。

AN：在不同产品之间优先处理最终产品。 我也感到我们缺少客户反馈循环。 确切的需求是什么？针对谁？一旦实施，我们是否以适合最终用户的良好方式解决了这些需求？

如果您从头开始对任何人有任何建议，那将是什么？

南方周末：永远不要离开集成测试。 如果Marius并没有从此开始，那将很容易使它成为未来的目标，那将是该项目的失败。 另外，从一开始就尽早发布，经常发布并在任何地方发布。 我们等了太久才分发Debian和Ubuntu软件包，这阻碍了项目的采用。

AN：从第一天开始设计工作流程。 如果不是这样，您的竞争将使您周围不断运转。

DP：总是有明确的长期目标，但不要害怕出于充分的理由而改变目标。

翻译自:

devops最佳实践