IronCore864 最近的时间轴更新 IronCore864 最近的时间轴更新 |
IronCore864V2EX 第 570110 号会员，加入于 2022-01-25 11:47:38 +08:00 |
IronCore864 最近回复了
2022-03-03 23:12:03 +08:00 回复了 Benker 创建的主题 › 分享发现 › 玩转 DevOps 工具链从未如此简单，开源项目 DevStream v0.1.0 Release 可以尝尝鲜 |
@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 可以从中学习一二，走的更远。
祝好！
能看出您对于无论是 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 可以从中学习一二，走的更远。
祝好！
2022-03-03 11:49:49 +08:00 回复了 Benker 创建的主题 › 分享发现 › 玩转 DevOps 工具链从未如此简单，开源项目 DevStream v0.1.0 Release 可以尝尝鲜 |
@Taiga 很好的问题！
这其实是一个是否要把配置作为 Single Source of Truth (SSoT)的问题。
可能对于有些工具而言这么做没问题，但有些工具这么做可能就会带来问题：比如你举的例子，如果不允许我手动 git commit 来修改 pipeline 我觉得很肉疼。。。
所以可能最终的实现还是要看负责那个工具的插件的实现。到底哪些插件适合做成 SSoT? 这个问题可能让插件的使用者来回答比较具有说服力。
所幸的是，某个插件是否要做成 SSoT ，DevStream 都是支持的。
这其实是一个是否要把配置作为 Single Source of Truth (SSoT)的问题。
可能对于有些工具而言这么做没问题，但有些工具这么做可能就会带来问题：比如你举的例子，如果不允许我手动 git commit 来修改 pipeline 我觉得很肉疼。。。
所以可能最终的实现还是要看负责那个工具的插件的实现。到底哪些插件适合做成 SSoT? 这个问题可能让插件的使用者来回答比较具有说服力。
所幸的是，某个插件是否要做成 SSoT ，DevStream 都是支持的。
Select Language