服务
关于
CloudProse博客
Think FaaS播客

无服务器最佳实践:测试-Think FaaS播客

Forrest回答了侦听器有关测试无服务器应用程序的问题,并分解了一些简化云中测试工作流的方法。
福雷斯特Brazeal Trek10 191210 171202
阿甘(Forrest Brazeal) | 2018年7月12日

2018年7月12日,星期四

在Google Play上订阅 订阅苹果播客

成绩单

嗨,我是Trek10的Forrest Brazeal,这是“ Think FaaS”,在这里我们比运行Lambda函数花费更少的时间了解无服务器计算的世界。因此,请紧记五分钟-现在是“ Think FaaS”的时候了。

今天,我们将继续发布有关无服务器最佳做法的迷你系列。首先,我想分享一个问题,这个问题是我本周从我们的一位出色的Think FaaS听众那里得到的。我将完整阅读它,因为我认为这是许多人正在进行的斗争的一个很好的总结。

Hi Forrest, I'm listening and enjoying your podcast at trek10.What I really miss, and hopefully you'll have a session about it, is testing in the cloud. As a developer who owns the code from product, to coding, to deployment, to monitoring, testing is a crucial part of the process. Local testing is feasible, there are tools and various mocks that enable me to test it locally, but for me without running my app in its native cloud environment at least once, there is no way to know if I broke something, code or integration (until it reaches the ci/cd process which for me is too late). The main problems that I'm facing:* Provisioning additional account in aws is expensive, I'm using managed services that cost money just for being provisioned like rds, elastic search.* Its quite cumbersome to manage multiple accounts (as dev manager) to 所有 of my developers and limit their billing* It's extremely frustrating to use the develop, deploy, debug cycle in a cloud environment due to network , it can take up to 1 minute for each small code change.

因此,让我解释一下这位听众在说什么。听起来他们已经在做最重要的事情,那就是编写模拟和单元测试以尽可能地覆盖其本地代码。有一些无服务器框架的插件,例如无服务器脱机,可以帮助解决此问题。有一个名为 本地堆栈 它会积极维护并模拟许多最受欢迎的AWS服务。顺便说一下,AWS甚至提供了DynamoDB的免费本地下载,这是我最喜欢的很棒的AWS事实之一。所有这方面的最大最佳实践是,尽可能使业务逻辑与与服务提供商的集成脱钩。这样一来,您就可以更轻松地模拟代码进行测试,甚至在需要时甚至可以交换提供程序。您希望尽可能确信自己的代码在上云之前是正确的。

但是,即使我们的听众正在做所有这些事情,听起来他们还是更在意集成测试。毕竟,无服务器应用程序主要由服务之间的边界组成,并且直到您在云中运行它并验证一切正常之后,您才真正进行过测试。现在,我确实想指出这一点。无服务器架构是事件驱动的,或者应该是事件驱动的。事件进来,事件出去。这是一个容易模拟的模式。因此,当您进行集成测试时,您真正要寻找的是服务之间的权限问题,可能是基础结构配置问题,以及性能瓶颈。性能测试不一定每次更改代码都需要运行,因此我们确实限制了我们需要担心的范围。

也就是说,我听到了听者提问中的三个主要痛点。与在本地计算机上运行相比,集成测试可能会非常昂贵,繁琐且速度缓慢。

关于管理测试堆栈的费用,除了尽可能多地依赖按使用情况收费的服务外,我建议在开发人员之间共享数据和缓存层,并为他们提供自己的应用程序堆栈(Lambda,API Gateway,AppSync),因为这些都是廉价的,并且这就是许多开发工作正在进行的地方。如果您要为每个开发人员提供一个完全独立的AWS帐户,这将变得更加棘手,因此您必须在成本和对代码进行沙盒化的优势之间进行权衡。

其次,管理所有这些测试堆栈可能很困难。这很重要,您需要使用诸如CodePipeline之类的工具来协调测试。在Trek10中,我们一直在使用动态管道,这些管道在将功能分支推送到源代码控制并将开发人员的代码部署到测试堆栈时会加速旋转。这只是开发人员,因此如果有人需要进入控制台,四处探寻,更改测试堆栈中的某些内容,这不是世界末日。这就是控制台的用途,而且速度可能很快。但是,您需要一个代码升级过程,以使只有代码定义的基础结构才能使其脱离开发环境,并进入下一步。

我还建议自动化部署后进行的冒烟测试。用模拟数据调用Lambda函数。针对AppSync进行GraphQL查询。您可以在Lambda函数或CodeBuild环境中无服务器地运行这些测试。 CodeBuild会慢一些,但可能会给您带来更大的灵活性。您想在所有环境中运行这些测试,而不仅仅是在开发环境中运行。

最后,速度。在本地计算机上编写代码,将其部署到云中并运行它以检查错误时,我们的侦听器提到网络延迟令人沮丧。这听起来很疯狂,但是缩短反馈循环的一种方法可能只是在云端编写代码。我说的是使用Cloud9(AWS基于浏览器的IDE)。我的共同主持人Jared Short实际上使用Cloud9作为他的主要开发环境,他最近推出了 一个有趣的博客文章 他如何以及为什么这样做。 Cloud9具有一些不错的Lambda集成。它使您可以在浏览器中编写和调试无服务器应用程序,然后单击即可将功能部署到测试环境。它可能不像运行本地托管的应用程序那么快,但是与每次进行更改时从本地计算机推送代码相比,您可能会发现它可以加快工作流程。

现在,显然,我描述的工作流程并不完美。在无服务器世界中,我们与React开发之类的本地开发生态系统在功能上并不相称。但是随着无服务器运动的继续发展,我们已经看到工具得到了突飞猛进的改进,我毫不怀疑它将继续发生。同时,您可以通过在Twitter @ Trek10inc上关注Trek10来保持无服务器状态,我和@forrestbrazeal也在其中,我们将在下一集Think FaaS上与您见面。

作者
福雷斯特Brazeal Trek10 191210 171202
阿甘(Forrest Brazeal)