我们有一个无服务器框架项目,在monoreo中有不同的微服务。项目的结构看起来像:
project-root/
|-services/
|-service1/
|-handler.py
|-serverless.yml
|-service2/
...
|-serviceN/
...
|-bitbucket-pipelines.yml
正如您所看到的,每个服务都有自己的部署文件(serverless.yml(
我们只想部署在推送/合并中修改过的服务,因为我们使用的是比特桶管道,所以我们更喜欢使用它的功能来实现这一目标。
经过一点研究,我们发现了changesets
属性,它可以为目录中更改的文件设置一个步骤。因此,对于每项服务,我们都可以添加bitbucket-pipelins.yml,类似于:
- step:
name: step1
script:
- echo "Deploy service 1"
- ./deploy service1
condition:
changesets:
includePaths:
# only files directly under service1 directory
- "service1/**"
这似乎是一个完美的匹配,但这种方法的问题是,我们必须为repo中的每个服务编写一个步骤,如果我们添加更多的服务,我们将不得不添加更多的步骤,这会影响可维护性和可读性。
是否有任何方法可以使用参数化步骤来创建for
循环,其中输入参数是服务的名称?
另一方面,我们可以制作一个自定义脚本来处理条件和检测更改本身的部署。即使我们更喜欢比特桶原生方法,我们也对其他选择持开放态度;在脚本中最好的方法是什么?
您能得到的最接近的方法是为部署步骤重用yaml锚点,并将自定义部署环境与您的服务相匹配。
definitions:
yaml-anchors:
- &deploy-step
name: Deploy
script:
- echo "Deploy $BITBUCKET_DEPLOYMENT_ENVIRONMENT"
- ./deploy $BITBUCKET_DEPLOYMENT_ENVIRONMENT
pipelines:
branches:
main:
- parallel:
- step:
<<: *deploy-step
deployment: service1
condition:
changesets:
includePaths:
- service1/**
- step:
<<: *deploy-step
deployment: service2
condition:
changesets:
includePaths:
- service2/**
# ...
- step:
<<: *deploy-step
deployment: serviceN
condition:
changesets:
includePaths:
- serviceN/**
额外奖励:Bitbucket将独立跟踪每个微服务部署。
我怀疑BITBUCKET_DEPLOYMENT_ENVIRONMENT
是否可以在includePaths
块中插值,所以这仍然很冗长。如果你设法智能化部署脚本,为你检测文件更改,那么你可以将其简化为
definitions:
yaml-anchors:
- &deploy-step
name: Deploy
script:
- echo "Deploy $BITBUCKET_DEPLOYMENT_ENVIRONMENT"
- ./deploy $BITBUCKET_DEPLOYMENT_ENVIRONMENT
pipelines:
branches:
main:
- parallel:
- step:
<<: *deploy-step
deployment: service1
- step:
<<: *deploy-step
deployment: service2
# ...
- step:
<<: *deploy-step
deployment: serviceN
但是要注意,您可以拥有的自定义部署环境的数量是有限的。