devops部署_Devops使发布和部署变得很酷

devops部署

回到十年前，当极限编程问世时，它开始改变程序员思考测试的方式。 XP使软件开发人员对测试自己的代码负责。 XPers为程序员提供了诸如“ 测试优先开发”之类的实践，以及简单，免费的基于社区的自动化测试工具，例如xUnit和FIT和Fitnesse 。

XP使测试变得很酷。 程序员开始关心如何编写良好的自动化测试以及实现高水平的测试代码覆盖率，并开始关注从测试和持续集成中优化反馈循环。 程序员没有将代码扔给测试团队，而是开始负责审阅和测试自己的代码并确保其确实有效。 这花费了一些时间，但是其中大多数想法已经成为主流，并且对软件开发和软件质量产生了积极影响。

现在，Devops在发布和部署上也做同样的事情。 人们正在寻找新的方法来简化和简化软件的发布和部署，使用更好的工具，并使开发人员和运营人员共同完成此任务。

这是一件好事。 因为开发人员已经忽略了发布和部署，甚至可能不仅仅是测试。 它留到了最后，因为这是您要做的最后一件事–在一些大型的串行生命周期项目中，您可以花数月的时间设计和开发某些东西，然后才能发布代码。 发布和部署非常困难-它涉及各种复杂的技术细节和检查。 为此，您必须了解系统的各个部分的布局方式，并且需要了解系统的技术平台和操作环境，以及Ops如何需要对系统进行设置和监视，以及他们如何连接系统，他们使用什么工具，这些工具如何工作，以及如何通过操作依赖性，合规性和治理要求来工作。 您必须以不同的语言与不同的人交谈，学习并关心他们的需求和痛点。 很难做到所有这些正确的事情，并且很难对其进行测试，并且您承受着将系统淘汰的压力。 为什么不只给Ops JAR和EAR，WAR和ZIP（以及您的电话号码，以防万一出现问题）并让他们弄清楚呢？ 我们回到将代码再次扔到墙上。

Devops通过使开发人员和运营人员一起工作，共享技术和解决问题的方式，正在改变这种状况。 这使得开发人员以及像我这样的开发经理更加关注发布和部署（以及部署后）的要求。 不只是完成它。 让开发人员以及质量保证和运营人员共同思考如何使发布，部署和配置变得更简单，更快捷，可能出问题的地方，然后确保对于每个版本都不会出问题–不只是在存在发行版时问题或Ops抱怨。 用自动步骤替换清单和说明。 添加发布后的健康检查。 在持续集成到持续交付的基础上 ，使其更容易，更安全，更便宜地发布到测试和生产环境。 这是所有实际的，具体的工作，对于试图更快地设计和构建软件的团队来说，这是自然而然的下一步。

XP和Devops故事之间的区别是，与敏捷开发初期相比，Devops中的供应商支持更多。 带有Chef和Puppet和UrbanCode（已将其Anthill Pro构建和发布工具集重新命名为DevOps平台的产品）等产品的商业供应商，以及带有Go的 ThoughtWorks Studios，甚至IBM和HP也参与了Devops并推动Devops的构想向前发展。

这是好是坏。 很好–因为这意味着人们可以使用某些工具，并且可以帮助人们了解如何使用它们的人们。 有人可以协助赞助会议和其他活动，使人们聚在一起探讨Devops问题。 不好，因为要了解和欣赏Devops中发生的事情和真正有用的内容，您必须克服越来越多的营销噪音。 现在说真正的思想领袖和传道者是否会被供应商产品经理和顾问淹没还为时过早，就像敏捷开发社区今天所面临的问题一样。

参考： Devops在Building Real Software博客上通过JCG合作伙伴 Jim Bird 使“发布和部署”变得很酷 。

相关文章 ：

• 无迭代开发–最新的新事物
• 软件开发和维护中的回报递减
• 为什么自动化测试可以提高您的开发速度
• 如何解决生产问题
• 生存在荒野西部开发过程中的9条提示

翻译自: https://www.javacodegeeks.com/2011/12/devops-has-made-release-and-deployment.html

devops部署