使用 GitLab 自动化 Quarkus
Logicdrop 提供了一个业务自动化和数据智能平台，使企业能够设计自己的解决方案并在云中运行它们。 我们每月在全球客户群中处理数百万笔交易，并为关键任务流程增加重要价值。
挑战
自从迁移到 Quarkus 以来，我们的生产力迅速超过了我们的 CI/CD 流程。 我们需要一种更好的方法来利用微服务和云原生方法，更快、更频繁地部署，并让每个人都参与到整个过程中。
我们最终确定，复杂性不在于实际部署，而在于编排所有投入其中的工作以及之后的处理。
我们面临的一些挑战是
-
环境随着服务的增多而变得更加复杂
-
调试分布式服务具有挑战性
-
需要并使用不同的工具集来提高可见性
-
除了本地之外，没有隔离的方法来开发或共享工作
-
前端和后端团队之间的协作不足
必须有更好的方法……
GitLab 项目
我们确定的结构是将集群操作、模板和 Quarkus 服务拆分为单独的项目。 这使我们能够轻松地对现有配置进行更改或应用新配置，从而以最小的努力实现最大的灵活性。
集群项目集中了所有与 Kubernetes 集群相关的内容。 它被配置为 GitLab 集群管理项目，因此我们可以管理其他集群服务，如 Elastic、Nginx 或任何其他 Helm charts。
模板项目包含我们所有 GitLab 项目使用的构建块。 它使维护更容易，提供灵活性并提高一致性。 开发人员可以在几分钟内使用这些模板添加新的应用程序或服务。
Quarkus 项目被视为服务系列，每个服务都是单独工作和部署的。 每个服务都使用触发器来通知集群何时可以部署或清理。
| 我们发现使用 Quarkus 配置文件 将常见的发布和 Kubernetes 属性抽象到共享 JAR 中，从而使开发人员更无需管理单个配置。 |
使用 Quarkus，我们无需维护服务的 Helm charts。 我们甚至有 Quarkus 服务可以直接与 GitLab 交互，以进行我们维护的特定工具和指标。
Quarkus 扩展
使用开箱即用的 Quarkus 扩展，可以轻松快速地公开各种日志、指标和功能。
更进一步，将扩展集成到 GitLab 中，我们
-
节省了时间
-
减少了工作量
-
提高了可见性
-
促进了协作
-
最大限度地降低了复杂性
我们使用的最重要的扩展是 Quarkus Kubernetes 和 Quarkus Kubernetes Config 扩展。
我们集成到 GitLab 的其他扩展有
将 Quarkus 扩展与 GitLab 结合使用，我们可以全面了解我们的环境，从开发到部署和监控，从而使构建微服务变得更加容易。
梦想流水线
开发人员驱动的部署
我们最重要的流水线围绕使开发人员流程更加精简和易于使用。 开发、调试和协作多个服务需要尽可能简单和轻松。
以前，部署到更高级的环境既繁琐又可行，但开发人员没有完全参与到此过程中。
| 自从迁移到 Quarkus 以来，开发人员现在负责开发和部署（适用限制）他们自己的服务。 |
我们决定使用 GitLab 合并请求流水线 作为推动我们流程的催化剂。
每次推送时，合并请求将
-
运行所有单元测试
-
运行任何集成测试 (Mongo, AWS, Redis)
-
运行任何 E2E 测试（其他外部服务）
-
生成代码覆盖率和质量报告
-
发布交互式 Swagger API
合并请求最有用的功能是我们可以使用它来部署任意数量的服务，并与它们交互到隔离的环境中。
审查服务使我们超越了自动化测试。 我们可以抽查正在进行的工作，或者甚至在需要时运行全套服务（这在组合 UX 和多服务功能期间特别有用）。
| 与纯 Java 同类产品相比，Quarkus 本机可执行文件比羽毛还轻，只有很小一部分大小。 这使我们可以在比部署等效 Spring Boot 服务所需的空间更小的空间中部署全套服务。 |
构建 Quarkus 服务
下游 Quarkus 流水线是一组专门的作业，仅用于处理构建、测试和容器化 Quarkus 服务。
对于每个更改的服务，我们
-
构建本机可执行文件或快速 jar
-
运行任何测试（包括在需要时运行本机测试）
-
生成 Kubernetes 清单
-
构建和部署其容器
| 我们仅推送容器并将清单上传到 AWS S3。 这使我们可以将更改累积到可以部署的单个包中，该包由一个或多个服务组成。 |
更快的流水线
为了加速流水线，尤其是在构建多个本机可执行文件时，我们依靠 GitLab AutoScaling runners 并行运行作业。 这使我们可以在相对恒定的时间范围内构建任意数量的服务。
| 目前，对于 20 多个服务，我们可以在不到 20 分钟的时间内执行完整的端到端部署，包括本机可执行文件，而无需人工干预。 大多数时候，由于我们只部署更改的服务，因此净时间要少得多。 |
我们使用 GitLab 的 needs 关键字来缩短流水线，以便我们可以更快地进入更重要的作业而无需等待。 这使我们可以在服务准备就绪后立即并重复地部署服务（如果需要）。
在上面的 DAG 中，构建服务后，我们可以部署它们，而无需等待其他服务完成。
| 本机构建是密集型的，因此最好并行运行它们。 里程可能会有所不同，但我们发现 AWS M5.XL 实例是我们在执行此操作时最划算的。 |
一次部署统领一切
分支驱动开发过程，标签驱动发布过程。
可以随时提升默认分支。 这会启动一系列作业，最终在没有干预的情况下将更新的服务部署到集群中。
除非测试失败（应该事先发现），否则流水线，无论是来自开发人员分支还是默认分支，都是完全自动化的。
单击 promote 开始执行以下步骤
-
协调 Maven 版本
-
更新变更日志
-
创建发布标签
-
构建服务并部署容器
-
生成 Kubernetes 清单
-
发布 Swagger API 并生成 OpenAPI 客户端
-
将版本提升到下一个
-SNAPSHOT版本
| 无论好坏，我们都使用 Maven CI Friendly 版本来帮助我们简化版本控制和部署。 |
下图显示了所有作业同时运行，包括正在构建的每个 Quarkus 服务。
更改的服务完成构建后，部署将自动开始。
然后通知集群获取清单，执行任何最后一分钟的配置，并最终部署服务。
| 这是我们利用 Quarkus Kubernetes Config 的地方。 我们将属性转换为预期的 configmaps 和 secrets，这些 configmaps 和 secrets 将部署到命名空间中。 |
下面的示例显示了流水线如何从合并请求过渡到合并，最终发布。
Git 您的 Quarkus 功能
通过将 GitLab 与我们的 Quarkus 平台紧密集成，我们的流程变得更加流畅，并提供了一站式工具、日志和监控，就在 GitLab 中……
现在，团队首先会查看 GitLab，而不是必须与不同的工具和应用程序交互（高级场景除外）。
覆盖率和质量报告
Jacoco 为每个项目生成覆盖率报告。 指标在每个服务的整个生命周期中都得到维护和可见。
此外，Code Climate 用于衡量默认分支和每个合并请求之间在每个服务的整个生命周期内的质量变化。
分布式服务跟踪
Jaeger 为我们提供了有关如何使用我们的 API 的见解，并使我们能够跟踪多个服务之间的交互。
| Jaeger 对我们来说非常宝贵，因为我们非常依赖于经常与其他服务通信的单一职责服务。 |
结论
将 Quarkus 深度集成到 GitLab 中为我们的流程增加了重要价值，并且非常值得付出的一点努力。
在我们的公平竞争理念的基础上，开发、调试、部署和监控云原生服务比以往任何时候都更优化。
由于 Quarkus 与云技术的自然契合，以及通过扩展提供的功能，我们已经能够创建一个全面的 DevOps 生态系统，否则这将是难以设置和协调的。
新流程的亮点包括
-
可以在隔离状态下处理服务
-
并行构建减少了交付更改的时间
-
常用工具在 GitLab 中可用
-
预览服务使协作更容易
-
部署是完全自动化的
最终，我们不必培训员工使用不同的工具，授予超出 GitLab 的访问权限，或直接公开任何基础设施。
这个新流程虽然看起来很密集，但易于管理和构建，并且几乎无需人工干预即可实现完全自动化的端到端。
我们使用的关键功能现在可以在 GitLab 中访问，这有助于我们更快地迭代、协作和做出反应。
