6.DevOps 和敏捷开发

康威定律⑮说：设计系统的组织，最终产生的设计等同于组织之内、之间的沟通结构。

因此，一个公司的前端、后端和数据库团队可能会倾向于使用三层架构。在很大程度上，应用程序的结构，是由组织沟通后产生。简而言之，形式是交流的产物。

在本文中，作者学习康威定律并应用到自己的组织。

以下为摘录:

传统的瀑布式开发模式已经为我们的应用程序定义一个特定的沟通结构：

开发开发人员让（QA）团队测试并质量保证，QA 让运维（OPS）团队去部署。

这种方式的沟通，是非敏捷的，加重了我们有缺陷的组织结构，这又是一个印证了康威定律的例子：组织结构决定产品。

阅读完整的文章， DevOps 和敏捷开发，请访问
post.cfm/devops-agile-317

7. DevOps 团队需要 ChatOps

项目团队关键利益相关者之间的对话（例如，开发人员、业务分析员、项目经理、安全团队），平台之间的沟通，可以对协作产生深远的影响。

较差的或甚至没有使用通讯工具，导致沟通不畅，重复的工作，或错误的实现。另一方面，开发和业务基础设施相结合的通信工具，可以加快向组织交付业务价值。

也就是说，一个团队如何组织基础设施结构，如何沟通，将直接影响团队的效率。

在文章 DevOps 团队需要 ChatOps 中，作者介绍了 ChatOps，DevOps 的一个分支，关注 DevOps 团队的沟通。

ChatOps 包括了团队的沟通和协作工具：通知、聊天服务器、机器人、问题跟踪系统等等。

以下为摘录:

在最近的一篇博客⑱中，作者写道，ChatOps，一词起源于GitHub上，都是关于基于对话的驱动开发方式：

“把你的工具带到您的沟通过程中，并使用一个聊天机器人修改关键的插件和脚本工作，团队可以自动执行任务和协作工作，使工作更好、更便捷、更快”。Sigler写道。

大多数团队在聊天服务器上都有一定程度的合作。聊天服务器可以作为一个城市广场一样容纳开发团队、促进团队之间的凝聚力、讨论实际问题以及潜在解决方案等。

我们希望所有的团队成员使用聊天服务器。在我们的团队中，为了避免一般聊天室的灌水聊天，我们也创建专用聊天室，每个项目，项目团队成员可以谈论项目的细节，不涉及其他的团队：

和其他简单的沟通介质不一样，聊天服务器可以智能化，开发的基础设施，向团队传递通知，团队执行命令并反馈回基础设施。

我们的聊天服务器是通知的枢纽，与我们的基础设施快速互动：

项目团队通过聊天服务器接到通知（还有其他方法），关注基础设施任何生成状态，他们关注：构建失败、构建成功、超时等。

阅读完整的文章，DevOps团队需要ChatOps，请访问
post.cfm/chatops-in-devops-team-029

8.DevOps之Vagrant

环境等同⑲是一个理想的、令人充满期待的状态。缺乏环境等同会使软件开发陷入令人沮丧的困境。部署和开发都经常会陷入这样的陷阱，降低了稳定性、可预测性和生产力。

当环境不等同时，这使得故障难以排除，而且难以协作。这种缺乏环境等同使开发人员和运维人员负担太多。

在这篇博客中 DevOps 之 Vagrant ，作者描述了 Vagrant：

这是一个开发者使用的工具，提供了一个虚拟化和环境配置，Vagrant 为开发者提供了一个单一的，声明式脚本，以及一个简单的命令行界面。

通过使用相同的预先配置的 Vagrant 脚本，Vagrant 为所有开发者统一了线上的环境。在应用开发生命周期过程中，Vagrant 消除了“环境不同”的借口。

以下为摘录:

运维团队的作业通常包括在所有部署环境中实施全面的校验，例如用于测试、分段和上线。

相反，开发团队几乎完全自己负责配置开发机器。为了达到百分之100的环境等同，两个团队必须使用相同的语言，使用相同的资源。

Chef和Puppet，这两个都是为运维而生，对一个繁忙的开发人员来说可能不太友好。

Chef和Puppet都有一个比较陡的学习曲线，并没有真正解决环境等同的问题：

开发者仍然需要和线上环境同步。

所有这些额外的工作会带来一个相当大的开销，而开发者只想好好的写业务代码！

