转载

软件交付的未来是编码

Spring创始人Rod大叔一直在和厂商派扳手腕，厂商派认为开发人员应该更关注业务，其他事情交给他们，这从Istio推出可以看出来，Istio认为Spring cloud里面那些服务发现、负载平衡等应该由第三方组件如Istio实现，但是Rod大叔代表的Spring派显然不是这种观点，所以推出Spring cloud，由开发人员通过yaml配置服务发现、配置服务器和负载平衡等，这是Rod他们理解的Devops意思，是开发人员干运维人员的事情，这次Rod大叔又发布文章，他的新产品Atomist可以把软件交付的配置变成编码，他认为YAML和Bash已经没有存在意义了，应该用更强大的代码替代。

我们为什么需要软件API？

由于Spring，Rails，Node和Spring Boot等框架不断发展的成就，在过去10到15年间我们编写的应用程序代码得到了极大的改进，我们在Kubernetes和Cloud Foundry时代的部署经验远离了WebSphere的恐怖世界，然而，两者之间最重要的差距 - 我们的软件如何交付到生产 - 并没有跟上步伐，我们也没有足够的日常自动化活动。

云原生部署的兴起以及传统单体的解体，使得现在问题日益明显，更多项目意味着更多的交付管道，带来大量重复和难以确定的交付策略，项目扩散暴露了缺乏自动化：例如，如何以一致的方式创建项目，使项目保持最新，并随时了解其中发生的事情。

是时候重新思考：对于软件交付和自动化应该实行战略调整而非只是战术方法微调。我们相信下面三大创意可以改善我们的交付和自动化体验：

1. 重新思考每个代码仓储的每个交付管道模型，将其替换为事件中心。当我们拥有少量大型应用程序时，每个仓储repo有一个管道是有意义的，每个应用程序都可以有一个复杂的特殊构建，但是在今天，数百甚至数千个应用程序是很常见的，这些应用程序的交付流程有很多共同之处，每个仓储一个管道已经变成错误的模型，事件中心能让团队在一个地方表达和演进，代码存储库上的活动会产生我们可以集中处理的事件。

2. 为我们的项目及其活动提供丰富的相关模型....

3. 拥抱现代编程语言的强大功能，在代码中定义传递和自动化。

真正的代码不是不自然的混合，自linux上编译方式make文件出现以来，我们倾向于在代码之外表达构建和交付步骤，作为程序员，就好像交付已经不是我们的工作，其实它是我们的工作，我们应该运用我们的核心技能。

每家公司都在从事软件交付业务，对于C这样低级语言使用简单的构建是可以的，这时使用非代码也就是配置是有意义的; 当表达复杂的交付流程时，YAML和Bash没有多大意义。

由于过去没有质疑这种方法，我们已经陷入了奇怪的状况，在YAML中定义变量，我们有OOP和FP，也有很好的命令式编程语言，但是YAML却不属于这些，在我们大多数人出生之前，Bash是当时接近最前沿的技术。

我们相信这些想法对于软件交付来说是一个非常优越的前进方式。我们希望Atomist服务能够提供最好的体现，但这些想法比任何一项服务或产品都要大。幸运的是，有一种方法可以表达比任何一家公司或产品更大的想法：开源。

在WebSphere糟糕的旧时代，高尔夫球场开始发生重大变化，今天，开发人员经常使用笔记本电脑作为开发的开始，使用用代码开发软件。也可以用这只新的方式开展交付工作，在笔记本电脑，使用开源的本地软件交付机。

今天我们宣布Atomist的下一代软件交付方法是免费和开源的。

....

原文 https://www.jdon.com/49907

正文到此结束