搭配使用 Split 功能标记与 Bitbucket pipelines

将新代码部署到生产环境是有风险的。即使在测试和暂存环境中对代码进行了单元测试、集成测试和系统测试之后，缺陷仍可能给生产带来风险。过去，一旦缺陷给生产带来风险，开发人员有两种选择，用户会受到影响。他们可以回滚缺陷的代码，或者向前推进修复。这两种解决方案都需要时间。现在，开发人员通过将相关的代码变更打包在功能标记中，只需点击一个按钮，即可在环境中开启或关闭功能。缺陷代码对用户的影响可以立即得到缓解，并且可以安全地开发和向前推进修复。本文使用 Bitbucket Pipelines 和 ImageLabeller 演示应用中的 Split 功能标记对此进行了演示。

先决条件

Bitbucket cloud 和 pipelines

Split 帐户

ImageLabeller 功能标记演示

ImageLabeller 是一款使用机器学习来标记图像的小应用。ImageLabeller 部署到五个环境。测试、暂存、Production-us-west-2、Production-us-east-1 和 Production-ca-central-1。本文演示了如何使用功能标记来管理对 ImageLabeller 的 SubmitImage 组件的变更。SubmitImage 是用 Go 编写的 AWS Lambda。此演示使用 Split 来管理功能标记。Bitbucket 用于源控制，Bitbucket pipelines 用于 CI/CD 功能。

搭配使用 Split 功能标记与 Bitbucket pipelines

创建 Split 帐户，转到“管理员设置”，然后转到“工作区”。在默认工作区上单击“查看”以查看可用环境。

重命名默认环境，并添加适合您的用例的新环境。ImageLabeller 部署到五个环境。对应于三个 AWS 区域的测试、暂存和三个生产环境。US-WEST-2、US-EAST-1 和 CA-CENTRAL-1。

单击“Splits”，然后在左侧导航面板中单击“创建 split”，以创建一个新的 split，这是一个功能标记。

为 split 命名，然后将“流量类型”变更为用户。

单击“添加规则”，在创建 split 后将目标规则添加到其中。为测试环境创建目标规则。每个环境可以有单独的目标规则。目标规则定义了在代码中访问 split 时它返回的数据。本指南将 split 设置为默认返回“关闭”，特定用户访问 split 时返回“打开”。

展开“设置默认规则”，然后将其设置为“关闭”。

展开“设置单个目标”，单击“添加目标”，然后将“服务”设置为“打开”，然后将“发送给用户”设置为属于 QA 流程一部分的某个用户。本指南使用 AtlassianDemoUser@atlassian.com 作为测试用户。

保存变更。split 现在有针对测试环境的目标规则。单击环境下拉列表其他区域。例如，暂存。

单击“复制目标规则”，然后选择“测试”以复制之前创建的目标规则。对每个环境重复此流程。各个环境可能有截然不同的目标规则。本指南使目标规则跨环境保持相同。

转到“管理员设置”，然后转到“API 密钥”以获取每个环境的 API 密钥列表。在代码中的 API 调用期间，这些 api 密钥会被发送回 split，以获得正确的 split 版本。本指南使用每个环境的服务器端密钥。

转到您的 Bitbucket 存储库，再转到“存储库设置”，然后转到“存储库变量”，为每个 API 密钥添加变量。

编辑 bitbucket-pipelines.yml 文件，然后将 STACK_PARAMETERS 添加到 AWS SAM 部署步骤中。这是根据每个环境完成的。下面的 YAML 代码段显示了 AWS US-WEST-1 中“测试”区域的部署步骤。因此，该步骤引用了上面设置的 split_test_env 存储库变量。为每个环境使用相应的存储库变量。

1- pipe: atlassian/aws-sam-deploy:1.2.0
2  variables:
3    AWS_ACCESS_KEY_ID: ${AWS_ACCESS_KEY_ID}
4    AWS_SECRET_ACCESS_KEY: ${AWS_SECRET_ACCESS_KEY}
5    AWS_DEFAULT_REGION: 'us-west-1'
6    STACK_NAME: 'OpenDevOpsSubmitImage'
7    CAPABILITIES: [ 'CAPABILITY_IAM', 'CAPABILITY_NAMED_IAM', 'CAPABILITY_AUTO_EXPAND' ]
8    TEMPLATE: 'https://s3.amazonaws.com/open-devops-code-us-west-1-${AWS_ACCOUNT_ID}/submit-image-packaged.yml'
9    WAIT: 'true'
10    DEBUG: 'true'
11    S3_BUCKET: 'open-devops-code-us-west-1-${AWS_ACCOUNT_ID}'
12    SAM_TEMPLATE: 'build/template.yaml'
13    STACK_PARAMETERS: '[{
14      "ParameterKey": "SplitIOSDKKey",
15      "ParameterValue": "${split_test_env}"
16    }]'

编辑 AWS CloudFormation template.yml 文件并添加引用 Split SDK 密钥的“参数”部分。

1Parameters:
2  SplitIOSDKKey:
3    Type: String

在 template.yml 文件中，向需要访问 Split 的每个 AWS Lambda 资源添加一个“环境”部分。本指南演示

1Environment:
2  Variables:
3    SplitIOSDKKey:
4      Ref: SplitIOSDKKey

将以下依赖关系导入将使用 Split SDK 的 Go 文件中。

1"github.com/splitio/go-client/v6/splitio/client"
2"github.com/splitio/go-client/v6/splitio/conf"

此函数创建客户端，并检索 Split UI 中创建的“SubmitImageDemoSplit”的功能标记值。它取一个参数“用户名”。

1func getSplitIOFlag(username string) (string, error) {
2  splitIOSDKKey := os.Getenv("SplitIOSDKKey")
3
4  cfg := conf.Default()
5  factory, err := client.NewSplitFactory(splitIOSDKKey, cfg)
6  if err != nil {
7    fmt.Printf("SDK init error: %s\n", err)
8    return "", err
9  }
10
11  splitClient := factory.Client()
12  err = splitClient.BlockUntilReady(10)
13  if err != nil {
14    fmt.Printf("SDK timeout: %s\n", err)
15    return "", err
16  }
17
18  treatment := splitClient.Treatment(username, "SubmitImageDemoSplit", nil)
19  fmt.Printf("SPLIT_DEMO treatment is %s, username is %s\n", treatment, username)
20
21  return treatment, nil
22}

使用电子邮件地址调用该函数。在这种情况下，someRandomUser@atlassian.com 将拉取功能标记的默认值，因为它不是与功能标记关联的允许列表的成员。AtlassianTestUser@atlassian.com 将拉取与它所在的允许列表关联的功能标记值。

1foo, err := getSplitIOFlag("someRandomUser@atlassian.com")
2  _ = foo
3
4  bar, err := getSplitIOFlag("AtlassianDemoUser@atlassian.com")
5  _ = bar

在执行了代码后，查看 AWS CloudWatch 日志中的输出。请注意，当 someRandomUser@atlassian.com 访问功能标记时，它会返回“关闭”，当 AtlassianTestUser@atlassian.com 访问功能标记时，它会返回“打开”。

通过这种方式，开发人员可以控制其代码的执行，而无需进行另一次部署。如果在环境中发现缺陷，则可以关闭该环境中的功能标记，然后可以运行旧代码。

总结

Split 功能标记可轻松集成到通过 Bitbucket pipelines 部署的应用中。功能标记使开发人员能够控制已部署代码的执行。这可以更快响应缺陷部署，减少对用户的影响。用些时间启动 Bitbucket 和 Split 的实例，然后测试您的团队的能力。