在云的世界里，没人会去主动的关闭互联网并且所有应用程序也总是在创造着一个持续性计算型的世界。云计算的这种永远在线、永远互联与永远更新的特性带来了我们通常所说的持续集成与持续交付（CI/CD）。 像Facebook每天都会“部署”一款新的软件，但通常，用户并不会注意到这样的更新，因为我们是通过网页或移动应用进行软件访问的，而所有的更新与部署工作均发生在后端。这可被视为是一种快速的大规模发布，就像敲入一串不间断的大写C一样。

技术供应商商现在正致力于将持续性性的CI/CD软件工具推向市场。而客户看到这些工具后，也总是会欣然接受他们。这种朝向不断重生式的工程开发模式本意是良好的，但问题是软件部门的资源会经常被用于即用型功能软件的编写。

而谷歌现在开始尝试去解决这种问题。显然，谷歌云为企业客户运营了大量的“实例”。它可以看到客户对数据与流程的需求，以及这些客户在试图构建、测试和最终软件在谷歌云部署过程中的各种阻碍与痛苦。

Google Cloud Build

谷歌的赌注压在自己的Google Cloud Build平台上。这是一个为客户提供云端软件构建服务的产品，它也因此而得名。谷歌将Google Cloud Build称之为“平台”，但我们可能更愿意相信谷歌云服务才是真正的应用的“平台”。 Google Cloud Build更像是一个完全托管式的云应用开发环境，其中包含一组相关的构建和测试管理工具，如自动化和工作流程控制，以及智能隐私与漏洞分析。

简而言之，Google Cloud Build本质上是一套软件，旨在帮助客户在持续性的云世界中创建云应用程序。 Google工程VP Melody Meckfessel说道，持续型计算意味着软件团队需要更快地交付出更多的业务价值。 但这种对速度和变化的偏好也具有代价，比如每天都会发现全新的漏洞，看似无害的更新可能会导致整个程序的崩溃。

她在Google的博客文章中写到，“发现并解决问题的时机最好是尽可能早与自动地。在软件中，类似的持续改进文化是必不可少的，同时还有自动化的最佳实践的新工具，比如持续集成和持续交付（CI/CD）。在创建Cloud Build的过程中，我们与来自各行各业的软件开发人员合作，并听取他们的意见。同时我们也花了时间去了解是什么提升了我们内部工程团队的生产力”。

Meckfessel表示，正是Google的这种“倾听”让它能够识别出云应用软件开发中的三个最关键影响因素。

可扩展性、灵活性与安全性

可扩展性是关键， Meckfessel表示，没有人会觉得构建过程过快，也没有人会去指责测试套件运行的太快。随着项目的发现，新的开发人员加入团队，CI/CD系统也必须能够进行匹配。 Google对于此的回应则是提供灵活的定价模式，为需要不同数量云应用处理能力的客户提供不同的计算资源规模。

当提及灵活性因素时，Meckfessel认为，软件开发是其实就像一个由不断变化的框架、依赖关系、服务、语言和工作组成的日益复杂的网页。

她说道，“应用程序部署在多个云、本地资源和移动应用程序商店中。为了支持开发需求，Cloud Build会与GitHub、GitLab、Cloud Source Repositories 和BitBucket等主要的源存储库一道运行，同时它还支持Docker、Maven、Gradle、Bazel、Go和npm等。一个附件组件的生态系统以及能够将你自己的任务和工具链变为容器的能力能够使集成你现有开发人员工作流的过程变得更为容易”。

而在最后，Meckfessel还强调了安全。她认为安全性不仅仅是在运行时（比如，当一个应用实例进行运行时），还在整个服务方案的生命周期中，它会关联到每个正在使用的工具与管道中。为了解决这个问题，Cloud Build使用了安全和策略控制，它在自己的虚拟机（VM）上运行每一个构建过程，这减少了由构建环境不一致而引发的信息泄露或构建错误风险。

当然，这是Google的一家之言，并不是每一个人都会表示赞同，比如Datical 的联合创始人兼CTO Robert Reeves就持有不同的看法，这是一家提供自动化软件，并加速应用程序发布周期的数据库供应商。

他判断到，“有一天，一个CI/CD工具会忘记应用程序堆栈中最重要的部分：数据库。不论开发团队构建、测试和部署软件的速度和规模，如果数据库团队不能跟上进度，整个发布过程就会终止。虽然Google Cloud Build对于维护你自身的CI/CD方案来说无疑是一种改进，但软件的发布周期依然只能以最慢的速度运行。如果Google和其他CI/CD供应商想要真正实现他们的承诺，他们需要好好考虑数据库”。

Reeves提醒到，所有的应用程序和网站都是由数据驱动的，所以他进一步指出，超过80%的应用程序的部署需要通过某种形式的数据库进行修改。

“所以，当你提供的CI/CD方案对你80%的部署都没有帮助时，你只解决了20%的问题。在这个解决方案中，没有东西能够对数据库模式的变化进行帮助。因此，Google会要求用户进行手动地更改，并同时自动化编译后的应用程序。但这只会给已经超负荷的数据库管理员（DBA）带来更多的压力”。

综上，可能目前Google在如何将Cloud Build推向市场方面可能还没有忘记数据库工程元素，但是，这就是说，Cloud Build还是更为关注那些上层的开发人员的需求。

但公平来讲，我们在全球中范围内没有足够的开发者，因此我们无法从新型的基于服务的计算模式中获得足够的数据中心后端支持。因此，如果Google可以通过自动构建、测试、人工管理和部署工具以在整个开发和部署周期中节省一些时间并消除手工流程，那么开发人员就可以更为专注于编写云代码的工作，整体而言，这件事情依然利大于弊。

来源：Forbes

作者：Adrian Bridgwater

编译：T媒体 张飞逸

版权声明：

凡本网内容请注明来源：T媒体（http://www.cniteyes.com）”的所有原创作品，版权均属于易信视界（北京）信息科技有限公司所有，未经本网书面授权，不得转载、摘编或以其它方式使用上述作品。

本网书面授权使用作品的，应在授权范围内使用，并按双方协议注明作品来源。违反上述声明者，易信视界（北京）信息科技有限公司将追究其相关法律责任。