【发布时间】：2017-03-31 12:26:32
【问题描述】：
我正在使用 gitlab CI 为我的网站设置部署过程。
我有一个production 网站和一个带有staging 部署的子域。
假设我有不同的分支：master 和 release。我有一个配置为 .yaml 的文件：
如果我推送 master，我会在 production 上进行部署（带有手动选项），如果我推送我的分支版本，我会在 staging 上进行自动部署。
git push origin master
部署到生产环境（手动验证），
git push origin release
部署到登台。并且任何其他被推送的分支都不会部署。
我们是几个人一起工作，有时，当在 git push 上指定标签（例如 specifictag）时，我们希望能够在 staging 上部署另一个分支（例如 feature）：
git tag specifictag
git push origin feature --tags
这对我很有用，因为有时一些开发人员希望在合并发布之前测试他们的代码，而我们不想创建第三个环境。当然，我们不想在每次推送任何分支时都进行部署。
stages:
- staging
- production
test-deployment:
stage: staging
script:
- [...]
only:
- release
tags:
- extranetserver
prod-deployment:
stage: production
script:
- [...]
only:
- master
tags:
- extranetserver
when: manual
有没有人知道如何使用标签作为在推送特定标签时强制部署的一种方式？ 谢谢！
【问题讨论】：
-
正在部署什么样的网站。哪个服务器。只是询问是否可以以不同的方式解决原始问题。
-
它并不能准确回答您的问题，但您是否查看了 Review Apps docs.gitlab.com/ce/ci/review_apps ？
-
感谢大家提出的问题和建议。我们的网络应用程序非常多样化，它收集了不同语言的许多算法和功能，所以我正在寻找一些非常通用和适应性强的东西。我们称我们的网站为“实验室”，因为它有许多功能。
-
@Jawad ：当我询问时，我没有查看 ReviewApps，它看起来很有趣！但是，我不确定它是否可以帮助我，因为如果我理解得很好，它每次都会创建另一个网站“子域”。我觉得我不想这样做。我错了吗？
-
实际上你定义了它的部署方式。它可能在子域上，但也可能在您的暂存子域上，但在不同的端口上。我认为它主要被设计为与 kubernetes 或 openshift 等可以动态创建子域的平台一起使用。因此可能不适用于您的用例。
标签： git deployment gitlab gitlab-ci