其他
Bytebase 0.1.0 开源版发布
Bytebase是什么
为什么要做Bytebase
长期耕耘这块的工具产品,目前的业界标杆,比如Flyway,Liquibase。许多团队也都使用他们的开源版本,他们的优势是长期积累,已经经过了时间的考验,在schema change core这层很扎实。但相应的劣势则是因为都是10多年的老产品了,所使用的技术栈都比较老。比如Flyway, Liquibase都是基于Java的,像数据库变更通常会作为CI场景中的一步,这一步现在往往会放在单独的容器里操作,为了跑一下Flyway的一条命令,还要先下载个JVM,或者用带JVM的镜像。再比如说他们在Web端都比较弱,要么完全没有,要么是非常基础的功能,远远达不到应对现在协同研发,持续集成的场景。当然还有一个问题,就是他们是什么都支持,数据库商业的和开源的,格式XML, SQL的都支持,经年累月,积累了不少技术债。 团队内部自研,通常当研发团队规模到了50人左右时,就必须组建DBA团队, 再更具规模的公司DBA和研发的比例是1:150 ~ 1:400。为了提高DBA的接客能力,就不得不依赖工具,从最基本的SQL工单开始,往往一开始DBA们就会自己攒个工具,比如拿起熟练的Python + Django,再高级点的用AntD美化一下。这些工具往往是随着需求一点点搭起来的,先是工单,再来个巡检,加个监控,做个备份,接个审批流这样,最后就做成了经典的公司内部系统,就像这样:
有一些更有心的同学,会把公司内部做的工具开源出去,有几个其实在社区是蛮受欢迎的,小几千的GitHub Star。我也了解到国内也有体量不小的公司在用这样的开源产品,这个价值还是很大的,至少DBA们不用重复造轮子了,还是造他们不擅长的轮子。但是坦率来讲,这些开源方案的产品化程度仍然远远不够,是很难成为业界的标杆方案。
Bytebase是如何构建的
业务建模
界面设计和交互
Issue详情页
页面URL中slug的设计
add-createdat-column-to-userpostcomment-table-for-dev-environment,这个是issue的名字 13008: 这个是issue的ID,其实是真正识别issue的关键
?stage=dev-1:这个是用url query parameter,来定位到具体的stage,一个issue上能包含不同的stage,不同的stage展示的内容也会不同。 #activity14029: 这个是用anchor定位到具体的评论位置。
开发者体验
后端选用Golang,Golang静态执行文件自包含,所以不需要像Java那样,还要先装一个JVM 利用Go 1.16之后引入的embedding功能把前端文件打包
采用了SQLite而不是一般会采用的MySQL, PostgreSQL(这个之后也会单独讲一篇)
./bytebase
就能把整个前后端Bytebase都跑起来了,其实也用不了10秒,基本是1秒内启动完的。花式Banner