玩转 DevOps 工具链从未如此简单，开源项目 DevStream v0.1.0 Release 可以尝尝鲜

[Benker]

写代码以外，还有很多头疼事

假如你现在成立一家公司，或者更具体一点，你要组建一个研发团队，在开始写代码前你需要做哪些事情？

有些繁琐又重复，让人头疼的事情是绕不开的，比如：

1. 你需要选择一个地方来存放代码，也许是 GitHub ，也许是 GitLab ；
2. 你需要一个工具来完成项目管理或者说需求管理、Issue 管理等等工作，也许你会选择 Jira 或者禅道或者 Trello ；
3. 你需要选择一种开发语言，选择一个开发框架，比如你决定用 Golang 来开发，假如这是一个 web 项目，你需要考虑 web 框架用什么？“第一行”代码怎么写，也就是第一个脚手架怎么组装；
4. 然后你需要配置一些 ci 自动化，比如 GitHub 上添加 actions 来完成代码的扫描、测试等等；
5. 当然 cd 工具也不能少，不管你选择 Jenkins 还是 ArgoCD ；
6. 如果 cd 完成了，接下来可能你马上要开始纠结日志、监控、告警等等方案应该怎么定了
7. 如果想得更多，或许你希望 GitHub 上别人给你提的 issue 能够自动同步到你的 Jira 或者 Trello……
8. ……

也许我上面说到的例子并不完整或者绝对准确，但是有一个结论我们必须接受：在一个软件的开发生命周期中，除了业务代码编码本身，在 DevOps 工具链上我们需要花费大量精力去选型、打通、落地、维护……

开源 DevOps 工具链 vs 一站式 DevOps 平台

我们可以选择在某个云厂商手里购买一个一站式 DevOps 解决方案，只要钱够，基本就不用操心运维的问题了。这时候你可能会遇到的最大的问题就是“灵活性”不足，没有一个云厂商愿意为了你的定制化需求去修改这个“一站式 DevOps”里的任何一个环节。比如你觉得自己公司的持续集成环节特别牛，但是怎么集成进去呢？当然“钱够”也只是一个假设，或许最大的问题是“没钱”。

我们也可以选择开源的 DevOps 工具，自己落地，搭建一条灵活的工具链，只要有足够的人力来维护（可能需要几个很资深的工程师才能玩转整条工具链）。这时候可能会遇到的最大的问题就是“人力”和“经验”不足，要自己搞清楚每个环节的“最佳实践”并不是一件容易的事情。免费、灵活，但是落地难，维护难，这也不是最佳方案。

所以我们想要有开源 DevOps 工具链的灵活性，可以自由替换其中任意一个工具；我们也想要有一站式 DevOps PaaS 服务的便利性，不用自己投入人力物力去研究去慢慢落地。

所以你还有第三种选择，就是找一个能够“自动化管理开源 DevOps 工具链”的工具，让它来实现一个“节约人力”又“灵活高效”的 DevOps 平台。

没错，DevStream 做的就是这件事：解决开源 DevOps 工具落地的难点，搞定开源 DevOps 工具链之间打通的痛点，解放研发团队的生产力，让大家少在 DevOps 工具上踩坑，腾出更多的精力在自己的业务逻辑上。

DevStream v0.1.0 目前能干什么？

1. 缺陷、需求管理 - Trello (集成 GitHub)
2. 源码管理 - Golang 脚手架生成
3. CI 流程 - Golang 、Python 、Nodejs
4. CD/GitOps - ArgoCD / ArgoCD App
5. Monitoring - kube-prometheus
6. ……

当然当你打开 DevStream 的项目主页时，或许在 Releases 页面里会惊奇地发现我们已经发布了 v0.2.0 或者更新版本了，那么不需要犹豫，请直接下载最新版本来体验，让历史成为历史。

能不能更直观一点？

Demo 视频： https://www.bilibili.com/video/BV1wq4y147T1/

你想问 DevStream 的将来？

