我跟你打赌。告诉我你的开发和运营团队如何合作,我就能告诉你你的CI/CD 管道是什么样的。这是因为 CI/CD 是康威定律最纯粹的表达。你的 CI/CD 管道会像你的工程组织一样支离破碎、杂乱无章。这就是你得到这样的“管道”的方式:好吧,也许这有点夸张(不过,根据我在大型企业的经验,并没有太多夸张)。但另一方面肯定是正确的:一旦你沟通正确,你就可以开始看到你一直希望从 CI/CD 中获得的好处。不相信吗?让我给你展示一些模式。冷战请记住,CI/CD 管道的存在是为了通过自动化手动步骤和提高对发布的信心,平滑和加速从开发到运营和 QA 再到生产的代码流。这与许多大型组织仍在实行的瀑布式发布方法完全相反,在这种方法中,开发人员将代码“扔过墙”给运营。开发人员无法访问生产环境,而运维人员对代码的工作原理没有太多内部了解。我们把这称为“冷战”模式:一个冷战组织竟然会考虑实施 CI/CD,这有点令人惊讶。但是他们和其他人一样,可能会到处使用这个流行词。当新的自动化系统崩溃时,除了增加手动劳动之外,还会导致额外的管理开销。基本上,只是带有额外步骤的旧瀑布流程。如果不清除组织中的隔阂,就无法清除发布流程中的隔阂。Gumbo嗯,gumbo。在冷战中,运维人员往往会抑制开发速度,而 Gumbo 组织则是开发人员活动的狂热沼泽。您会在很多成长中的初创公司中看到这种情况。工程团队变得过于庞大,无法维持简单的发布流程,随之而来的是混乱。如果没有明确的安全指南或针对开发人员的云操作培训,很容易就会因为草率的配置更新而导致生产中断或暴露 S3 存储桶。如果说冷战是非连续集成,那么这更像是连续解体。聪明的人在混乱中工作。一些优秀的 CI/CD 管道可能浮在水面之下。但是没有办法在整个公司内发现和分享这些知识。幸运的是,混乱阶段非常不稳定,没有人会误以为这是好事,因此组织很快就会凝聚成...... The BlobBlob 的凝聚状态比冷战或秋葵汤要成熟得多。有人意识到“我们需要标准!指南!一个工具来统治它们——这将阻止这种疯狂!”因此,他们成立了一个由手头最好的基础设施工程师组成的中央 DevOps 团队。中央团队创建了一个每个人都应该使用的管道基础设施。这可能就像一个共享的 Jenkins 实例一样简单。它可能像链接到一系列动态 CodePipeline 模板的 AWS 账户自动售货机一样复杂。但其他团队会真正使用中央管道吗?有些会!他们会发现他们的用例非常适合通用解决方案,并被吸收到 blob 中。然而,其他团队会发现他们的应用程序需要不同的方法。他们会不理想地使用中央解决方案,或者更糟的是,忽略它并启动他们自己的秘密 CI/CD 解决方法——在 blob 本身的阴影下影子 IT 。保护伞Blob 希望您认为这是成功的唯一途径。这就是 blob 的力量,为什么这么多团队无限期地陷入其中。但 blob 错了。成熟的组织最终会实现的目标(不仅仅是在 CI/CD 方面,而且在一般的云采用方面)是让各个团队按照自己的方式取得成功,同时仍为他们提供所需的护栏和培训,以满足组织的云卓越标准。这意味着要有一个中央架构委员会和一个安全团队来制定明确的指导方针——我最近与一位 ACG 客户交谈时,他们称之为“云不可协商”。这意味着将您的云专家嵌入产品团队中,这些产品团队需要实际支持才能从云新手过渡到专家。是的,这意味着确保每个人都通过培训和认证使用相同的云语言。您可以将其称为伞状模式。每个产品团队都不同:云流畅度伞状模式涵盖了所有团队。现在我要打赌:我是否描述了您的组织?或者您看到了其他模式?在 Twitter 上联系我,让我们继续对话。 ACG for Business 可帮助您组织中的每个人都使用云语言,以便您可以打破障碍并更快地创造价值。 免责声明:本内容来源于第三方作者授权、网友推荐或互联网整理,旨在为广大用户提供学习与参考之用。所有文本和图片版权归原创网站或作者本人所有,其观点并不代表本站立场。如有任何版权侵犯或转载不当之情况,请与我们取得联系,我们将尽快进行相关处理与修改。感谢您的理解与支持! 查看原文
我跟你打赌。告诉我你的开发和运营团队如何合作,我就能告诉你你的CI/CD 管道是什么样的。这是因为 CI/CD 是康威定律最纯粹的表达。你的 CI/CD 管道会像你的工程组织一样支离破碎、杂乱无章。这就是你得到这样的“管道”的方式:好吧,也许这有点夸张(不过,根据我在大型企业的经验,并没有太多夸张)。但另一方面肯定是正确的:一旦你沟通正确,你就可以开始看到你一直希望从 CI/CD 中获得的好处。不相信吗?让我给你展示一些模式。冷战请记住,CI/CD 管道的存在是为了通过自动化手动步骤和提高对发布的信心,平滑和加速从开发到运营和 QA 再到生产的代码流。这与许多大型组织仍在实行的瀑布式发布方法完全相反,在这种方法中,开发人员将代码“扔过墙”给运营。开发人员无法访问生产环境,而运维人员对代码的工作原理没有太多内部了解。我们把这称为“冷战”模式:一个冷战组织竟然会考虑实施 CI/CD,这有点令人惊讶。但是他们和其他人一样,可能会到处使用这个流行词。当新的自动化系统崩溃时,除了增加手动劳动之外,还会导致额外的管理开销。基本上,只是带有额外步骤的旧瀑布流程。如果不清除组织中的隔阂,就无法清除发布流程中的隔阂。Gumbo嗯,gumbo。在冷战中,运维人员往往会抑制开发速度,而 Gumbo 组织则是开发人员活动的狂热沼泽。您会在很多成长中的初创公司中看到这种情况。工程团队变得过于庞大,无法维持简单的发布流程,随之而来的是混乱。如果没有明确的安全指南或针对开发人员的云操作培训,很容易就会因为草率的配置更新而导致生产中断或暴露 S3 存储桶。如果说冷战是非连续集成,那么这更像是连续解体。聪明的人在混乱中工作。一些优秀的 CI/CD 管道可能浮在水面之下。但是没有办法在整个公司内发现和分享这些知识。幸运的是,混乱阶段非常不稳定,没有人会误以为这是好事,因此组织很快就会凝聚成...... The BlobBlob 的凝聚状态比冷战或秋葵汤要成熟得多。有人意识到“我们需要标准!指南!一个工具来统治它们——这将阻止这种疯狂!”因此,他们成立了一个由手头最好的基础设施工程师组成的中央 DevOps 团队。中央团队创建了一个每个人都应该使用的管道基础设施。这可能就像一个共享的 Jenkins 实例一样简单。它可能像链接到一系列动态 CodePipeline 模板的 AWS 账户自动售货机一样复杂。但其他团队会真正使用中央管道吗?有些会!他们会发现他们的用例非常适合通用解决方案,并被吸收到 blob 中。然而,其他团队会发现他们的应用程序需要不同的方法。他们会不理想地使用中央解决方案,或者更糟的是,忽略它并启动他们自己的秘密 CI/CD 解决方法——在 blob 本身的阴影下影子 IT 。保护伞Blob 希望您认为这是成功的唯一途径。这就是 blob 的力量,为什么这么多团队无限期地陷入其中。但 blob 错了。成熟的组织最终会实现的目标(不仅仅是在 CI/CD 方面,而且在一般的云采用方面)是让各个团队按照自己的方式取得成功,同时仍为他们提供所需的护栏和培训,以满足组织的云卓越标准。这意味着要有一个中央架构委员会和一个安全团队来制定明确的指导方针——我最近与一位 ACG 客户交谈时,他们称之为“云不可协商”。这意味着将您的云专家嵌入产品团队中,这些产品团队需要实际支持才能从云新手过渡到专家。是的,这意味着确保每个人都通过培训和认证使用相同的云语言。您可以将其称为伞状模式。每个产品团队都不同:云流畅度伞状模式涵盖了所有团队。现在我要打赌:我是否描述了您的组织?或者您看到了其他模式?在 Twitter 上联系我,让我们继续对话。 ACG for Business 可帮助您组织中的每个人都使用云语言,以便您可以打破障碍并更快地创造价值。 免责声明:本内容来源于第三方作者授权、网友推荐或互联网整理,旨在为广大用户提供学习与参考之用。所有文本和图片版权归原创网站或作者本人所有,其观点并不代表本站立场。如有任何版权侵犯或转载不当之情况,请与我们取得联系,我们将尽快进行相关处理与修改。感谢您的理解与支持! 查看原文 云计算 软件开发 商业策略
请先 登录后发表评论 ~