ci/cd服务器_无服务器流：针对速度和质量进行了优化的CI / CD分支工作流-CSDN博客

ci/cd服务器

The ephemerality of Serverless architectural components, coupled with the pay-per-use pricing model, allows us to have rapidly deployable, cheap and disposable environments when working with Serverless-First architectures. No longer are we constricted to Dev, Staging, UAT and Prod environments.

无服务器架构组件的短暂性，再加上按使用付费的定价模型，使我们在使用无服务器优先架构时能够拥有可快速部署，便宜且可抛弃的环境 。我们不再局限于开发，登台，UAT和产品环境。

Instead, we can have any number of environments that are isomorphic to the real production infrastructure. This allows us to reimagine how our CI/CD can work, reducing the lead-time to release to production, while maintaining quality assurance.

相反，我们可以具有与实际生产基础结构同构的任意数量的环境。这使我们能够重新构想CI / CD的工作方式，减少发布到生产中的交货时间，同时保持质量保证。

“Serverless-Flow” is similar to GitHub Flow, but takes advantage of the ephemeral pay-per-use environments Serverless offers. There are 4 steps to getting to Serverless-Flow on your CI/CD:

“ Serverless-Flow”类似于GitHub Flow，但利用Serverless提供的临时按使用付费环境。进入CI / CD上的Serverless-Flow有4个步骤：

1. Isolating Environment Deployments 🏝2. Integration Test Coverage 👷‍♀️👷‍♂️3. Branching Workflow — Serverless Flow 🌳4. Cleanup ♻️

1.隔离环境部署🏝2。 集成测试覆盖率👷‍♀️👷‍♂️3。 分支工作流—无服务器流🌳4。 清理♻️

1.隔离环境部署🏝 (1. Isolating Environment Deployments 🏝)

The basic pre-requisite to using the Serverless-Flow approach to CI/CD is to have service(s) that are deployable to isolated environments based on a single change to a deployment argument.

对CI / CD使用无服务器流方法的基本先决条件是，基于对部署参数的一次更改，就可以将服务部署到隔离的环境中。

Note: These examples will focus on the Serverless Framework

注意：这些示例将重点放在无服务器框架上

In the Serverless Framework, people often make use of the stage option for this: serverless deploy -s [STAGE NAME] -r [REGION NAME] -v

在无服务器框架中，人们经常为此使用stage选项： serverless deploy -s [STAGE NAME] -r [REGION NAME] -v

The stage variable can be used by the Serverless Framework to make environment variables change, and also included in the naming of other resources to ensure resources don’t clash between stages.

Stage变量可由Serverless Framework使用，以更改环境变量，并且还包含在其他资源的命名中，以确保资源在各个阶段之间不会发生冲突。

The key is that the environments are isolated and don’t clash. If you deploy a Dev1 environment, you don’t want to have issues when deploying Dev2 because an S3 resource created as part of the service has a naming conflict. The simple solution to this is to include the variable you’re using for environment declaration in the naming of any collateral resource. Alternatively, some teams stop naming additional resources at all and let AWS generate unique names.

关键是环境是孤立的，不会冲突。如果部署Dev1环境，则部署Dev2时不会出现问题，因为作为服务一部分创建的S3资源存在命名冲突。一个简单的解决方案是在任何附带资源的命名中包括用于环境声明的变量。 或者，一些团队根本停止命名其他资源，而让AWS生成唯一的名称。

Some projects avoid stages all together to make this issue clearer to the team. API Gateway natively supports the concept of staging (generating per stage URLs), whereas services like S3 do not. It’s important that teams ensure collateral resources are made dynamic per-environment to prevent accidental impact to other environments and to allow deployments to proceed. One tactic to avoid stages can be to add a custom option to your Serverless deploy: serverless deploy --infraStackName staging

一些项目一起避免了阶段，以使团队更清楚地了解此问题。 API Gateway本身支持分段(按阶段URL生成)的概念，而S3等服务则不支持。团队必须确保按环境动态分配抵押资源，以防止对其他环境造成意外影响并允许部署继续进行。避免阶段的一种策略是向无服务器部署中添加自定义选项： serverless deploy --infraStackName staging

Just like a stage, this deployment argument can be included in resource naming to avoid conflicts:

就像阶段一样，此部署参数可以包含在资源命名中以避免冲突：

2.集成测试范围👷‍♀️👷‍♂️ (2. Integration Test Coverage 👷‍♀️👷‍♂️)

To have trust in CI/CD all the way to production we need to verify our changes have not broken existing functionality, and that they deliver the new functionality. Teams should no longer rely on manual regression testing and instead, automation should be the primary verification check.