这就是Vagrant出现的意义。Vagrant是一个面向开发者的工具，基本上Vagrant提供了一个虚拟化环境，提供了一个单一的，声明式的脚本和一个简单的命令行界面。

Vagrant通过启动一个虚拟机（VM），去除繁重的工作，消除了人工配置或运行，例如，chef-server和chef-client。Vagrant的隐藏这一切，提供一个简单的脚本给开发人员，一个名叫Vagrantfile无扩展项文件，可随着代码签入到源代码控制。

阅读完整的文章，DevOps之Vagrant，请访问
post.cfm/devops-technologies-vagrant-345

9.使用DevOps解决上下文切换的不利影响

在计算系统中，上下文切换发生在：

操作系统保存一个应用程序线程的状态，停止线程并恢复其他线程的状态（之前停止线程），使其他线程恢复执行。

上下文切换管理的开销，发生在处理状态的保存和恢复，这个过程会对操作系统产生负荷，并影响应用程序的性能。

在博客使用DevOps解决上下文切换的不利影响中，CERT研究员Todd Waits描述了如何使用DevOps改善负面影响，减少项目之间的“上下文切换”对软件工程团队效率的影响。

以下为摘录:

Quality Software Management: Systems Thinking⑳, 作者在这本书中讨论了，上下文切换的概念是如何适用于一个工程团队。

从人力劳动力的角度来看，上下文切换是一个项目停止工作的过程，并在不同的项目上完成不同的任务后，将其重新捡起来。就像计算机系统一样，在多个项目之间进行上下文切换时，团队成员通常会产生开销。

当团队成员被分配到多个项目时，上下文切换通常会发生。上下文切换的合理理由是：

逻辑上来讲，为团队成员分配项目任务，比为每个项目分配专用资源更省时省力。

这似乎是合理的假设，将一个人的精力平分，对每个项目，两者之间的项目收益率百分之50。

此外，如果一个团队成员只在一个单独的项目中，如果这个项目正在等待处理某些事情，比如等待书面工作审批、审查等，该小组成员将是空闲的，没有充分利用。

使用我们计算系统的隐喻，任务之间的切换类似多线程概念，如果一个线程因为某些事情阻塞，其他线程可以执行其他工作，而不是等待第一个线程直到恢复。

如果所有的工作只分配给第一个线程，进展很慢。虽然多线程在计算系统中很合理，问题是，人类并不总是能很好分配精力。因此效率会在上下文切时损失，生产力可能会在精力分散在更多的项目的时候下降。

阅读完整的文章，使用 DevOps 解决上下文切换的不利影响，请访问
post.cfm/addressing-detrimental-effects-context-switching-devops-064

10.什么是 DevOps？

通常，当我们设想一个实现了 DevOps 的组织，我们可以想象一个自动化运转良好的机器：

·         基础设施配置

·         代码测试

·         应用部署

最终，这些做法的结果是运用DevOps的方法和工具。DevOps适合所有规模的团队，从一个一个人的团队到一个企业组织。在这篇博文中，什么是DevOps，CERT研究员Todd Waits介绍了DevOps的基础。

DevOps可以看作是敏捷方法的推广。它要求掌握相当多的知识和技能，包括一个项目从开始到持续，到被一个专门的项目小组负责。组织壁垒必须打破。只有这样才能有效地缓解项目风险。

以下为摘录:

然而严格来说，DevOps 并不是持续集成，交付或部署。

DevOps 的做法能使团队达到协调，理解必要的自动化基础设施、测试和部署。特别是，DevOps 提供了组织如何保证：

·         不同项目团队人员之间的合作；

·         基础设施即为代码；

·         自动化任务、过程和工作流程；

·         监控应用和基础设施。

商业价值驱动 DevOps 的发展。如果没有 DevOps 的心态，组织经常发现他们的运维、开发和测试团队，目光短浅，只致力于创建方便自己的基础设施、测试套件或产品增量。

一旦一个组织打破了这些孤岛，把这些领域的专业知识整合起来，就可以把重点放在共同致力于提供商业价值的基本目标上：

组织良好的团队会发现（或创建）工具和技术，使他们的组织实践 DevOps。每个组织都是不同的，有不同的需求，不同的但是必须满足的需求。

DevOps 的关键，并不是一个杀手级的工具或脚本，而是合作文化和传递价值的终极承诺。

·         （王鹏（翻译）

·         高浩淼（整理&发布）

）

