分类目录归档:生活

Using Nexus 3 as Your Repository – Part 3: Docker Images

This is the third and last part of a series of posts on Nexus 3 and how to use it as repository for several technologies. (Part 1Part 2.)

Stop-OutdatedContent

Installation

Check out the first part of this series to see how we installed and ran Nexus 3 using a single docker command. Just do that and the installation is done.

Configuring Nexus as a Docker repo

What we will do:
– create a private (hosted) repository for our own images
– create a proxy repository pointing to Docker Hub
– create a group repository to provide all the above repos under a single URL

I suggest you to create a new blob store for each new repo you want to create. That way, the data for every repo will be in a different folder in /nexus-data (inside the Docker container). But this is not mandatory for it to work.

By default, the Docker client communicates with the repo using HTTPS. In my use case I had to configure it with HTTP, because we didn’t have the certificate nor the knowledge on how to obtain it.

Important to notice: the Docker repo requires 2 different ports. We are going to use 8082 for pull from the proxy repo and 8083 for pull and push to the private repo.

I had some problems with slightly older versions of Docker, so I strongly suggesting you to start with the version that I’ve tested with, that is 1.12.3.

private repo

A repository for Docker images that your team creates.

Create a new Docker (hosted) repository and configure it like:

rafael-1

proxy repo
A repository that proxies everything you download from the official registry, Docker Hub. Next time you download the same dependency, it will be cached in your Nexus.

Create a new Docker (proxy) repository and configure it like:

rafael-2
rafael-3


group repo
This will group all the above repos and provide you a single URL to configure your clients to download from to.

Create a new Docker (group) repository and configure it like:

rafael-4
rafael6

You can create as many repos as you need and group them all in the group repo.

This step is actually optional to use Nexus 3 as a Docker repository, because we can stick to pulling and pushing to the proxy and hosted repositories as will be discussed later.

Configuring your clients and projects to use your Nexus repos
To interact with your repo, the first thing is to configure the Docker daemon in your machine to accept working with HTTP instead of HTTPS.

How exactly to do this config depends on your operating system, so you should check dockerd documentation. On RHEL I did it putting this content in /etc/docker/daemon.json:

{
  "insecure-registries": [
    "your-repo:8082",
    "your-repo:8083"
  ],
  "disable-legacy-registry": true
}

You have to restart the daemon after setting this (sudo systemctl restart docker).

On Windows or Mac you should config your deamon in a box like this:

rafael-5

Now we have to authenticate your machine to the repo with:

docker login -u admin -p admin123 your-repo:8082
docker login -u admin -p admin123 your-repo:8083

This will create an entry in ~/.docker/config.json:

{
	"auths": {
		"your-repo:8082": {
			"auth": "YWRtaW46YWRtaW4xMjM="
		},
		"your-repo:8083": {
			"auth": "YWRtaW46YWRtaW4xMjM="
		}
}

To pull images from your repo, use (notice port 8082 being used):

docker pull your-repo:8082/httpd:2.4-alpine

To push your own images to your repo, you have to tag the image with a tag that points to the repo. This is strange to me, since I was trying to think about Docker tags the same way I do about Git tags, but they seem be somewhat different (notice port 8083 being used):

docker tag your-own-image:1 your-repo:8083/your-own-image:1
docker push your-repo:8083/your-own-image:1

To pull your own images from the repo, you can use:

docker tag your-own-image:1 your-repo:8082/your-own-image:1
# or
docker tag your-own-image:1 your-repo:8083/your-own-image:1

Both ports will work. I suspect that is because using port 8083 will connect directly to the hosted repo, whilst using port 8082 will connect to the group repo, which contains the hosted repo. I suggest you to stick to port 8083 to avoid duplicate images in your machines. If you chose to stick with port 8083 to pull your own images, you probably could skip creating the group repo, if you prefer.

Git 分支开发规范

Git 是目前最流行的源代码管理工具。 为规范开发,保持代码提交记录以及 git 分支结构清晰,方便后续维护,现规范 git 的相关操作。

image

分支管理

分支命名

master 分支

  • master 为主分支,也是用于部署生产环境的分支,确保master分支稳定性
  • master 分支一般由develop以及hotfix分支合并,任何时间都不能直接修改代码

develop 分支

  • develop 为开发分支,始终保持最新完成以及bug修复后的代码
  • 一般开发的新功能时,feature分支都是基于develop分支下创建的

feature 分支

  • 开发新功能时,以develop为基础创建feature分支
  • 分支命名: feature/ 开头的为特性分支, 命名规则: feature/user_module、 feature/cart_module

release分支

  • release 为预上线分支,发布提测阶段,会release分支代码为基准提测
当有一组feature开发完成,首先会合并到develop分支,进入提测时,会创建release分支。
如果测试过程中若存在bug需要修复,则直接由开发者在release分支修复并提交。
当测试完成之后,合并release分支到master和develop分支,此时master为最新代码,用作上线。
复制代码

hotfix 分支

  • 分支命名: hotfix/ 开头的为修复分支,它的命名规则与 feature 分支类似
  • 线上出现紧急问题时,需要及时修复,以master分支为基线,创建hotfix分支,修复完成后,需要合并到master分支和develop分支

常见任务

增加新功能

(dev)$: git checkout -b feature/xxx            # 从dev建立特性分支
(feature/xxx)$: blabla                         # 开发
(feature/xxx)$: git add xxx
(feature/xxx)$: git commit -m 'commit comment'
(dev)$: git merge feature/xxx --no-ff          # 把特性分支合并到dev
复制代码

修复紧急bug

(master)$: git checkout -b hotfix/xxx         # 从master建立hotfix分支
(hotfix/xxx)$: blabla                         # 开发
(hotfix/xxx)$: git add xxx
(hotfix/xxx)$: git commit -m 'commit comment'
(master)$: git merge hotfix/xxx --no-ff       # 把hotfix分支合并到master,并上线到生产环境
(dev)$: git merge hotfix/xxx --no-ff          # 把hotfix分支合并到dev,同步代码
复制代码

测试环境代码

(release)$: git merge dev --no-ff             # 把dev分支合并到release,然后在测试环境拉取并测试
复制代码

生产环境上线

(master)$: git merge release --no-ff          # 把release测试好的代码合并到master,运维人员操作
(master)$: git tag -a v0.1 -m '部署包版本名'  #给版本命名,打Tag
复制代码
image

日志规范

在一个团队协作的项目中,开发人员需要经常提交一些代码去修复bug或者实现新的feature。而项目中的文件和实现什么功能、解决什么问题都会渐渐淡忘,最后需要浪费时间去阅读代码。但是好的日志规范commit messages编写有帮助到我们,它也反映了一个开发人员是否是良好的协作者。

编写良好的Commit messages可以达到3个重要的目的:

  • 加快review的流程
  • 帮助我们编写良好的版本发布日志
  • 让之后的维护者了解代码里出现特定变化和feature被添加的原因

目前,社区有多种 Commit message 的写法规范。来自Angular 规范是目前使用最广的写法,比较合理和系统化。如下图:

image

Commit messages的基本语法

当前业界应用的比较广泛的是 Angular Git Commit Guidelines

具体格式为:

<type>: <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
复制代码
  • type: 本次 commit 的类型,诸如 bugfix docs style 等
  • scope: 本次 commit 波及的范围
  • subject: 简明扼要的阐述下本次 commit 的主旨,在原文中特意强调了几点 1. 使用祈使句,是不是很熟悉又陌生的一个词,来传送门在此 祈使句 2. 首字母不要大写 3. 结尾无需添加标点
  • body: 同样使用祈使句,在主体内容中我们需要把本次 commit 详细的描述一下,比如此次变更的动机,如需换行,则使用 |
  • footer: 描述下与之关联的 issue 或 break change,详见案例

Type的类别说明:

  • feat: 添加新特性
  • fix: 修复bug
  • docs: 仅仅修改了文档
  • style: 仅仅修改了空格、格式缩进、都好等等,不改变代码逻辑
  • refactor: 代码重构,没有加新功能或者修复bug
  • perf: 增加代码进行性能测试
  • test: 增加测试用例
  • chore: 改变构建流程、或者增加依赖库、工具等

Commit messages格式要求

# 标题行:50个字符以内,描述主要变更内容
#
# 主体内容:更详细的说明文本,建议72个字符以内。 需要描述的信息包括:
#
# * 为什么这个变更是必须的? 它可能是用来修复一个bug,增加一个feature,提升性能、可靠性、稳定性等等
# * 他如何解决这个问题? 具体描述解决问题的步骤
# * 是否存在副作用、风险? 
#
# 如果需要的化可以添加一个链接到issue地址或者其它文档
复制代码

参考链接

【需求】我是怎么带几个学生从零开始做一个研发中台的

接触中台的概念是在18年,互联网还在流行DevOps,微服务,资料异常多,但是却又是异常的敷衍,几乎没有一套完整的可落地的开源框架,大多就是一个权限系统、一套微服务脚手架,或者说一套似乎有完善落地的Docker或者K8s,但是能不能真正落地起来,到底怎么落地,不清楚,也不知道,符合不符合场景,查找到的资料都是说好,但是能不能落地,心里很是没底。

考虑左右,从零搭建了一套开源的研发中台,带着几个大学生,利用业余时间,用了大概1年多的时间,从过程的团队建设,试点尝试,过程分工,到形成一套中台项目管理流程,整个最终可以勉强实现下来,也是感慨万千,唏嘘不已。

整个研发中台架构 (http://cloud.linesno.com)

为什么要做这样的中台,还要从零开始

1、需要知识积累和沉淀,不断的反思,不断的吸收,不断成长

有一定工作的经验的开发肯定知道,企业开发中包含有大量的、重复的CURD(增删查改),以及重复性组件,还有不断的获取和重复使用的学习资料等等,这些重复性的东西,每次使用都有新的感悟和感受,如果没有积累,每次都可能从零开始,无法达到沉淀和积累,从而浪费大量的时间和精力在上面,如温水煮青蛙,久而不知,而自茧作缚。

而相对的另一个例子,滴水穿石,之所以可以穿石,就是因为不断在前面的积累基础上,加上不断的坚持,如果每次从零开始滴,也许也可以穿石,但是消耗的成本和时间,也是很巨大的。学习也是如此,加上不断的积累,在一项技能上不断的学习积累,日积月累,不管有没有达到”穿石“,但是一定有会不小的进步。

2、不想把时间浪费在无用的点上,更想专注,不用站在巨人的肩膀,自己就有肩膀

有一种慢慢的体会和感悟,叫“ 欲速则不达 ”, 每个事情都有消耗时间、精力、过程,而人本身就是一个有限的特种,怎么样可以在有限的时间里面,更好的完成和学习,需要的不是其它,而是【专注】。所谓的专注并不是要时时刻刻的去想,去学习,而是坚持长久的做这个事情。

类似的如常见的1万小时成专家说法。 中台搭建的目的之一,就是节省用时间,去掉重复无用的东西,在有限的时间里面,更好的专注在新的点上,不断的前进,不断的提升自我。

3、落地不是一个人的事情,是整个团队的事情,要学会带团队一起成长

一套中台,需要涵盖的内容很全面,每个模块,领域都需要有对应的人员,这个时候,不是一个人能完成,而是需要调用团队的力量去实现。 就像打球,即使说有一个人球技出神入化,但是他一样也需要传球的人,助攻的人。想要落地这个平台,就需要有团队参与,发挥团队优势,提升整个团队气氛,团队合作,合理分工等,这些都需要学习和实践。

最后获利的不是某一个人,也不是具体谁谁,而是团队的每一个成员,在这个过程中能发挥、创造、体现出他们自己的价值,团队成员的见识、协作、信心等的成长。不管这个过程是艰辛也好,埋怨也罢,你走你才知道,而不是听谁说你才知道,这就是你自己的经验,自己的价值。

带人的过程是要学会发挥自己的能力的同时,更要学会带团队一起成长。

4、需要一套完善的研发中台打磨,站在前面的基础上提升

在出来一套可见东西之后,可能比想像的还要“千疮百孔”,还要不堪,甚至连往回看的勇气都没有。但是正是这样的东西,摆出来,拿出来,虚心接受所有的问题和建议,然后在后期一步步消化,一步步打磨,而形成出来的,就是自己的产品,或者说,把自己打磨成一套精品。

技术总会在不断的发展,需要有一个产品,一个中台可以让你,或者我在更好的中台上面做预研,而出来的成果,也会比从零起个“Hello World”强得多,毕竟你已经在场景里面,已经在平台里面,安全,测试,规范,可用性,健壮性等等都有中台的验证和支撑。

开发接入研发中台的HelloWorld说明

没有实战基础的学生,是否能组成团队

1、为什么要选择学生团队,不找有工作经验或者社会经验的人

找学生,这也是B方案,前面的A方案,最初规划,团队组件的是找的是同学和有工作经验,还找了以前老师作为指导,沟通好,拉了10几个人成团,便开始。但是这个过程经过不到2个月就发现问题,异地沟通困难,团队鸡血也很快消磨,有转成观望态度,原因不免是 工作忙,时间精力不足,整体的技术预研也几乎停滞不前,原计划的分工,很快无法往下,研发任务开始体现出敷衍趋势,成立的微信群很快形成死群。开始信息发出的时候,还有几个人附和,到后面,可能连附和都没有。

很快,就有提出要退出研发计划,同时各种小群也开始建立,这些都意味着团队有危机的趋势,不管是信任和人心开始出现浮动,放置观察了1个多月,考虑同学,朋友,还有后面的各个因素,无奈放弃此方案,成员停止研发沟通联系,慢慢的转向分享文章,咨询经验等方式,进而消停。

由于之前在校时有一定的学生接触、组织经验,B方案实施也是很快落地,不到2个星期的时间,也成立了10几个人的群。学生没有实战经验,不管是沟通还有动手,都与实际工作人员有天跟地的区别,而能不能落地,却成为一个最担心的事情。不仅仅如此,学生成团的现象,抱团等情况,过于依赖于师生级别关系(比如较愿意听老师的话),这些都是问题,不过既然A方案放弃,就得全力保障B方案的实施,而且这步的操作过程,更需要严格,可控。

2、怎么进行团队的培养、磨合,最终成为可作战的兵团

学生团队开始份两个组别进行,互相互相隔离的分开,原考虑是分开培养,然后两边达到可控,可对比,以小组作为培养线。一开始活跃气氛远高过之前的团队,也是理解,毕竟学生很有学习的积极欲望。开始的时候,流程按 【培训_学习_考试_分级_练习_评审_重构】 这几个流程,按这几个流程下来,这个过程很快,几乎一个月内就可以完成。

当时整理的等级技能图

过于顺利的流程让我感觉,应该问题不大了,而且很快就可以进入提升学习阶段。考虑左右,虽然考虑可能有难度,由于之前的表现,还是比较有信心,毕竟流程,团队制度有建立雏形。决定开始接入新项目,进行实战练兵。

很显然,我的判断是错的,而且过于过早的接入实战,实战性的要求,沟通,压力等,让组长无法承受压力,而且之前做了一个最大的失误,考虑组长退了,副组长可以顶上,也就是常见的AB岗形式,结果却是组长退了,下面的学生人心异动,而且又是核心成员,很快引起其它成员信任危机,深度做安抚工作,而且减少对应的任务安排,但是最终还是造成内部沟通的不利,需要在任务上进行妥协,而这样的妥协却极度不利的中台的研发和后期的任务安排。这个近乎两个月的组团培养,组团受挫,这不得不让我思考之前的一些策略与方式。

明显,资源开始主要集中在第二组,这个时候,已经开始感觉到,组团的风险和管理上的缺失,不过幸运的是,前面两组留下了很多资料和资源,留下的这组人与上一组留下的成员,从素质上确实也比较高,很快完成了新的组团,而且意识较为统一,在沟通明显都成一气。

也发现,找人组团,不管是人员素质,意志力还有自控力等都有一定的要求,是否看个人有成长的追求等,能克服困难,能坚持。在进行多次任务安排和沟通之后,最终确定留下人员也就只有几个学生。 由原来的差不多30人, 差不多半年的时间里面,经历两轮的练兵和实战,后面一年的时间里面,也有进进出出的,但是最终来说,还是这几个人为核心。

3、怎么消掉学生气,形成接近社会的工作状态

学生团队与实战要是能对接得上,最大的问题是怎么样调整状态,即执行力,沟通能力,协助能力等,合理安排好自己的学习和工作时间,不影响学习,然后又能参与到项目建设中来,学会怎么样安排,怎么样协助,遇到困难的时候怎么面对,使达到任务目标。

而想到的,最好的练习方式,也是要接一个实战,所以,校内跑腿项目就建立了。

校园跑腿项目后台(测试界面)

校内跑腿是考虑到的一个比较接近于实际,涉及到各个方面的能力的项目。从开始的开始的项目立项,然后到团队执行,再到人员计划安排都走过一次,比如计划方案怎么写,中间沟通问题怎么考虑,遇到一些问题,怎么处理。如与社团合作的时候,达不到效果,然后就找会长一起沟通,然后面对问题,而不是说,逃避问题。开始常常是一个问题一遇到就想着可能会失败,“哎,可能就这样了”,这个时候就引导找到问题点,解决问题点。也有说以为安排就需要马上完成的,就告诉他们要有计划,然后哪天完成哪些,一步步执行,不要急于这一天等。

他们有思路,听取他们的意见,尊重他们的意见,有一些想法就多鼓励去做,在执行过程中,也配合他们一起处理,让他们有意识的知道,原来这个是错的,毕竟新人,带有一些学生气,有冲劲。如果执行过程有困难,就多鼓励,如果有错误,就引导并适当批评,有成果,就奖励等。

在两个多月的时间里面,跑腿人员大概有70多人,公众号关注人1000多人,然后订单2000多单,整理了从申请,接单,跑腿,扩展等流程。团队也开始慢慢会了讨论,沟通,使用一些常用的工具,体会互相理解,互相宽容,执行力和作事思维也慢慢了有了提升,了解到生产中实际项目,包括工程代码的研发过程过程,比如怎么对接微信,登陆,支付等(跑腿项目是自研的),至少达到这一步,也是多少有些欣慰的。

关于公众号,原本可以让他自运营的,毕竟流程制度都在,对跑腿人员也有利益,却因为公司的问题,暂时停止了项目,也是较为可惜。

平台研发过程中怎么安排学生团队,学生团队可以做什么

1、过程成员缺少很多东西,怎么安排任务

最主要的是怎么安排研发任务,然后又不能一下给太多任务,还要有一定的成就感,这个倒是为难到我。整体的研发平台涉及到的面太多,从文档,服务器,运行,执行集成,项目代码等都有一整套,这些都要落地,让他们实现任务的同时,能有自己的成果。

前面的整体架构,包括规划这层,在前面团队组建的时候,我这就把整个蓝图做了规划(组团的时间远超过之前的估计,原计划是3个月,最后想不到用了大半年),这也是特别麻烦的一点,无法让他们有参与感,考虑左右,就只能从最简单的开始。

规划的第一版本整体研发中台架构

开始从jenkins 的使用,然后到Git导入批量工程,怎么团队协助,合并代码,怎么帮别人运行中台,从最简单的操作开始,然后怎么本地部署,比如Zookeeper,redis使用场景,工程怎么打包,服务器怎么查看异常,怎么查看日志等,都从最简单的做起,一点点的完成带入感,慢慢体会到平台的过度。在有些了解之后,开始学会使用代码生成器,生成服务工程 ,生成一些组件,生成CURD,做一个学生管理系统。比如日志组件,通知组件,这些都可以让他们使用代码生成器一步完成初版,后期的我再在上面进行优化处理。

规划的第一版本整体学习计划

目标就是让有了解之后,有自己的想法,可以实现自己的想法,从而提升自己,增加自己的知识面,这也是引发出其它的问题,就是知识深入的问题。毕竟面的代价就是深度,而这个,当前做的最好的办法就是,鼓励认真学习大学老师的课程并说明重要性(我们大学都是以学习基础为主),然后计划的时间拉长,比如完成一个Git工程导入的任务可能要1周。

2、消极,缺乏自信,缺乏学习主动性,怎么办

平台研发过程中,最为难的事情就是接触新的事务,常常接触到的回应是 ”我不知道“ ,”我没接触过“ 等,或者说,一接触到新的东西,就莫名的害怕,还有一种比较常见的情况就是,任务往往都是最后一天才有去执行,其实这个问题倒不大,但是却有各种理由来表达 如 “学习任务太多” 或者说 “正在看” 。开始就发现问题,然后就往下问,却不是这么回事。主要还是缺少学习的主动性,然后在追问的时候,又知道这样不对,内心存在愧疚,然后又有点畏惧罢了,这也许是学生团队的可爱之处。

这种情况还是比较常见的,无可否认,即使在实际工作中,这种也是屡见不鲜的。没有接触过就先让他们百度,网上参考,找解决方案,多问人,不要怕问,也不要害怕说问多别人会生气,更不要怕百度拿别人的代码(这是与应试教育不同的地方之一了)。软件以实现功能为主,也鼓励创新,但是更多的是,解决问题为主,做事要有始有终,有成果。针对于另一种情况,却是批评为主,或者说有时候激动,就真要多说几句。并不是不允许最后一天执行,但是最主要的是不能敷衍,对就是对,错就是错,要敢于面对问题,敢于表达自己的问题,也不要怕被别人看见,怕被别人知道,学会面对,然这样才有发现问题,解决问题,避免自欺欺人。

过程以慢慢的培养主动性,自主学习能力,自我提升为主,同时,也要树立正确的三观,工作观,培养的做事的魄力。

3、团队过程最为合理的,感觉还是激起人善意和潜力

其实这个过程中,最害怕也是最难做的,就是怎么带团队的问题,结果不是怕不出成果,而是误导。带的过程,并不是说不敢给压力,更不是说不敢给努力,而是在有限的能力里面,让他们最大的发挥自己,然后创造他们自己的价值,发挥他们自己的价值。其实这个并不是自己的觉悟,而是在自己莫大的团队管理困扰之后,在读到一篇微信文件,介绍“彼得 德鲁克”的时候,一个自己的真实体会。

现实中,不仅仅是这几个学生,在公司内部也一样涉及到一些管理性的工作,带队工作,这个比起学生团队,更加残酷得多,也现实得多。团队成员并不是我们的上下级,而是大家的一种互助,一种共赢。自己在培养别人的同时,别人也在培养你,提高自己更高的标准,锤炼自己的人格,同时超过我们自己的局限,做出自己可能自己都没有想到的事情。提升他们,帮助他们,感恩他们,同时他们会感恩你,跟随你,展现自己的人格魅力,而其它的管理工具,还有书籍,更多的感觉是一种辅助。

带团队过程中,本身也要学会反省,检讨自己,必须要清楚自己在做什么。反之,正如一部电视剧里面说的,孝庄对康熙说的:“鳌拜可能不是自己要反的,而是你把它逼反的”(大意如此,原话不记得了)。而相反的,激起他内心的善意,学会感恩,这样,也许会更好的让他发展自己,即使不在这个团队,在另一个团队,公司也能有这样的心态,久而久之,也肯定会赢得别人的认可 ,创建自己应该有成就。

我们要做成怎么样的目标

1、要形成大平台作为后盾,小兵团进行作战的战略

平台建设从开始的团队组建、培养、到一起作战,项目从开始的架构设计,技术选型,第一行代码,到第一个访问链接,都包含着一层层的努力和坚持。这个过程大概过了1年多,从计划到出来第一版本,基本上能达到“大平台,小兵团“作战的目标。

中台的形象示例

当然,目前的版本还是千疮百孔,有些地方甚至可能不堪,或者不完善,这些都是开始,一个初型。需要不断的实践,团队不断的去上面去锤炼它,让他成长,然后添加自己的想法,表达自己,它就像一个土壤,为下一步的完善的过程提升了基础。

为团队的下一步,后来,甚至未来的蓝图规划, 带来了一种可能,而不再是纸面上理论,更不再是网上这里缺少一块,那里缺少一块,不可落地的东西,而是一个完善的架构,一个完整的研发中台,希望可以为项目管理,开发,管理带来战略上的共赢。

2、持续迭代,不断更快更好的升级和优化

在后续不断的学习中,会不断的去学习,实践自己的想法,整合更好的资源,技术,吸收更稳定的,可用的东西,不断的提升研发中台的能力。

这是一个很长的过程,可能是一年,两年,甚至是五年十年,学习不止,步伐不停,积跬步以至千里,积小流以成江河。打造研发中台的过程其实出来这个并不是中台的精品,而是这个精品是你自己,磨炼的不是所谓的中台,而是你自己。

最后

以上就是带学生团队1年多来走过的历程,从零实现,走过的路程。不算长,也不算短,只是一个过程。

企业统一研发中台实战视频教程

设计

中台研发设计

  • 研发中台架构整体概括和演示
  • 大中台小前台架构模式的适用场景
  • 企业统一研发中台设计基本原则
  • 企业项目管理整体架构设计
  • 中台整体规划和技术
  • 中台技术选型和基础准备

研发

当前只是基础版

  • 基线规划和组织规划
  • 中台研发基础环境搭建
  • 实现基础工程包
  • 实现代码生成器
  • 实现基础服务工程初版
  • 实现基础配置平台
  • 实现基础网关平台
  • 实现平台基础对外门户
  • 测试基础接口实现
  • 测试基础UI实现
  • 运维基础框架
  • 运维基础监控框架
  • 第一个HelloWorld项目

落地

企业落地

  • 第一个项目组接入
  • 多个项目组接入研发平台
  • 项目组沟通计划落地

迭代

后续迭代

  • 业务中台抽取搭建
  • 企业平台迭代和思路

Java自动化测试工具汇总

xUnit frameworks 单元测试框架

TDD \ ATDD \ BDD

  • 工具
    • JBehave – Behaviour-Driven Development (BDD)测试框架. BDD是从 test-driven development (TDD) 和 acceptance-test演进而来, 让用例的编写对新手更加友好和直觉化
    • Cucumber-JVM – 纯 java的Cucumber实现,支持大部分流行的jvm语言
    • JGiven – 开发者友好且实用的BDD工具. 开发者使用纯java及流利API编写测试场景, JGiven负责生成领域专家可读的报告
    • easyb – Java平台的BDD框架. 通过使用Domain Specific Language(DSL), easyb致力于让文档可读可执行
    • robotframework – 最有名的acceptance test-driven development (ATDD)测试框架
    Spectrum – BDD-style test runner,支持Java 8. 灵感来自于Jasmine, RSpec和Cucumber.

Model-Based Testing

  • GraphWalker – Model-Based测试框架. 这个工具可以从 graphml, dot 或 json文件中读取model,然后自动创建测试用例

Code analysis and coverage 代码扫描和代码覆盖率

  • SonarQube – 管理代码质量的开源工具
  • Gradle Quality Plugin – 静态代码分析工具,支持Java和Groovy,使用 Checkstyle, PMD, FindBugs 和CodeNarc. 插件使用了统一的控制台输出并简化了开发者的工作流: 查看不规范的错误时只需要留意控制台就好,并且控制台输出的体验跟java编译错误的输入体验一致
  • Qulice – Qulice是Java项目的代码扫描和质量控制工具. 包含了最好的静态代码扫描工具和预配置选项。你不需要单独再对这些工具进行配置了。
  • JaCoCo – JaCoCo是免费的代码覆盖率统计工具,应该也是应用最广泛的覆盖率工具了。

Web UI test automation web ui自动化工具

  • libraries
    • Selenium – 浏览器自动化工具
    • SikuliX – 基于OpenCV的 GUI 测试框架, 使用图片识别技术,支持windows/linux/mac系统
  • frameworks and wrappers 框架及封装
    • Selenide – 简洁的Selenium封装,让 UI用例的编写更容易
    • Selenified – 开源的测试框架,目的是让selenium测试更加简单,提供了简单的接口去添加测试报告,错误处理以及线程安全的运行模式。可以运行在本机或云端(Grid or SauceLabs).
    • Serenity BDD (Thucydides) – 创新的开源库,让你可以更高效的编写用户验收用例, 并可以根据用例去生成项目文档及测试报告
    • htmlelements – 让web测试时元素交互更加简单的java库
    • atlassian-selenium – 让开发者可以更高效的编写Selenium/WebDriver功能测试的开源库
    • stevia – Persado出品的开源自动化测试框架
    • darcy – 开源的测试框架,支持java 8,提供了具有表意性以及使用简单的API
    • Satisfy – 基于Thucydides和Jbehave的开源测试框架。支持WebUI, SOAP, REST, emails, files,并支持创建随机数据,开箱即用
    • JDI UI Test Automation Framework – UI自动化测试框架。扩展了Page Object设计模式,并加入了一些常用的元素
    • Geb Framework – 基于groovy自动化测试框架。专为Webdriver Page Object设计模式以及Spock Framework(BDD)的集成而设计。
    • FluentLenium – FluentLenium可以帮助你写出可读性好, 可重用, 可靠且灵活的Web UI功能测试用例. FluentLenium 提供了为Selenium实现的流利api,并为selenium用户的一些常见问题提供了解决方案。
    • Selion – 基于TestNG和Selenium提供了一系列的功能,让你可以在短时间内搞定webdriver. 支持web和移动端测试
  • extensions 扩展
    • BrowserMob Proxy -从浏览器获取性能数据的简单工具, 一般跟自动化工具,比如Selenium和Watir配合使用
    • Selenium-Grid-Extras – 让Selenium Grid 节点的管理更加简单, 并通过清理测试环境的方式让节点更加稳定
    • Selenium Grid Extensions – 扩展了Selenium grid,以及可以在执行selenium用例的同时执行Sikuli用例
    • Selenium Grid Router 轻量级的server,作用是把Selenium Wedriver的请求分发到多个Selenium hub。
    • Docker Selenium Grid – 提供了native的视频录制功能,支持Selenium Grid,最初被设计为跟docker-selenium一同使用。
    • Video Recorder Java – 使用自动化测试用例来录制视频的java库
    • Zalenium – 提供一次性的灵活的Docker-based Selenium Grid视频录制功能, 支持实时预览和online/offline控制面板。
    • SikuliFactory – 为SikuliX提供了PageFactory实现。
    • Mailosaur – 邮件自动化测试工具,基于Mailosaur。

Mobile test automation 移动自动化测试

  • Appium – 开源的自动化测试框架,可以测试native/hybrid/mobile web应用。核心是基于webdriver协议进行了扩展
  • Calabash – 跨平台的自动化测试框架,支持Android和iOS的原生应用以及hybrid应用。 Calabash的语法非常容易理解,甚至可以让非技术人员编写和执行基于上述平台的自动化测试用例。
  • Robotium – 安卓自动化测试框架,支持原生及hybrid应用. Robotium让我们可以非常方便的编写强大和稳定的黑盒UI测试用例。 有了Robotium的支持, 测试开发工程师可以编写安卓应用的功能用例系统用例以及用户验收用例。
  • UIautomator – 提供了高效的测试UI的方式。 可以创建支持真机及模拟器运行的自动化测试用例,并包含了可以查看和分析安卓UI的viewer。
  • Espresso – 比较新的开源自动化测试框架, 让开发者和测试人员都可以编写UI用例。 Espresso的api简单且易学,你可以非常快的使用这个框架上手安卓自动化测试

API test automation 接口自动化测试

  • Karate-DSL – Karate是BDD风格的使用javascript实现的测试框架。可以让你调用任何web-service类型的接口并对响应进行断言。

Windows UI test automation windows ui自动化测试工具

  • SikuliX – 基于OpenCV的 GUI 测试框架, 使用图片识别技术,支持多操作系统
  • Winium.Desktop – 测试Windows应用(主要是基于WinForms和WPF平台)的自动化测试工具. 实现了Selenium Remote WebDriver协议

Unix \ Linux UI test automation Unix \ Linux ui自动化工具

  • SikuliX – 基于OpenCV的 GUI 测试框架, 使用图片识别技术,支持多操作系统

MacOS UI test automation mac ui自动化工具

  • SikuliX – 基于OpenCV的 GUI 测试框架, 使用图片识别技术,支持多操作系统

Server side test automation 服务端自动化测试工具

  • Citrus – Javas实现的测试框架,支持企业级SOA应用的e2e服务测试, 支持 HTTP, JMS, TCP/IP, FTP, SOAP协议,以及XML和JSON.