要一直信任CI / CD到生产的整个过程，我们需要验证所做的更改没有破坏现有功能，并确保它们提供了新功能。团队不应再依赖手动回归测试，而应该将自动化作为主要的验证检查。

Serverless architectures are best tested via Integration Testing on the deployed infrastructure. Mocking is rarely appropriate, and instead, real scenarios should run on the real underlying services.

无服务器架构最好通过已部署基础架构上的集成测试进行测试。模拟很少是合适的，而是应该运行实际方案 真正的基础服务 。

It’s key that the integration test suite can be run on any environment, automatically conducting all required setup and teardown of data.

集成测试套件可以在任何环境下运行，自动进行所有必需的设置和拆卸数据，这是关键。

For example, if a test runner like jest is used, arguments should be passed for the stack/stage name and AWS Profile to use for verification (e.g. asserting the content of an S3 bucket is correct).

例如，如果使用了诸如jest之类的测试运行程序，则应传递用于堆栈/阶段名称和AWS Profile的参数以用于验证(例如，断言S3存储桶的内容正确)。

Note, a future deep dive article will demonstrate how integration testing of Serverless Architectures can be achieved in Jest.

注意，将来的深入探讨文章将演示如何在Jest中实现无服务器架构的集成测试。

3.分支工作流 -无服务器流 🌳 (3. Branching Workflow — Serverless Flow🌳)

Serverless-Flow, as the name suggests is based on many of the same principles as GitHub Flow. GitHub Flow in short proposes:

顾名思义，Serverless-Flow基于与GitHub Flow相同的许多原理。简而言之，GitHub Flow建议：

Create a branch from main with a descriptive name.
从main创建一个具有描述性名称的分支。
Add commits onto that branch locally, pushing regularly.
将提交定期添加到该分支上。
Open a Pull Request to main
打开向主请求请求
Code Review
代码审查
Deployment to production before final merge to main
在最终合并到主服务器之前部署到生产

Image for post — https://guides.github.com/introduction/flow/ https://guides.github.com/introduction/flow/

Serverless-Flow avoids the verification in production step by making use of the ephemeral environments available to us in Serverless.

Serverless-Flow通过利用Serverless中可用的临时环境来避免生产阶段的验证。

Create a branch from main with a descriptive name.
从main创建一个具有描述性名称的分支。
Add commits onto that branch locally, pushing regularly.
将提交定期添加到该分支上。
Open a Pull Request to main
打开向主请求请求
Code Review
代码审查
Automatic deployment to new environment named after Pull Request number. e.g. serverless deploy --infraStackName pr-42 (triggered by PR open or push to existing PR)
自动部署到以请求请求编号命名的新环境。 例如， serverless deploy --infraStackName pr-42 (由PR打开或推送到现有PR触发)
Integration Test Suite runs against PR-x environment to verify changes.
Integration Test Suite在PR-x环境下运行以验证更改。
Optional: Functional Review on PR environment (environment will have a subdomain for the PR number, allowing a preview of the feature)
可选：PR环境的功能审查 (环境将具有PR号的子域，从而允许预览功能)
Deployment to Production (before or after the merge to main)
部署到生产中(合并到main之前或之后)

Note: GitHub Flow is actually not strict on where verification happens. “Different teams may have different deployment strategies. For some, it may be best to deploy to a specially provisioned testing environment” — therefore Serverless-Flow is a form of GitHub Flow, where we are strict on where verification happens.

注意：GitHub Flow实际上对验证发生地并不严格。 “不同的团队可能有不同的部署策略。对于某些人来说，最好将其部署到专门配置的测试环境中”，因此Serverless-Flow是GitHub Flow的一种形式，我们严格进行验证。

4.清理♻️ (4. Cleanup ♻️)

Finally, it’s not great to have many stacks building up so we need to do some garbage stack collection. This can be achieved by a Lambda cron, automatic cleanup on merge to main or a lightweight stack management API that allows stacks to be claimed, released and even reused*.

最后，建立许多堆栈并不是很好，所以我们需要进行一些垃圾堆栈收集。这可以通过Lambda cron，在合并到主数据库时自动清除或轻量级堆栈管理API来实现，该API允许声明，释放甚至重用堆栈*。

Read more about stack reuse and management APIs with our open-source Table Lock project.

通过我们的开源Table Lock项目了解有关堆栈重用和管理API的更多信息。

结论 (Conclusion)

Serverless allows an infinite number of environments. If we structure our infrastructure well we can create innovative CI/CD processes that allow teams to deploy faster, with better verification & QA processes.

无服务器允许无限数量的环境。如果我们合理地构建基础架构，我们可以创建创新的CI / CD流程，使团队可以更快地部署，并具有更好的验证和质量保证流程。