或许用不了多久，我们就能完整实现 “DevOps toolchain as code”，那时候你的整个 DevOps 工具链都能以 DevStream 作为唯一入口来运维，dtm(DevStream 命令行工具)将成为你的整条 DevOps 工具链的 “single source of truth”。当然那时你需要替换整个 DevOps 工具链中的某一个环节，也会变得很简单。

其实目前我们已经部分实现 “single source of truth”，部署好的工具发生的部分变更已经能够被 dtm 感知到，并且 dtm 会判断这种变更是否合理，是否需要修复，进而采取相应的动作让整个 DevOps 工具链变得更可靠。

怎么参与 DevStream 社区？

当然，DevStream 的发展离不开社区用户的支持，DevStream 欢迎所有人参与社区建设，一起完善 dtm 的功能，让 dtm 越来越强大！

怎么参与 DevStream 社区？

不要有任何心理负担，只要打开 GitHub ，找到 merico-dev/stream 项目，README 里有详细的介绍。反正就是非常欢迎大家下载、体验、捉虫、提 Issue 、挑刺、bugfix 等等等等。

如果您有任何建议或疑问，可以加入 Discord [https://discord.com/invite/83rDG6ydVZ]或 点击 merico-dev/stream->Readme->DevStream 用户群，与 DevStream 开发者沟通。

[Taiga]

简单的看了下，如果有理解错误 po 主请纠正我。
所以解决的痛点是，打通 DevOps 工具链，把一个比较通用解决方案给到项目上。
那么之后呢。比如说，action 运行了一段时间 pipeline 需要修改，是改 stream 配置重新部署，还是直接去仓库把 aciton 改了？

[IronCore864]

@Taiga 很好的问题！

这其实是一个是否要把配置作为 Single Source of Truth (SSoT)的问题。

可能对于有些工具而言这么做没问题，但有些工具这么做可能就会带来问题：比如你举的例子，如果不允许我手动 git commit 来修改 pipeline 我觉得很肉疼。。。

所以可能最终的实现还是要看负责那个工具的插件的实现。到底哪些插件适合做成 SSoT? 这个问题可能让插件的使用者来回答比较具有说服力。

所幸的是，某个插件是否要做成 SSoT ，DevStream 都是支持的。

[Taiga]

@IronCore864 这么问是因为我觉得 DevStream 的定位有点奇怪。从他上面可以看到 Terraform 的影子，并且也提出了 DevOps toolchain as code 的点子。

但是我能想到的使用场景，也就在新起项目的时候快速 copy 出一条标准化的模板。之后的修大概率不会再用 DevStream 了。
因为像 pipeline 本来就是 code 了，没必要再 as code 一次。仓库 /看板（ SaaS ）配置本来就是一次性配置，不会频繁修改没有 as code 的必要。

至于 SSoT ，为了实现他而产生的 double 学习 /配置成本，我个人会觉得不是特别划得来。

[IronCore864]

@Taiga 非常有深度的回复，再次感谢！

能看出您对于无论是 DevOps 工具链还是 Terraform 的原理都有深刻且读到的见解，请再次接受我的赞美：）

毋庸置疑，DevStream 的确受到了 Terraform 的启发；当然，更大程度上是受我们自家 Dev 系列产品 DevLake （ merico-dev/lake ）的启发。当然，如果追宗溯祖，其实 Terraform 本身的 core-plugin 架构、core 做状态机然后 plugin 做 CRUD 的主意也并不是原创就是了：）

"从 0 到 1"的确是 DevStream 首先针对的场景：初创公司、初创团队、老公司老团队的初创项目需要快速 bootstrap 、需要快速搭建 Software Development Life Cycle (SDLC)所依赖的全部工具。对于有能力自研一站式 DevOps 平台的中大型企业来说，可能并不是 DevStream 的第一批潜在用户。当然，从长远来看，DevStream 力图去做 DevOps Toolchain 界的 apt/apk/yum 甚至是"Linux 发型版本"；但作为 v0.1.0 版本，我们的目的不是解决从 1 到 100 ， 而是解决从 0 到 1.

至于 v0.2, v0.3, v0.4...以至于 v1.0, v2.0 之类的版本，自然是要完善"从 1 到 100"的场景，否则就会像您说的一样，"之后的修大概率不会再用 DevStream 了"，这显然并非是我们的本意。

SSoT 是否值得， 其实我们也不知道：这正是我们敢于选择在产品非常雏形阶段的 v0.1 就决定与公众面世的原因：我们想倾听用户的声音，让用户告诉我们它们想要什么产品，什么样的产品能够为他们的工作带来最大的加在一起；而不是想开发一款自认为特别牛逼的产品，完善到了 v1.0 再发布，only to find out that we solved a problem that doesn't even exist in the first place.

DevStream 的目标是减少用户的 operational overhead （请原谅中英文夹杂的回复，有些词汇本来就是在英语环境下接触到的，可能没找到合适的翻译，见笑），如果实现 SSoT 反而增加了用户的学习、配置成本，那的确就有些舍本求末的意思了，这正是我们想尽快发布出来倾听用户声音的原因。说实话，我个人的观点其实是不太赞成 DevStream 来支持 SSoT ，或者，至少我希望把是否由 DevStream 来支持 SSoT 这给决定交给用户、交给插件的开发者来决定，因为他们才最知道自己的需求。但是我们并不敢狂妄自大的替用户做决定，于是还是决定尽快 public release 然后倾听用户的声音。本来我以为这不是一个适合在 v0.1 阶段讨论的问题，因为可能只有用了一些时间之后才能对这个问题有更深刻的理解，出乎意料的是在发布当天就受到了您这样有见解的回复，再次感谢！

其实我觉得，与其说 DevStream 是为了解决某个切实的问题（从 0 到 1 也好，从 1 到 100 也好），不如说 DevStream 本身是一种新的思维方式，更厚颜无耻的说是一种哲学思想：我们不想受限于 one-size-fits-all 的一站式平台的限制，我们想要在 SDLC 的整个过程中都达到研发效能的最大化：在 DevOps 工具层出不穷的今天，我们认为 CNCF 、开源代表了先进的生产力，这也是我们想做 DevOps Tool Manager 的初衷：灵活性。

在不久的将来，对于已经到达 1 的团队，或许在后续的学习实践中会发现某个工具能进一步的提升自己的生产力，但比如由于某云厂商 code pipeline 的限制，不能把最先进的工具整合进来以提升效率。对于这种场景，我们希望 DevStream 可以轻松的修改一端配置然后一个简单的 apply 即可完成"热插拔"。DevOps 跟前端一样，新产品新工具新框架层出不穷，要想时刻保持最先进的生产力，就需要对工具、方法进行不断的学习和试错，不断的整合、改善自己现有的 SDLC 流程。DevStream 希望能为大多数拥抱开源的开发者团队减少一些 overhead ，让他们能够更快速更轻易的达成这一目的。

至于您所说的 pipeline 本来就是 code ，没必要再 as code 一次，这个我个人非常认可。我们并不是单纯的想把某条 CI pipeline as code （虽然看起来目前 v0.1 版本支持的几个插件的确是这么做的，但目前 DevStream 只是一个 minimum viable product ，不是我们的最终目标）。实际上 DevOps 是一个非常广阔的概念，包含了太多工具之外的最佳时间、mindset 、做事的哲学、团队的管理方式等等内容，这些内容不可能都由 DevStream 来承载，但作为一个 unopinionated 的开源工具，无疑我们想尽可能多的整合一些 DevOps 的最佳实践进来。

不知道您职业生涯项目中、包括个人项目中，个人的偏好、最常使用的工具有哪些？在使用过程中的痛点有哪些？如果可能，希望您能在不泄露个人信息的前提下不吝赐教，或许 DevStream 可以从中学习一二，走的更远。

祝好！