更频繁地发布可以带来更好的开发和更好的运营

作为一家公司，我们做出的最重要的决定之一就是减少发布软件的次数，而要增加发布次数。 上线之后，我们尝试按季度交付更新，因为在此之前，我们遵循分阶段交付生命周期来构建系统，并预先进行了分析和架构，并在3个月的阶段中完成了设计，开发和测试。 但是一旦系统运行，这种方法就行不通了。 随着更多客户的反馈，我们的工作重点在不断变化，有太多事情需要立即修复或调整，我们不得不处理紧急的运营问题。 我们一直中断开发以部署临时发行版和补丁程序，然后重新计划和重新计划，这浪费了每个人的时间，并使跟踪我们需要做的工作变得更加困难。 开发人员和操作人员忙于吸引客户并进行灭火，这意味着我们无法在需要时进行更改。 所以我们决定
将发布周期从3个月缩短到1个月，然后再将发布周期缩短到3周再到2周，从而使发布更小，更集中并且更易于管理。

更小，更频繁的发布会改变开发方式

无论您是为了减少上市时间并在启动中获得快速反馈，还是要控制企业中的风险并管理变更，交付的次数减少但频率更高，这迫使您重新考虑如何开发软件。 它改变了您计划和估计的方式，以及您如何考虑风险以及如何管理风险。 它会更改您的设计方式以及需要执行的设计量。 它改变了您的测试方式。 它改变了人们所需的工具，以及他们需要多少工具。 它会改变您的优先级。 它改变了人们合作的方式以及他们与客户合作的方式，创造了更多的机会和更多的彼此交谈和相互学习的理由。 它改变了人们思考和采取行动的方式–因为他们必须以不同的方式思考和采取行动，以保持并继续做好工作。

更小，更频繁的发行版改变了Development和Ops协同工作的方式

更改发布和部署的频率也将更改操作的工作方式以及开发人员和操作一起工作的方式。 没有足够的时间进行大量会议和文书工作来进行重量级发布管理和变更控制。 您需要一种更轻松，更便宜的方法。 但是，更频繁地改变事物也意味着更多犯错的机会。 因此，您需要一种可以降低风险并尽早发现问题的方法。

一年左右发布一次软件的开发团队通常不会花费大量时间来考虑发布，部署和操作方面的事情，因为他们不必这样做。 但是，如果他们每两周部署一次，如果他们不断地推出软件，那么花些时间了解生产的实际情况并简化部署和回滚就很有意义。他们和操作更容易。

您不必使所有事情都自动化，也可以不这样做，除非您对问题有足够的了解。 我们从检查清单和脚本，手动配置和手动系统测试开始。 我们将所有内容置于源代码控制下（不仅仅是代码），然后开始标准化和自动化部署和配置以及回滚步骤，以自动审核的命令和运行状况检查代替手动工作和检查清单。 我们已经从手动服务器设置和修补转向使用Puppet管理基础架构。 我们仍将测试与生产保持一致，以便我们可以通过更少的生产特定更改来更频繁地测试更多部署步骤。 我们仍然没有一键式部署，也许永远也不会，但是今天发布和部署更简单，更标准化，更安全，更便宜。

部署仅仅是开始

改善部署仅仅是对话的开始 ，对话可以扩展到其他操作。 因为他们之间的合作越来越频繁，所以开发人员和操作人员将彼此了解更多，并开始了解彼此的语言以及优先级和问题。 为此，我们鼓励人们阅读Visible Ops，并派遣Ops和测试人员以及一些开发人员甚至经理参加ITIL Foundation培训，以便我们都了解事件管理与问题解决之间的区别以及如何进行RCA，以及适当的变更管理的重要性–可能是过大了，但它使我们所有人都对运营进行了思考，并予以认真对待。 每当遇到严重问题时，我们都会将开发人员，测试人员和操作人员聚集在一起，以计划和审核版本，并在RCA中为生产提供支持，并且我们共同努力找出问题出在哪里以及如何防止发生错误再次。 开发人员和操作人员配对以调查和解决操作问题，并改善我们设计和推出新体系结构的方式，以及如何保护我们的系统以及如何设置和管理开发与测试环境

听起来很简单。 不是。 花费了一段时间，并且出现了分歧，问题和退步，就像您从根本上改变人们的工作方式的任何时候一样。 但是，如果您做对了，那么人们将开始建立联系并建立关系，并最终在各个组之间建立信任和透明性-这就是Devops真正的目的 。

您不必更改组织结构或检查文化—在大多数情况下，无论如何您都没有这种职责。 您不必购买持续部署甚至持续交付 ，也不必购买基础架构作为代码 ，也不必使用Chef或Puppet或任何其他Devops工具 -尽管这些工具确实可以帮助您。 一旦您开始更快地移动，从每几个月一次一次的部署到每月一次一次，并且随着组织的发展步伐的加快，人们将不得不改变工作方式。

今天，我们的工作方式以及我们对开发和运营的思考方式已经大不相同，而且绝对健康。 我们可以更快地响应业务变化和问题，与此同时，我们的可靠性记录也得到了显着改善。 我们并未打算“敏捷”-直到我们要缩短发布周期时，我们才更加仔细地研究了Scrum和XP以及后来的看板，以了解这些方法如何帮助我们开发软件。 而且，我们也没有尝试“开发Devops”-在人们开始在Velocity以及其他任何地方谈论这些想法之前，我们已经在寻求更好的开发和操作协作方面。 作为一家公司，我们所做的一切都是同意更改公司将软件投入生产的频率。 这一切都与众不同 。

参考：在Building Real Software博客上， 发布更多频率可以带来更好的开发和更好的操作 ，这些是我们JCG合作伙伴 Jim Bird的。

翻译自: https://www.javacodegeeks.com/2013/02/releasing-more-often-drives-better-dev-and-better-ops.html