Gitworkflow和测试Openshift/Kubernetes中的短命特性分支

Question

最近，我的团队开始适应基于敏捷交付的git工作流，我们一直在使用JIRA、TeamCity和其他各种CI工具来完成管道。该工作流对于JAVA中的monolith或SOA应用程序非常有用。

这个问题来自面向企业环境(如Openshift )的微服务交付管道。

使用git工作流，期望feature分支一旦开发和测试，将合并到develop分支，然而，当开发中有许多特性时，开发人员需要一个平台来测试他在提交请求之前构建的服务特性。

对于openshift/K8，我们公开一个服务，假设每个由特性分支构建的服务如下所示。

myapplication-MIM-158848-feature1.myco.internal.au
myapplication-MIM-158849-feature2.myco.internal.au

在内部，openshift应该能够分配专用的荚来测试服务，一旦与develop分支合并，它们就应该被处理，这种方法的另一个问题是运行集成测试，或者如果服务与使用者apis有依赖关系。修改基于feature分支的服务名称不是一个好主意。

有谁知道在基于微服务的平台中处理这种交付模型的更好方法吗？谢谢

Answer 1

我们正在使开放源码成为我们在GitHub上的openshift持续部署设置，我们称之为强迫症。它实际上是由git标记和git中的Helmfile yaml驱动的。由于它是由git标记驱动的，因此对于使用哪些分支是不可知的。您使用的CI/CD工具也是不可知论的。

开发人员可以通过在git中修改yaml文件，在openshift上开发新的应用程序。因此，设置特性分支的开发人员可以通过简单地标记代码并更改一些yaml以让openshift运行该代码来“自助服务”旋转代码。

它可以用于满足您的用例如下：

1. OCD由git标记(或git发布)事件生成，并在git标记中生成源代码的容器映像，并使用相同的标记标记容器映像。它不需要知道这些标记属于哪个分支。
2. 需要新特性分支部署的团队将在git中添加一个新文件夹，该文件夹保存所有要构建和运行标记代码的配置。

OCD是作为通用舵机图来实现的。其中一个设置了BuildConfig，它是从git标记构建的，并使用相同的标记标记图像。另一个将设置DeploymentConfig以运行标记图像。另一个管理用git加密的秘密。另一个管理ConfigMaps。安装时使用Helmfile，可以在yaml文件中声明一堆头盔发行版。这是由adnanh/webbook运行的，这是一个可以捕获gitweb钩子事件并运行shell脚本的小型go应用程序。

强迫症是在建立微型服务的情况下创建的。这个想法是团队可以很容易地获得新的服务。使用它来临时启动应用程序来测试是很容易的。如果从git中删除了删除应用程序，它就不会更新它们。这将是不难实现的，当测试，我删除应用程序与单一的命令行。

免责声明:它目前是预发行版，但功能已经完成，我们正在将我们自己的应用程序移植到其中。