6.DevOps 和敏捷开发

康威定律⑮说：设计系统的组织，最终产生的设计等同于组织之内、之间的沟通结构。

因此，一个公司的前端、后端和数据库团队可能会倾向于使用三层架构。在很大程度上，应用程序的结构，是由组织沟通后产生。简而言之，形式是交流的产物。

在本文中，作者学习康威定律并应用到自己的组织。

以下为摘录:

传统的瀑布式开发模式已经为我们的应用程序定义一个特定的沟通结构：

开发开发人员让（QA）团队测试并质量保证，QA 让运维（OPS）团队去部署。

这种方式的沟通，是非敏捷的，加重了我们有缺陷的组织结构，这又是一个印证了康威定律的例子：组织结构决定产品。

阅读完整的文章， DevOps 和敏捷开发，请访问
post.cfm/devops-agile-317

7. DevOps 团队需要 ChatOps

项目团队关键利益相关者之间的对话（例如，开发人员、业务分析员、项目经理、安全团队），平台之间的沟通，可以对协作产生深远的影响。

较差的或甚至没有使用通讯工具，导致沟通不畅，重复的工作，或错误的实现。另一方面，开发和业务基础设施相结合的通信工具，可以加快向组织交付业务价值。

也就是说，一个团队如何组织基础设施结构，如何沟通，将直接影响团队的效率。

在文章 DevOps 团队需要 ChatOps 中，作者介绍了 ChatOps，DevOps 的一个分支，关注 DevOps 团队的沟通。

ChatOps 包括了团队的沟通和协作工具：通知、聊天服务器、机器人、问题跟踪系统等等。

以下为摘录:

在最近的一篇博客⑱中，作者写道，ChatOps，一词起源于GitHub上，都是关于基于对话的驱动开发方式：

“把你的工具带到您的沟通过程中，并使用一个聊天机器人修改关键的插件和脚本工作，团队可以自动执行任务和协作工作，使工作更好、更便捷、更快”。Sigler写道。

大多数团队在聊天服务器上都有一定程度的合作。聊天服务器可以作为一个城市广场一样容纳开发团队、促进团队之间的凝聚力、讨论实际问题以及潜在解决方案等。

我们希望所有的团队成员使用聊天服务器。在我们的团队中，为了避免一般聊天室的灌水聊天，我们也创建专用聊天室，每个项目，项目团队成员可以谈论项目的细节，不涉及其他的团队：

和其他简单的沟通介质不一样，聊天服务器可以智能化，开发的基础设施，向团队传递通知，团队执行命令并反馈回基础设施。

我们的聊天服务器是通知的枢纽，与我们的基础设施快速互动：

项目团队通过聊天服务器接到通知（还有其他方法），关注基础设施任何生成状态，他们关注：构建失败、构建成功、超时等。

阅读完整的文章，DevOps团队需要ChatOps，请访问
post.cfm/chatops-in-devops-team-029

8.DevOps之Vagrant

环境等同⑲是一个理想的、令人充满期待的状态。缺乏环境等同会使软件开发陷入令人沮丧的困境。部署和开发都经常会陷入这样的陷阱，降低了稳定性、可预测性和生产力。

当环境不等同时，这使得故障难以排除，而且难以协作。这种缺乏环境等同使开发人员和运维人员负担太多。

在这篇博客中 DevOps 之 Vagrant ，作者描述了 Vagrant：

这是一个开发者使用的工具，提供了一个虚拟化和环境配置，Vagrant 为开发者提供了一个单一的，声明式脚本，以及一个简单的命令行界面。

通过使用相同的预先配置的 Vagrant 脚本，Vagrant 为所有开发者统一了线上的环境。在应用开发生命周期过程中，Vagrant 消除了“环境不同”的借口。

以下为摘录:

运维团队的作业通常包括在所有部署环境中实施全面的校验，例如用于测试、分段和上线。

相反，开发团队几乎完全自己负责配置开发机器。为了达到百分之100的环境等同，两个团队必须使用相同的语言，使用相同的资源。

Chef和Puppet，这两个都是为运维而生，对一个繁忙的开发人员来说可能不太友好。

Chef和Puppet都有一个比较陡的学习曲线，并没有真正解决环境等同的问题：

开发者仍然需要和线上环境同步。

所有这些额外的工作会带来一个相当大的开销，而开发者只想好好的写业务代码！

