devops 文化
组织在购买Trip-tik并规划其DevOps路线图的路径时应引起很多关注，但是绞尽脑汁养育DevOps文化并营造运营和开发团队之间的协作与交流环境并不是其中之一。他们。 如果有的话，那是浪费时间和DevOps反模式。
为什么“ DevOps包含文化和协作”是错误的
对于那些无能为力的人力资源团队精明的成员来说，弄清楚DevOps如何包含文化和协作是一个重要的话题，但是如果这样的讨论开始占用开发人员和工程师的时间，那将是有毒的。 这些人有真正的工作要做。
当有人提出“ DevOps包含文化和协作”时，我总是很快指出协作可能确实是其中的一部分，但不是积极的。 DevOps与加强协作无关。 DevOps与改善沟通无关。
当您正确地进行DevOps时，应该减少协作，而不是更多。 持续交付和持续集成 （CI / CD）（DevOps理念的核心原则）的重点是消除尽可能多的手动流程。 这意味着少交流而不是多交流。
尽管我确实鄙视所有有关开发和操作孤岛的讨论，但事实是，当我们正确使用诸如Chef，Jenkins，Docker和Git之类的DevOps工具时，人与人之间的互动应该减少。 如果我可以将Java应用程序包装在嵌入式Tomcat容器中，使用Docker进行构建并将其部署到云中，而运营团队中没有人让我填写表格或发送电子邮件，那么协作的需求实际上就消失了。 仅出于这个原因，“ DevOps包含文化和协作”的说法是一个完整而完全的误称。
还值得一提的是，如果您的组织确实存在协作和沟通问题，那就是人力资源问题，而不是技术问题。 不要责怪IT部门招聘经理的无能。
让我们揭穿虚假的DevOps文化神话
我之前曾揭穿过DevOps文化神话 ，但是对转换后的DevOps信奉者进行解密是一场永无止境的战斗。
有效的DevOps实践可能会对组织的文化产生长期影响，但是任何DevOps文化的变化都是结果，而不是采用该流程的前提条件。 每个DevOps传播者似乎都错误地理解了这个简单的概念，并且坦率地说，这令人困惑。
文化是由一群人通常执行的各种过程和程序定义的。 在阿姆斯特丹，人们倾向于骑自行车。 在乌克兰，居民似乎真的很喜欢白菜。 这些是文化特征。
为什么荷兰人骑自行车？ 这是因为阿姆斯特丹像煎饼一样平坦。 实际上，煎饼只希望它们像阿姆斯特丹一样平坦。 正是这种情况使骑自行车吸引了一小群纺车爱好者。 在乌克兰，卷心菜价格便宜且价格昂贵，因此以美味的卷心菜为主题的聚宝盆成为了聚宝盆。 没有人四处告诉阿姆斯特丹或乌克兰的人们，他们需要改变自己的文化，开始骑自行车和吃白菜。 既有条件决定文化模式。
同样的情况适用于DevOps文化。 抱怨某个组织需要改变其文化是没有头脑的，没有生产力。 如果DevOps确实包含文化和协作，那么它仅作为输出，而不是输入。 如果您想正确执行DevOps ，则正确的方法是专注于输入。 如果提供正确的输入，则将洗脱DevOps文化。
DevOps文化投入
那些产生DevOps文化的输入是什么？ 为开发人员提供他们喜欢的工具是一个开始。 如果允许开发人员使用像Git这样的分布式版本控制系统，该系统提供了独立运行并以隔离方式运行的功能，则他们更有可能一天多次检查代码。 如果您将诸如Apache Maven ， Jenkins CI或Atlassian Bamboo之类的构建工具尽早引入混合，那么运行连续代码质量例程将成为常态。 使用JIRA和Agile sprint之类的良好协作工具也将更加顺利。
组织提供按需云计算资源后，另一种重大的文化变化发生了。 传统上，运营团队将使开发人员跳入一堆箍，填写一堆表格，并等待更长的时间，然后再提供原型环境或沙盒服务器。 如果可以根据需要提供基于云的资源，那么就可以节省时间，减少资源获取过程。 这导致文化改变。
而且这种省时的，破坏筒仓的流程可以追溯到DevOps哲学的根源。 毕竟，当开发人员开始使用按需云计算资源来提供自己的容器托管服务时，在开发与运营之间的界限究竟发生在哪里？ 开发和运营的融合是使用正确的工具并围绕它们构建正确的流程的结果。 这就是DevOps的全部意义，也是“ DevOps包含文化和协作”的唯一方式。
DevOps涵盖了文化和协作：对还是错？
不要接受虚假的DevOps文化神话，也不要接受DevOps团队进行更好的协作和沟通的呼吁。 那些是初学者的谈话要点。 安置在他们身上的预言家应该被解雇。 铺平道路，引入开发人员和运营团队喜欢的工具，同时使按需资源比乌克兰的白菜更丰富。 如果这样做，事情将会开始改变。
如果您想正确执行DevOps，请专注于输入，而不是输出。
devops 文化
6205
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
