Cmeet2023·第二期 | DevOps助力研发效能提升

[墨泪]

新的一年，相信很多产品技术团队把研发效能提升列为重要的目标，甚至还有团队为此专门成立了项目组。近期围绕研发效能提升的讨论不绝于耳，但如何搭建有效体系、如何进行实践运营、怎样使用合适的效能提升工具，却鲜有文章具体阐述。

作为如今在开发行业兴起的热门概念，DevOps 正以某种形式有效地提高提高全球软件公司的上市速度、可销售性、创新和产品质量。本文将以DevOps工具为核心，结合众多技术专家的知识分享，以实际案例为研发效能提升提供思路与解决方案。

 

“DevOps+云原生”

业界公认的“云原生”（Cloud Native）概念是Pivotal公司的Matt Stine于2013年首次提出，然后被一直沿用至今并发扬光大。它是云计算区别于传统IT架构的根本特征，云原生应用正在成为云计算主流的服务形式。企业通过采用基于云原生的技术和管理方法而生成的应用，就能够持续地享受到“云计算”提供的源源不断地高效服务。

DevOps “元素周期表”

Daocloud道客技术专家朱晓武认为，“应用架构和部署形态决定了CI/CD的技术”。传统应用如 Jenkins构建jar、maven仓库、artifactory发布、VM化部署等已然逐渐成为过去式，而镜像化构建、原生制品仓储、容器化测试、k8s化部署、可观测性、微服务治理等现代化应用为云原生CI/CD的开发提供了广阔的平台。因此，DevOps与云原生相结合能够更好地发挥云原生技术低成本、多租户特性等优势，有效提升研发效能。

以Argo Rollouts为例，Argo Rollouts是一个Kubernetes控制器和一组CRD，为Kubernetes提供高级部署功能，例如蓝绿部署、金丝雀部署、金丝雀分析、实验和渐进式交付功能。在研发项目周期上，Argo Rollouts提供了更快速，更安全，更可靠的应用程序更新，从而缩短研发周期和上线时间；在项目研发质量上，它能够提供更灵活，更智能，更自动化的流量控制和指标分析，从而提高研发质量和用户体验；在产品竞争力上，Argo Rollouts又能实现更多样，更科学，更优化的测试方法，从而增强研发创新和竞争力。

 

以DevOps作为开发和安全中间的支点

作为技术圈成员，相信大家对Java一定不会陌生，自1995年Java推出之后，马上给互联网的交互式应用带来了新面貌，而如今，Java应用版本管理逐渐变得更复杂、难度更大。捷蛙科技JFrog (中国) 技术总监王青认为，Java应用版本管理的难处主要集中在五个方面。

其一，以传统方式进行的Java应用版本管理依赖管理关系复杂，无法排查某个组件的使用情况，例如：公司各个团队都用不同版本的log4j.jar，导致漏洞排查难以进行；其二，研发团队经常不遵循SemVer 语义进行版本命名，例如：app命名永远使用 app-A.jar。其三，没有统一的制品管理仓库，例如：Nexus、Harbor。其四，制品同步难，开发如何推到生产？多地数据中心如何同步？其五，开源组件治理难，研发人员通常无法获知项目用了哪些开源组件，无法阻止高危漏洞组件。

JFrog Artifactory将DevOps变成开发和安全中间的支点

那么，如何通过DevOps实现高效的 Java 应用版本管理？王青以JFrog Artifactory产品为案例为我们提供了思路：JFrog Artifactory通过依赖管理、版本号管理、联合晋级模型、基于Project的版本管理、联邦仓库实现制品实时同步和开源组件治理等产品方案，成功将DevOps变成开发和安全中间的支点，从而实现更高效的 Java 应用版本管理。

 

DevOps 实战：“Kubernetes + GitLab CI” 

1. Kubernetes 环境微服务应用开发

微服务应用开发环境通常包含大量服务，完整部署资源需求高，本地资源难以满足，同时部署复杂，搭建完整本地开发环境的难度大，新人开发门槛高，此外，微服务应用开发环境的协作成本较高，本地各微服务需要及时同步他人的修改等，这些都是微服务应用开发亟待解决的痛点。

倍基智能(倍赛) 技术总监王家军认为，对于小型技术团队，如果想使用微服务架构，但又不想引入太多微服务组件，可以尽量复用 Kubernetes 所提供的功能，如使用 Service 资源来进行服务注册发现、使用 Ingress 资源来对外提供服务、使用 ConfigMap 资源来管理应用配置。

如何配置融合开发环境？王家军提供了一些可行思路：

• 本地个人开发环境 + Kubernetes 连调开发环境 = 融合开发环境
• 本地开发环境只启动当前需要开发的微服务，资源消耗极低
• 通过端口映射对外暴露 Kubernetes 连调开发环境里的内部服务

2. GitLab CI 软件自动化构建和发布

GitLab CI是一套配合GitLab使用的持续集成系统（当然，还有其它的持续集成系统，同样可以配合GitLab使用，比如Jenkins）。而Pipeline是Gitlab根据项目的.gitlab-ci.yml文件执行的流程，它由许多个任务节点组成, 并且用来定义 CI/CD 的具体过程。

详细而言，Pipeline 包含 Job 和 Stage 两类对象，Job 定义做什么，Stage 定义什么时候做；每个 Job 必须且只能归属到某个 Stage，并按 Stage 的顺序执行，同一个 Stage 下的多个 Job 并行执行；Job 由对应类型的 Runner 来执行，通过 Tag 来指定 Runner 类型；Pipeline 执行可在提交代码时自动触发，也可手动触发。

以GitLab CI Java服务构建和部署为例，王家军也为我们提供了一些可行思路：

• 构建 Jar 包。此过程包含登录私有 Maven 仓库与缓存 Maven 依赖包
• 构建 Docker 镜像。首先要等待 Docker 服务可用，然后登录私有镜像仓库，并使用上次构建镜像来加速本次构建
• 部署服务到 Kubernetes 集群。开发人员需设置集群连接配置 Kubeconfig，之后使用隐藏 Job 来抽取共同定义

 

天下武功，无坚不摧，唯快不破。时代发展到现在，客户的需求瞬息万变，市场的风向也难以预测。作为企业，想要生存下去，只有让自己变得更快，而DevOps 使一切成为可能。拥有 DevOps ，团队可以定期发布代码、自动化部署、并将持续集成 / 持续交付作为发布过程的一部分，助力企业与团队提升研发效能。关注CSDN，我们将持续关注研发效能体系构建的最新状况与热点话题，为大家分享最新的行业洞察与知识干货！