‧ 你需要选择一个地方来存放代码，也许是 GitHub，也许是 GitLab；
‧ 你需要一个工具来完成项目管理或需求管理、Issue 管理等等工作，也许你会选择 Jira 或者禅道或 Trello；
‧ 你需要选择一种开发语言，选择一个开发框架，比如你决定用 Golang 来开发，假如这是一个 web 项目，你需要考虑 web 框架用什么？“第一行”代码怎么写，也就是第一个脚手架怎么组装；
‧ 然后你需要配置一些 CI 自动化，比如 GitHub 上添加 actions 来完成代码的扫描、测试等等；
‧ 当然 CD 工具也不能少，不管你选择 Jenkins 还是 ArgoCD；
‧ 如果 CD 完成了，接下来可能你马上要开始纠结日志、监控、告警等等方案应该怎么定了
‧ 如果想得更多，或许你希望 GitHub 上别人给你提的 issue 能够自动同步到你的 Jira 或者 Trello……
也许上面的例子并不完全准确，但是有一个结论我们必须接受：在一个软件的开发生命周期中，除了业务代码编码本身，在 DevOps 工具链上我们需要花费大量精力去选型、打通、落地、维护。
我们可以选择在某个云厂商手里购买一个一站式 DevOps 解决方案，只要钱够，基本就不用操心运维的问题了。
这时候你可能会遇到的最大的问题就是“灵活性”不足。云厂商大概率不会愿意为了你的定制化需求去修改“一站式 DevOps”里的任何一个环节。比如你觉得自己公司的持续集成环节特别牛，但是怎么集成进去呢？
当然“钱够”也只是一个假设，或许最大的问题是“没钱”。
我们也可以选择开源的 DevOps 工具，自己落地，搭建一条灵活的工具链，只要有足够的人力来维护（可能需要几个很资深的工程师才能玩转整条工具链）。这时候可能会遇到的最大问题就是人力和经验不足。要自己搞清楚每个环节的“最佳实践”并不是一件容易的事情。免费、灵活，但是落地难，维护难，这也不是最佳方案。
我们既想要有开源 DevOps 工具链的灵活性，可以自由组合、替换其中任意工具；也想要有一站式 DevOps PaaS 服务的便利性，不用自己投入人力物力去研究，去慢慢落地。
那么，还有第三种选择，就是一个能够“自动化管理开源 DevOps 工具链”的工具，让它来实现一个“节约人力”又“灵活高效”的 DevOps 平台。
没错，DevStream 做的就是这件事：解决开源 DevOps 工具落地的难点，搞定开源 DevOps 工具链之间打通的痛点，解放研发团队的生产力，让大家少在 DevOps 工具上踩坑，腾出更多的精力在自己的业务逻辑上。
‧ 缺陷、需求管理 - Trello (集成 GitHub)
‧ 源码管理 - Golang 脚手架生成
‧ CI 流程 - Golang、Python、Nodejs
‧ CD / GitOps - ArgoCD / ArgoCD App
‧ Monitoring - kube-prometheus
‧ ……
当然当你打开 DevStream 的 GitHub 主页时，或许会发现 v0.2.0 或者更新版本已经发布了，那么不需要犹豫，请下载体验最新版本，让历史成为历史。
👇 DevStream Demo 视频
或许用不了多久，我们就能完整实现 『DevOps toolchain as code』，届时你的整个 DevOps 工具链都能以 DevStream 作为唯一入口来运维，dtm(DevStream 命令行工具)将成为你的整条 DevOps 工具链的 『single source of truth』。当然那时你需要替换整个 DevOps 工具链中的某一个环节，也会变得很简单。
其实目前我们已经部分实现 『single source of truth』，部署好的工具发生的部分变更已经能够被 dtm 感知到，并且 dtm 会判断这种变更是否合理，是否需要修复，进而采取相应的动作让整个 DevOps 工具链变得更可靠。
当然，DevStream 的发展离不开社区用户的支持，DevStream 欢迎所有人参与社区建设，一起完善 dtm 的功能，让 dtm 越来越强大！
如果您对 DevStream 项目感兴趣，点击文末『阅读全文』跳转 GitHub， README 里有更加详细的介绍。欢迎大家下载、体验、捉虫、提 Issue、挑刺、bugfix 等等等等。
如果您有任何建议或疑问，可以在公众号会话回复『DevStream』加入Discord（英文）或微信群（中文），与 DevStream 开发者沟通。
助力每一位开发者创造更多价值
EMPOWER EVERY DEVELOPER TO BUILD BETTER