DevStream v0.1.0 发布，玩转 DevOps 工具链从未如此简单

最新推荐文章于 2024-08-06 05:18:30 发布

思码逸研发效能

最新推荐文章于 2024-08-06 05:18:30 发布

阅读量1.1k

点赞数

文章标签：研发效能

本文链接：https://blog.csdn.net/simayi2018/article/details/123533994

版权

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

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

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

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

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

一站式平台 vs 开源工具链

我们可以选择在某个云厂商手里购买一个一站式 DevOps 解决方案，只要钱够，基本就不用操心运维的问题了。

这时候你可能会遇到的最大的问题就是“灵活性”不足。云厂商大概率不会愿意为了你的定制化需求去修改“一站式 DevOps”里的任何一个环节。比如你觉得自己公司的持续集成环节特别牛，但是怎么集成进去呢？当然“钱够”也只是一个假设，或许最大的问题是“没钱”。

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

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

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

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

DevStream v0.1.0 目前能做什么？

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

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

能不能更直观一点？

👇 DevStream 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 工具链变得更可靠。