Trendyol 搜索团队的CI/CD流水线结构

标签: trendyol 搜索 团队 | 发表时间:2020-07-28 22:26 | 作者:frankinbj
出处:http://weekly.dockone.io

本文将描述在Trendyol的搜索团队中,我们的流水线(pipeline)是如何设计的,以及我们的CI/CD都有哪些特点:
• 为QA和开发团队创建同步分支
• 用Sonar分析构建项目
• Sonar质量门状态检查
• QA同步功能流水线
• 为测试部署一个基于特性的容器
• 使用隔离的QA环境进行基于特性的QA测试
• 自动创建合并请求
• Consul动态配置推送
• 基于环境的部署
我们团队的目标很简单,就是能够通过单击来部署项目。在这条路上,我们已经设计并实践了很多流水线,现在,我们决定建立一个体系结构,这就是下面将要阐述的。
创建同步分支
一切都从将代码发送到远程仓库的功能分支开始。一旦代码被发送到特性分支,我们的特性流水线流程就被触发,我们开始第一个阶段,“创建QA分支”。对于QA验收测试项目,我们创建一个与任务同名的分支。有了这个分支,QA团队开始编写他们的测试,并且开始同步开发测试。
使用Sonar analysis构建项目
我们的项目有多种平台和语言,有用Java、GoLang、Scala、Python和Shell编写的项目。每种语言都可能需要不同的平台。我们已经创建了基础镜像来满足这些需求,并为此构建所有这些流程,目前仍在构建一些平台的定制化。
下面讨论一下基于java项目的构建过程。构建操作从下载maven依赖包开始。下载完maven依赖包后,继续运行单元测试。单元测试结果被创建为报告,该报告被发送到Sonar服务器进行sonarqube分析。在Sonar服务器上,这份报告的结果会通过我们为团队制定的质量门进行分析。根据分析结果进行条件决策,如改进工作需要再次进行。质量门流程会重复进行,直到条件满足为止。
在构建和sonarqube测试完成之后,会询问sonarqube服务器相关的分析是否成功,如果成功,CI / CD进程将继续下一步。如果不成功,就像我刚才提到的,重复改进过程再进行重新分析。在这个阶段,CI / CD进程失败,进程不会继续。
QA同步特性流水线
我们的QA团队是一个后端测试团队。因此,它们测试的结构通常是API、消费者、生产者和业务逻辑。在这种情况下,我们需要有大量的验收测试,这些测试完全自动化地进行。这个自动化的结构完全集成到CI / CD过程中。在这些自动化测试中,我们的隔离测试环境所得到的各项测试数据完全能够满足测试要求。
这个隔离的测试环境由数据注入代码和一个elasticsearch数据源组成。这些代码通过从真实数据创建一个数据集来满足业务相关的请求,随后导入到elasticsearch的索引。
正如您从流水线中看到的,在运行这些测试任务和API同时使用该源时,我们的数据源是一种隔离的结构。由于我们的API在运行测试时使用此资源,因此我们基于业务的测试提供了相关数据集对业务逻辑的控制。
一旦开发工作开始,我们的QA团队就会并行地为相同的任务编写测试任务。在编写测试任务时,如果有必要,可以把测试所需的数据集进行编排并索引到隔离的测试环境中。这样,使用单元测试来测试基于特性的代码部分,通过验收测试来保证准确性。在功能流水线开启合并请求之前,我们会完全自动地完成此操作。
使用这样的结构,我们可以在不影响现有结构的情况下完成测试,并且可以正确地测试新的作业,不会出现任何问题。
为测试部署一个基于特性的容器
我之前分享了一篇关于我们的部署过程是如何进行的文章。你可以从这里的链接( https://medium.com/trendyol-te ... 8a5a4)访问。
我想讲一下我们刚刚实施的特性流水线结构。我们的流水线是根据需求设计的,我们认为它非常有用,所以希望分享给大家。
作为一个团队,我们的目标是设计一个完全基于特性的CI / CD流程,并在我们的特性工作合并后拥有一个完整的可以上生产的代码库。为此,我们必须有一个经过充分测试的可用于生产的代码。
我们想到了一个实现这一点的方法。编写QA测试和特性部署,而且是同时在基于特性的流水线中执行,我们能同时完成这两项吗,还要保证手中的特性流水线是完全测试过的,直接上生产的代码。这是我们的想法,随后我们就开始了对这个想法的开发。
作为该结构的第一阶段,我们做了前面提到的“创建QA分支”的工作,并开始与QA团队同步开发。第二阶段是将基于此特性的代码部署到stage环境中。我们使用前面文章提到的部署结构实现了这个部署,通过将项目命名为“branchName-appName”来部署项目。我们使用任务代码作为分支名称,例如,SS-1867,当我们将其与项目名称结合使用时,我们创建了一个基于特性的且唯一的部署名。
我们通过apply deployment.yaml和service.yaml将deployment实施到kubernetes。此,我们就现在有了一个在Kubernetes环境中运行的基于特性的应用程序。但是,我们有一个问题,我们如何执行请求路由?我们决定使用ISTIO的虚拟服务特性来执行请求路由,从而解决这个问题。

apiVersion: apps/v1
kind: Deployment
metadata:
name: ${BRANCH_NAME}-${APP_NAME}
namespace: {namespace}
labels:
version: ${BRANCH_NAME}
app: ${APP_NAME}
chart: ${APP_NAME}-${SHORT_SHA}
release: ${BRANCH_NAME}-${APP_NAME}
heritage: Tiller
spec:
hostNetwork: true
dnsPolicy: ClusterFirstWithHostNet
replicas: 1
revisionHistoryLimit: 2
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 1
selector:
matchLabels:
app: ${BRANCH_NAME}-${APP_NAME}
release: ${BRANCH_NAME}-${APP_NAME}
template:
metadata:
labels:
app: ${BRANCH_NAME}-${APP_NAME}
release: ${BRANCH_NAME}-${APP_NAME}
spec:
serviceAccountName: ${APP_NAME}-sa
terminationGracePeriodSeconds: 120
restartPolicy: Always
imagePullSecrets:
- name: {registry-name}
containers:
- name: ${BRANCH_NAME}-${APP_NAME}
image: {registry-url}/${APP_NAME}:${SHORT_SHA}
imagePullPolicy: IfNotPresent
env:
- name: SPRING_PROFILES_ACTIVE
value: "stage"
ports:
- name: http
containerPort: {port}
protocol: TCP
livenessProbe:
httpGet:
path: /_monitoring/health
port: http
successThreshold: 1
failureThreshold: 3
initialDelaySeconds: 90
periodSeconds: 30
timeoutSeconds: 100
readinessProbe:
httpGet:
path: /_monitoring/health
port: http
successThreshold: 1
failureThreshold: 3
initialDelaySeconds: 90
periodSeconds: 30
timeoutSeconds: 100
resources:
limits:
cpu: 2
memory: 2Gi
requests:
cpu: 1
memory: 1Gi

apiVersion: v1
kind: Service
metadata:
name: ${BRANCH_NAME}-${APP_NAME}
namespace: {namespace}
labels:
app: ${BRANCH_NAME}-${APP_NAME}
chart: ${APP_NAME}-${SHORT_SHA}
release: ${BRANCH_NAME}-${APP_NAME}
heritage: Tiller
spec:
type: ClusterIP
ports:
- port: {port}
targetPort: http
protocol: TCP
name: http
selector:
app: ${BRANCH_NAME}-${APP_NAME}
release: ${BRANCH_NAME}-${APP_NAME}

我们开始了ISTIO虚拟服务的开发,并思考路由匹配规则。我们决定使用定制的header来创建这个规则。我们决定传递branchName作为定制header的key,并将分支名称ss-1867作为value。
通过这种方式,我们为ISTIO虚拟服务定义了匹配规则,如下。
kind: VirtualService
apiVersion: networking.istio.io/v1alpha3
metadata:
name: ${BRANCH_NAME}-${APP_NAME}
namespace: {namespace}
spec:
hosts:
- {apiurl}.{domain}.com
gateways:
- {gateway-name}
http:
- match:
- headers:
branch-name:
exact: ${BRANCH_NAME}
route:
- destination:
host: ${BRANCH_NAME}-${APP_NAME}
port:
number: {port}
headers:
response:
add:
branch-name: ${BRANCH_NAME}
当这个定制的header信息随请求一起提供时,ISTIO将虚拟服务请求路由到我们基于新特性的deployment下。通过这种方式,我们现在能够在一个staging环境中测试基于特性的deployment,对于QA测试,我们能够在不将代码合并到开发分支的情况下测试我们的代码。
如果有匹配的基于特性的部署,也就是说,此虚拟服务定义检测分支并通过执行请求路由将流量重定向到此部署。如果在这个阶段没有匹配,流量将被导向基于开发的部署。由于这种情况,我们返回先前发送给请求header的“branchName”header信息,以理解和验证它是否被定向到基于特性的部署。当我们在响应header信息中看到这个定制的header信息时,我们就知道请求路由已经成功完成了。
当然,只要特性分支存在,这个header信息就有效。在此期间,开发过程将继续进行。进行了特性开发和基于特性的测试改进。持续的特性开发一直开发到生产就绪为止。
在完成特性开发和测试之后,我们现在进入合并请求打开部分。与此同时,不再需要的基于特性的部署、服务和虚拟服务开发将从stage环境中清除。
在合并请求开启后,团队成员检查代码和测试。复审过程将重复进行,直到合并请求得到批准,此过程包括批注、重新开发(如果需要的话)和重新测试。
决定执行合并意味着特性已经被完全测试,并且保证产品已经准备就绪。这一阶段后,代码将被合并和打包,以进入预生产环境。
我们基于特性的流水线是这样的


基础流水线
我们的基础分支是是开发分支。我们的合并操作从基于特性的分支到开发分支。在这个过程之后,我们基于开发的分支操作就开始了。
我们基于开发的流水线包括以下步骤,
• 推送配置(Config Push)
• 构建
• Sonar检查
• 部署到Dev
• 部署到Stage
• 测试
• 部署到预计生产(PreProd)
• 部署到内网
• 部署到生产

简单解释一下这些步骤:
在Config Push阶段,我们repo中的Config被发送到Consul的Configs,而pods的Config无需重启就被更新了。(我们计划在另一篇文章中再详细地介绍一下这个结构。)
在“Build”阶段,基于开发分支执行构建和sonarqube分析。在这个阶段构建的代码库现在是一个可用于生产的代码库。
在“Sonar check”阶段,根据质量门做基于开发的代码检查分析,如果结果条件满足,CI / CD过程继续成功。
Trendyol通常有五种环境。它们分别是Dev环境、Stage环境、Pre-Prod环境、Internal环境和Production环境。我们CI / CD过程中的“Deploy to {ENV}”阶段代表了对这些环境的部署,可以在我前面提到的文章中找到更详细的信息。
在部署到开发和Stage环境之后,将重复并重新运行QA的测试自动化,以预测和测试合并操作期间可能出现的任何问题。
这个阶段之后,代码库已经经过测试并被批准为生产就绪。这个代码基现在可以部署到Pre Prod、Internal和Production环境中。但是,目前,我们正在自动进入Pre-Production环境,这一阶段,需要等待UAT测试的批准。将来,我们将删除这部分的手动流程,并切换到完全自动化。
感谢您一直阅读到此,并与我们一起体验了我们的经历。我代表搜索小组和trendyol小组向您表示感谢。
原文链接: https://medium.com/trendyol-te ... 345f5

相关 [trendyol 搜索 团队] 推荐:

Trendyol 搜索团队的CI/CD流水线结构

- - DockOne.io
本文将描述在Trendyol的搜索团队中,我们的流水线(pipeline)是如何设计的,以及我们的CI/CD都有哪些特点:. • 为QA和开发团队创建同步分支. • 用Sonar分析构建项目. • Sonar质量门状态检查. • QA同步功能流水线. • 为测试部署一个基于特性的容器.

IBM收购搜索引擎初创企业Blekko技术及团队

- - 36氪
蓝色巨人今天在博客 宣布已收购了搜索引擎初创企业Blekko的技术,后者的团队已经加盟IBM Watson. 打开Blekko网站我们看到先是弹出如下的页面,然后网站被跳转到Watson的博客上. Blekko原本是一家做垂直搜索引擎的初创企业,由全球首个病毒制造者Rich Skrenta与人联合成立于2007年.

团队

- Lorna - 坏脾气的小肥
我最近心情起落比较大,如果把时间线再拉长一点,则是去年多自负,今年多自责. 冷静下来的时候也会想,我能不能做得更好. 每一个团队都有它的长处,有它的短处,对于团队的缺陷首先要问自己几个问题:. 1、有没有激励大家全心全意地认同和投入这个项目. 2、有没有分工合理,使每个人认同和投入自己的任务. 3、他的缺陷是否可以通过工作指导、严格督促,在半年或一年时间里自我完善.

深度搜索

- - 译言最新精选
译者: HorseHour 原文地址: streamhacker.com. 当我们准备发布 Weotta时,我们已经为如何描述它犯了难. 我们使用了机器学习和自然语言处理吗. 我们最终觉得“深度搜索”是对我们工作最贴切的描述,它是一个超越了基本文本搜索的复杂搜索系统的简洁描述. 无需赘言,不管怎么看,我们都不是这个领域唯一的一家公司;谷歌和很多其他公司都在对深度搜索的各个方面进行研究.

团队管理101招

- 狂之想 - C++博客-牵着老婆满街逛
转载自:http://www.iteer.net/modules/doc/article.php?storyid=1402. 无论你是新手还是资深管理人,对你而言,管理好团队都是重要且具激励性的挑战. 切记:每位成员都能为团队作出一些贡献. 谨慎地设定团队目标,且认真严肃地对待它们. 尽早决定何种形态的团队适合你的目标.

DBA团队的使命

- 2sin18 - Alibaba DBA Team
DBA团队的使命:提供高可用、高性能、可扩展的数据存储服务. 高可用:可用性是运维的根本,我们不管做什么事情,都要把可用性放在第一位. 高性能:对性能的关注是我们一直坚持、做的最好的一面,仍需要继续做到极致. 可扩展:也就是最适合的,易部署,可线形透明伸缩. 数据存储:不只是关注某个数据库本身,是基于对各种最先进的数据存储技术的精深理解,提供最专业的服务.

谈团队知识管理

- - 人月神话的BLOG
如果要谈学习型团队,那么团队知识管理就相当重要,团队知识管理介于企业知识管理和个人知识管理之间,核心是知识能够成为整个团队的资产,并为团队创造价值. 今年在团队知识管理上,重点就是按照cmmi的一些思路,形成指导书,规范流程,工具模板,培训教材,检查单的完整知识库积累. 明确各个岗位职责和分工边界,能够按着规范流程做事情,大量前期积累的知识库又能够帮助团队成员快速的学习和解决问题.

谈技术团队目标

- - Tim[后端技术]
技术主管新年想得最多的一件事必定是如何比上一年做得更好. 宏大的目标设定每个团队都会做,谈几个不引人注意的小问题. 见过一些技术团队将计划定义为“按时完成需求”,需求驱动并没有什么不对,但是研发工作仅考虑被动需求的话是很难做好. 之前完成的许多需求有什么共性. 经常出问题/bug/故障的项目/功能/模块是哪些.

团队沟通杂感

- - 人月神话的BLOG
随时随地的短时间的,快速迭代的培训和教练作用远远大于正规的系统培训. 系统性培训一个是针对性往往弱,另外一个就是对团队成员有较高的要求,即自我强烈的系统性学习欲望. 走动时管理目的是及时的发现各种问题和团队技能之欠缺点,有针对性的进行沟通和经验传递,这需要团队管理者有敏锐的洞察力,不能脱离到团队工作事务之外.

某种理想的团队

- - 博客园_知识库
  (这篇文字灵感缘起于昨天发的一条半开玩笑半自嘲的 微博,由于设置了IFTTT被同步到我的 Twitter上,又被欢乐地转发了很多,估计是触发了某种有趣的共鸣). 现在我招聘已经被逼成这样了:先发自己和团队成员的简历给候选人,看你有没有兴趣跟一群这样水准的人一起做事,然后我争取到“面试你的机会”.