这就是Vagrant出现的意义。Vagrant是一个面向开发者的工具，基本上Vagrant提供了一个虚拟化环境，提供了一个单一的，声明式的脚本和一个简单的命令行界面。

Vagrant通过启动一个虚拟机（VM），去除繁重的工作，消除了人工配置或运行，例如，chef-server和chef-client。Vagrant的隐藏这一切，提供一个简单的脚本给开发人员，一个名叫Vagrantfile无扩展项文件，可随着代码签入到源代码控制。

阅读完整的文章，DevOps之Vagrant，请访问
post.cfm/devops-technologies-vagrant-345

9.使用DevOps解决上下文切换的不利影响

在计算系统中，上下文切换发生在：

操作系统保存一个应用程序线程的状态，停止线程并恢复其他线程的状态（之前停止线程），使其他线程恢复执行。

上下文切换管理的开销，发生在处理状态的保存和恢复，这个过程会对操作系统产生负荷，并影响应用程序的性能。

在博客使用DevOps解决上下文切换的不利影响中，CERT研究员Todd Waits描述了如何使用DevOps改善负面影响，减少项目之间的“上下文切换”对软件工程团队效率的影响。

以下为摘录:

Quality Software Management: Systems Thinking⑳, 作者在这本书中讨论了，上下文切换的概念是如何适用于一个工程团队。

从人力劳动力的角度来看，上下文切换是一个项目停止工作的过程，并在不同的项目上完成不同的任务后，将其重新捡起来。就像计算机系统一样，在多个项目之间进行上下文切换时，团队成员通常会产生开销。

当团队成员被分配到多个项目时，上下文切换通常会发生。上下文切换的合理理由是：

逻辑上来讲，为团队成员分配项目任务，比为每个项目分配专用资源更省时省力。

这似乎是合理的假设，将一个人的精力平分，对每个项目，两者之间的项目收益率百分之50。

此外，如果一个团队成员只在一个单独的项目中，如果这个项目正在等待处理某些事情，比如等待书面工作审批、审查等，该小组成员将是空闲的，没有充分利用。

使用我们计算系统的隐喻，任务之间的切换类似多线程概念，如果一个线程因为某些事情阻塞，其他线程可以执行其他工作，而不是等待第一个线程直到恢复。

如果所有的工作只分配给第一个线程，进展很慢。虽然多线程在计算系统中很合理，问题是，人类并不总是能很好分配精力。因此效率会在上下文切时损失，生产力可能会在精力分散在更多的项目的时候下降。

阅读完整的文章，使用 DevOps 解决上下文切换的不利影响，请访问
post.cfm/addressing-detrimental-effects-context-switching-devops-064

10.什么是 DevOps？

通常，当我们设想一个实现了 DevOps 的组织，我们可以想象一个自动化运转良好的机器：

·         基础设施配置

·         代码测试

·         应用部署

最终，这些做法的结果是运用DevOps的方法和工具。DevOps适合所有规模的团队，从一个一个人的团队到一个企业组织。在这篇博文中，什么是DevOps，CERT研究员Todd Waits介绍了DevOps的基础。

DevOps可以看作是敏捷方法的推广。它要求掌握相当多的知识和技能，包括一个项目从开始到持续，到被一个专门的项目小组负责。组织壁垒必须打破。只有这样才能有效地缓解项目风险。

以下为摘录:

然而严格来说，DevOps 并不是持续集成，交付或部署。

DevOps 的做法能使团队达到协调，理解必要的自动化基础设施、测试和部署。特别是，DevOps 提供了组织如何保证：

·         不同项目团队人员之间的合作；

·         基础设施即为代码；

·         自动化任务、过程和工作流程；

·         监控应用和基础设施。

商业价值驱动 DevOps 的发展。如果没有 DevOps 的心态，组织经常发现他们的运维、开发和测试团队，目光短浅，只致力于创建方便自己的基础设施、测试套件或产品增量。

一旦一个组织打破了这些孤岛，把这些领域的专业知识整合起来，就可以把重点放在共同致力于提供商业价值的基本目标上：

组织良好的团队会发现（或创建）工具和技术，使他们的组织实践 DevOps。每个组织都是不同的，有不同的需求，不同的但是必须满足的需求。

DevOps 的关键，并不是一个杀手级的工具或脚本，而是合作文化和传递价值的终极承诺。

·         （王鹏（翻译）

·         高浩淼（整理&发布）

）