从第一天开始，无服务器框架就有了阶段的概念；能够创建同一服务的不同堆栈。当你需要为你的团队或组织的软件开发生命周期提供不同类型的环境时，这个概念非常有效，因为它允许你使用开发阶段将开发代码部署到开发环境。
serverless deploy --stage develop
然而，这确实伴随着一些问题。你如何管理各种环境之间的不同环境变量？如果你想部署到多个AWS账户怎么办？
无服务器框架仪表板使用了名为 "提供商 "和 "参数 "的功能，使你能够准确地管理这些问题。让我们深入了解一下!
初始设置
让我们开始进行我们需要的基本设置。它非常快!
首先，进入Serverless Framework Dashboard，如果你还没有账户，就创建一个新账户，或者登录你现有的账户。如果你创建了一个新账户，它会提示你给你的组织一个名字。你可以给它起任何你喜欢的名字，不要担心，如果你需要一个特别的名字，你可以在以后免费创建额外的组织。
完成后，你可以点击右上方的create app ，由于我们谈论的是添加一个现有的无服务器框架服务，所以继续选择该选项。这里只需添加你希望创建的应用名称和你要部署的服务名称。点击部署按钮，你会被提示创建或选择一个提供者。提供者的功能是帮助管理你与......嗯......像AWS这样的提供者的连接。一旦你完成了这项工作，你只需将带有org和app属性的小yml片段复制并粘贴到你的serverless.yml中，保存该文件并进行部署。
当我们部署时，如果我们没有在部署时用--stage stagename ，它就会默认为dev ，所以你可能会出现这样的情况。
但是，如果我们想部署多个阶段呢？我们该如何管理呢？
独立的AWS账户
将我们的各种环境，如开发和生产，分离到不同的AWS账户中，是一种相当普遍的做法。如果我们想让我们的开发环境部署到与我们的生产环境完全不同的AWS账户，我们可以这样做，首先将这个备用的AWS账户添加到我们的org中。
进入org设置部分，点击左边的org ，然后选择Providers标签。在这里，你可以添加一个链接到任何和所有的AWS账户，你可能想分配给你的任何阶段的未来。你甚至可以选择一个默认提供商，我们建议将其设置为一个你不介意别人意外部署的AWS账户；换句话说，不是你的生产AWS账户。
一旦你添加了额外的AWS账户，你就可以回到应用屏幕，如果你有任何已部署的服务（在上面的说明后你应该有），你会在这里看到它们。我们要做的是创建一个新的prod阶段，并在部署前将我们的prod only AWS提供者分配给它。我们通过点击服务名称右边的菜单图标，选择 "添加阶段"，然后给它起名为prod。点击带有灰色 "待定 "图标的新prod阶段，我们可以切换到提供商标签，选择我们想分配给这个尚未部署的阶段的提供商。
现在，当我们用serverless deploy --stage prod 进行部署时，该部署过程将使用相关的提供者来获得我们的prod AWS账户的临时凭证，并做它需要做的事情。
但在默认情况下，还有更多的好处。因为你现在可以通过无服务器框架仪表板向AWS进行部署，你不再需要向开发人员分发访问密钥和秘密，以便他们能够从本地机器上进行部署。当通过仪表板进行部署时，无服务器框架会在部署时请求通过你刚刚设置的提供者创建的临时访问凭证。一旦部署完成，这些凭证就不再使用了。
这对安全来说要好得多。
参数
你的应用程序需要配置数据。无论是连接到数据源还是第三方API，它都需要这些细节来运行你的应用程序。然而，这些细节往往因你是在开发环境还是在生产环境，甚至是在本地运行而有所不同。
值得庆幸的是，无服务器框架仪表板有一个功能可以帮助我们解决这个问题。像我们之前做的那样，打开服务的设置，你应该看到一个带有CI/CD、提供者和参数选项的菜单。切换到参数，我们可以添加一个键/值对的集合，其值是加密存储的。
这些参数对其内部的所有阶段都是可用的。这是一个很好的地方，可以把默认值放在所有阶段上，或者只是一些合理的值，以确保部署时无论如何都不会出错。如前所述，我们确实希望能够为阶段本身设置独特的参数。
因此，让我们回到应用程序屏幕，点击我们部署的任何阶段，我们应该看到参数标签。
在这里，我们可以看到我们在服务层面上添加的参数被过滤掉了，但是把鼠标移到inherited 标签上，我们现在可以用我们阶段的自定义值来覆盖这个继承的值。如果我们愿意的话，我们甚至可以为这个阶段从头开始添加任何我们需要的参数。
现在在部署时，这些值可以在我们的serverless.yml文件中使用。
org: garethsorg
app: my-new-app
service: my-new-service
provider:
name: aws
runtime: node12.x
environment:
DB_HOST: ${param:DB_HOST}
DB_NAME: ${param:DB_NAME}
DB_PASSWORD: ${param:DB_PASSWORD}
DB_USERNAME: ${param:DB_USERNAME}
${param:} 语法在运行时检索存储在键上的值。但结合无服务器框架现有的变量语法，我也可以确保本地开发有所需的值。
environment:
DB_HOST: ${param:DB_HOST, 'localhost'}
DB_NAME: ${param:DB_NAME, 'localdbname'}
DB_PASSWORD: ${param:DB_PASSWORD, 'localdbpass'}
DB_USERNAME: ${param:DB_USERNAME, 'localdbusername'}
如果参数不存在，就像在本地环境中可能发生的那样，就会使用, 后的默认值来代替。
让我们让基础设施团队满意
如果你是以前仪表板的用户，你可能已经注意到安全保障功能已经被删除。然而，它并没有消失。我们把 "安全保障 "移到一个插件中，你可以选择是否把它添加到你的项目中，并继续为你的服务添加组织策略，在部署时进行评估。你可以在插件的GitHub页面找到更多信息
有了我们所看到的一切，想象一下在Serverless Framework CI/CD中循环使用，它默认使用所有这些功能。它可以帮助你在多个阶段和部署场景中管理一个无缝的软件开发生命周期。你只需要到Serverless Framework Dashboard上注册就可以开始了。
