Thoughts, stories and ideas.

GitHub 机器人分支过滤功能上线两周后

两年以来,GitHub 机器人一直是倍洽上最受欢迎的机器人,几乎没有之一。

不过过去我们也收到了一些使用反馈(多提反馈真的有用),在日常工作中,如果团队 GitHub 体量较为庞大且操作频繁,GitHub 机器人的实时推送则可能会对使用者带来一些困扰——更多是指频繁的推送提醒会造成一些打扰。

我们试图在「不错过任何重要消息」与「使用更便捷」上取得平衡,以使信息的送达能够更加高效。此前,我们为 GitHub 机器人上线了分支过滤功能,使用者们可以为自己的 GitHub 机器人设置关注分支,这之后,只有设置为关注的分支才会即时同步提醒推送。运转两周以来,我们自觉体验的确变得更好了一些。

启用 GitHub 机器人后,可以在「授权模式」页面对当前机器人进行配置。目前,一个 GitHub 机器人支持关注多个分支,在编辑框中,各个分支名称之间需要以空格进行分隔。

此外,配置 GitHub 机器人还需关注以下提示:

  • 如未设置关注分支,则默认对整体进行提醒;
  • 如果设置为关注的分支不存在,也将被系统认定为已设置分支过滤。即:如关注且仅关注了一个不存在分支,则不会收到任何推送消息;如关注了多个分支且当中部分分支不存在,则将收到存在分支产生的消息推送。

在分支过滤功能上线前已成功启用的 GitHub 机器人,可以在机器人管理列表中找到相应机器人,进入授权模式页面进行补充配置。

希望这个功能也会对你有用 :)

一个活动 | 商业化运作一周年之后,倍洽都发生了什么改变?

我们又又又一次的回顾起了过去:

从 2014 年写下的第一行代码,到 2015 年的正式开放注册,再到 2016 年 6 月 15 日,倍洽(BearyChat)高级版正式上线。累计到今天,倍洽共完成了 970 次上线,增加了 596 个新功能,修复了 326 个具体问题,每一天都在努力更优于昨天。

在过去的这一年里,倍洽最为显著的改变是对界面的整体更新。我们取消了旧版倍洽界面上的右边栏并将功能梳理合并入两级左边栏,力求使页面操作逻辑一致,层级更为分明。在优化视觉呈现和交互结构的思路之下,我们为原有的联系人列表增加了树形结构的组织架构模块,希望为大型企业及不断成长扩大的用户团队提供一种更有条理性的团队结构梳理方式。难以避免的是,因为页面结构变动的限制,在未来,一些新增的功能可能无法在旧版倍洽上使用,建议大家尽量切换和使用新版倍洽。

而同时一个潜移默化,我们期望能够平滑过渡的变化是,倍洽在过去的这段日子里确认了一个崭新且统一的品牌形象。包括特定的字体、配色、一对萌萌的吉祥物、和一个终于下定决定推广使用的中文名字:对的敏感如你也许已经发现我们逐渐将产品描述为「倍洽」了。这个名字或许难以避免的有着「英译中」的种种尴尬和不尽如人意之处,但是也许能大大降低拼写错误的概率……吧,暂时我们是这么乐观的想着的 :)

去年的今天我们有很多期待又有些忐忑的上线了倍洽高级版与企业版(私有部署版),开启了倍洽的商业化探索,一整年运营下来由衷的感慨是:感谢的话要多讲。

感谢所有人和我们一起经历倍洽商业化从 0 到 1 的过程,让我们能面向自己交付一份还不算糟糕的答卷,大家的包容、鼓励、支持甚至吐槽都是让倍洽变成今天的倍洽的动力。明天倍洽还有从 1 到 100 的山要攀登,也希望明年的今天还能在这里跟大家一起再「又又又又」的回顾起过去,期许那时候的倍洽会更加茁壮,功能更加「包你满意」,性能更加「稳如泰山」。

于是我们也准备了一个小小的福利活动,点击 链接 填写简单资料,6 月 26 日/7 月 10 日将分别送出一些倍洽吉祥物黑白熊抱枕(部分安卓用户如无法打开连接,可使用 PC 打开链接或至倍洽官方微信 bearyinnovative/一熊科技 后台留言):

  • 「称呼」一栏将用作抽奖定位标识,抽奖当日我们将把收集到的所有称呼作为抽奖码导入倍洽抽奖机器人后台,并在 大本营团队 中抽取最终获奖名单,欢迎点击链接加入团队监督抽奖流程;
  • 「邮箱」将作为唯一的联系方式,在名单抽取后我们将按照每一称呼对应的邮箱与中奖的小伙伴取得联系,沟通黑白熊抱枕的寄送事宜;
  • 最后,欢迎在「补充信息」字段中填写对倍洽的使用反馈、功能建议、赞或者吐槽。

期待大家的声音 XD

在 BearyChat 写代码是一种什么样的体验?

本文作者@hbc

  • 代号 xx,江湖人称老司机
  • 倍洽(BearyChat)后端工程师
  • 不爱吃福建人

本文起因于一个关于「创业公司技术选型」的提问。在大约两年前,熊小队 CTO 唐晓敏同学的 一个专访 里我们曾提及过这个问题,两年后再回顾,hbc 同学也从另外的视角为熊小队再次补充了答案 :P

工程部门概括,or: BearyChat 码仔的搬砖日常

BearyChat 工程部门可以按照不同方法来划分(当然人还是那么多的人)。
传统方法就是按照不同的职责来区分:

  • 前端天团
  • iOS/Android 客户端天团
  • 后端天团

顾名思义,不同天团的同事会负责对应方向的工作。例如我大部分时间都是作为后端天团的代码仔来上(搬)班(砖)的,所以主要会关注后端开发的事宜(下面也会介绍一下我们的后端架构的情况)。

但又因为目前的 BearyChat 技术团队还不算十分庞大,所以不一定会强制各位工程师只能做某个方向的事情。所以还可以按照以下方式划分:

  • 公有云 SaaS 开发天团
  • 私有部署开发天团
  • 基础架构天团

也就是说,在 BearyChat 做码仔,很大程度上都要身兼多个方向的研发任务(我们有萌系前端工程师速成 Clojure 的「奇迹」,也有后端工程师轮番上阵用 Angular/React 写搜索输入框的惨痛故事)

因为 BearyChat 产品功能比较多,所以日常开发任务都会按照功能模块来划分、以小组方式来组织开发(当然会带上稀缺资源设计师 XD)。典型的日常会是如下:

  1. BearyChat 的研发在与一生的敌人产品锦鲤讨论新功能的产品需求(包括用户故事、功能设定、边界条件等杂七杂八的东西)后会产出一份基本的产品文档;
  2. 工程师会在一生的敌人的帮助下根据产品文档把任务分拆到自己喜欢的整理工具中去;
  3. (前后端)工程师、设计师会根据拆分好的需求尽可能地并行做开发、设计的事情;
  4. 工程师在领取一个任务之后,会通过 GitHub Pull Request Flow 的形式来提交自己的实现给相关同事进行 review (原则上不少于两个), 同时 pull request 会有专门的 CI 流程进行测试;
  5. Review 同事在 CI 测试通过后会进行 code review, 这部分主要就是在 tracker/BearyChat 上吵架了 :P
  6. Code review 完成后,最后一位 review 的同事会 merge 代码到主干,并把相关任务标记为已完成;
  7. 代码自动部署到 stage 环境,相关同事会在 stage 环境上进行集成的测试;
  8. 每周二、周四对主干代码进行 release, 上线

Take away:

通常一个简单的需求从确认到开发再到上线周期一般在半个星期到一个星期左右。这套流程的基本概念从 BearyChat 创建伊始就开始使用,改动不大,主要有几个重点:

  1. 坚持 code review: code review 能帮助工程师找到很多盲点,盲点可以是代码上的,也可以是产品上的。同时 review 的过程也有利于不同的同事熟悉整个业务。
  2. 完整的 CI/CD 发布流程非常重要:因为 BearyChat 本身是一个涉及多个大功能模块的复杂系统,所以单独的测试不一定能把所有问题都暴露出来,因此一个完整的持续集成流程和测试环境能帮助工程师尽可能快地看到功能在完整环境上的运行效果,大大缩短了问题发现、重现周期。

后端架构

TL;DR:

  • Clojure + Erlang
  • MySQL + Redis + RabbitMQ + Elasticsearch
  • Thrift + HTTP
  • Ansible + Docker + Jenkins

最初的架构设计

最初的架构设计可以参考 CTO 唐晓敏在15 年一次访谈 创业公司的技术选型 中提到的草图:

这套架构的特点就是:简单 + 可扩展。

目前的架构设计

BearyChat 后端可以划分成几个部分:

  • 核心数据储存
  • API 服务
  • 即时通信 RTM 服务
  • 私有部署服务

核心数据储存主要使用了 MySQL / Redis / Elasticsearch / products / elasticsearch . MySQL 储存了大部分业务数据(最大的消息数据表已经接近过亿条记录,所以不久之前我们也对该表进行了一次横向切分迁移,下次再给大家介绍相关细节)。 Redis 作为万金油既保存了部分非结构化的业务数据,也作为缓存用途保存了使用中产生的临时数据。 Elasticsearch 则索引了 BearyChat 的消息、文件等可搜索的实体。

Take away:

核心数据部分,BearyChat 采用了成熟的开源技术,好处就是大部分坑都被人踩过填过了,工程师不需要浪费太多时间就能得到很好的成效。

API 服务和即时通信 RTM 服务可以放到一起讲。这两个模块一「静」一「动」。

API 模块是没有状态的服务,对外通过 HTTP 协议暴露接口。API 服务主要用了 Clojure 来实现,跑在 JVM + Ubuntu 上。

RTM 模块则是一个大型的连接状态机,所以用了 Erlang 来实现,同时也是部署在 Ubuntu 上。对外可以通过 WebSocket / TCP 进行连接。

动静两个大模块之间使用了两种方式来进行跨服务通讯:

  • RPC (Thrift):服务间通过 RPC 调用来获取状态、信息
  • RabbitMQ:目前主要作为任务队列来使用,会把用户消息处理、搜索索引、推送等异步任务放到这上面来进行消费

Take away:

这两个模块从最开始设计就坚持以下要求:

  • 横向扩展(x 轴)要方便:API 服务无状态自然是简单的。而 RTM 服务因为采用了 Erlang, 所以在进行横向切分的时候也非常简单。
  • 纵向扩展(y 轴)要灵活:除了可以很方面加大机器性能来提升以外,还要在模块内尽可能地应用服务状态监控(目前使用了 ELK + Grafana stack. zipkin 等一大波 opentrace 工具正在路上)和进行业务解耦(API 模块正在做从 monolithic app 迁移成 micro service 的相关重构)。
  • 业务扩展(z 轴)要无痛:目前 BearyChat 产品是围绕团队这个概念来进行设计的,所以根据团队切分(公有云)、迁移到私有部署成本都会非常低。

私有部署服务主要用于 BearyChat 的私有部署实现、发布、交付。BearyChat 的 私有部署 版本和公有云版本产品功能基本相似,但会有其他针对大型组织体系实现的功能。同时因为私有部署环境不完全属于工程师可以直接控制的范围,所以目前搭配使用了以下技术:

  • Docker: 私有部署实例会通过 docker 镜像发布,同一个 docker 镜像可以单独作为完整服务启动,也支持作为集群服务的节点启动;
  • Ansible + Packer: 因为 dockerfile / docker composefile 本身表达语义和操作存在很大的局限性,所以私有部署镜像使用了 ansible 作为 provision 脚本、packer 作为 repreduceable/identical 镜像的构建器;
  • Jenkins: 目前私有部署的打包发布会涉及 BearyChat 所有模块,因此镜像的打包会通过若干个 Jenkins pipeline task 来完成串联、自动化。

Take away:

  1. docker 不保证兼容是 feature 不是 bug
  2. 构建复杂的工程需要关注变与不变的地方,通过把不变抽离出来能减少很多重复的步骤。在私有部署中,变的主要是核心模块的代码,不变(相对来说)的则是核心模块的底层依赖

展望

除了要为更多的用户提供更加高效的工作方法,BearyChat 的工程师也在以下几个领域不断推进:

  • 更加快速的产品迭代、交付
  • 微服务化 & GraphQL
  • 更加开放的机器人集成生态环境(机器人市场 & OpenAPI
  • 适应更加多组织企业的私有部署版本

在这个很详细的回答下面,我们也打个小广告:假如你认同 BearyChat 对高效工作的理念,也有兴趣做一些不那么 SoLoMo 但依旧很酷的东西,点击左下角「阅读原文」,熊小队正在寻找 Android 研发等小伙伴,欢迎随时跟我们联系 :P

BearyChat 走进深大 | 当我们聊起后端开发时可以简单的聊起什么

熊仔们谋划了很久的校园行,终于从深圳大学开始出发。

感谢深圳大学于仕琪老师的支持帮助和计算机与软件学院同学们的热情,「一熊科技·倍洽」第一次走进校园计划在上周五圆满达成,当熊仔和同学们聊起远方和诗的时候,也顺便聊了聊后端开发 XD

一生的敌人(PM)说: 怎么实现我不管,明天就要上线。

熊组的后端工程师和产品经理为这一次分享准备了两个小议题,在《后端开发,从入门到__》中,主要针对产品的核心架构分享了一点点小小的心得和经验,并举了一个与深大同学们息息相关的案例,说明在产品经理不同需求下架构的改变:

  • 能看,能发,能删,能用就行!
  • 总是需要刷新太麻烦了,要实时!!
  • 怎么才 100w 用户就这么卡,改!!!
  • 怎么才 1000w 用户就这么卡,再改!!!!
  • 纽约的用户说他们打开太慢了,继续改!!!!!
  • 迭代的速度要更快,我们要有 bug 监控!!!!!!
  • ……,……,……,……,……,……,……!!!!!!!

好的大王,没问题大王(:зゝ∠)

从议题一延伸开来,针对某一个具体的方面,熊仔还与现场的同学们分享了《TCP 长连接的应用》,包括保活、重连、消息协议、特殊优化等基础方面。

感谢分享过程当中同学们的热情提问,大家探索的宽度和深度让交流有了更切实的意义。也欢迎更多的同学加入我们的 线上活动大本营 继续交流,互相启发。

此外,在这次分享课上,熊组也通过倍洽活动团队与同学们进行了一个小小的互动,我们准备了一些黑白熊周边作为我们小小的心意。

期望将来能与深圳大学的同学们继续交流更多有趣又有意义的话题。也期待能与更多院校的同学们一起探讨更多不一样的内容。

(每当现场有同学关注我们的官方微信公众账号,活动团队内的公众号机器人则自动提醒有新关注,并实时计算出当前活动的中奖概率)

超级管理员,及如何自助转移超级管理员权限

一直以来,团队创建者在相应倍洽(BearyChat)团队中拥有包括任命团队管理员在内的最高权限,在权限范围序列中,倍洽始终保持着「创建者>管理员>成员>访客」的权限结构。为了理解逻辑上的统一,近日我们将「团队创建者」重命名为「超级管理员」。在成员列表等处的展示中,你可能已经发现了相应称谓的改变。

以上修改使得下文将要说明的「自助转移权限」功能更加顺理成章。

在日常的使用中,有部分团队可能遇到了这样的问题:企业选用倍洽作为日常沟通和信息处理中心,但倍洽团队的创建者并不是企业实际的管理者,在倍洽的使用进入正轨之后,就会出现把最高权限——即过去的「创建者」,如今的「超级管理员」权限——转交给企业实际管理者的需求。

在过去,团队最高权限的转移需要经过一系列的邮件申请及人工反复确认才能完成,流程较为复杂,耗时也相对较长。在本周,我们也上线了自助转移超级管理员权限的功能。

在团队管理面板中的团队信息页面下,团队超级管理员将能看到一个「转交权限」的入口。转移超级管理员权限需完成以下步骤:

  • 验证当前超级管理员登录密码
  • 在下拉列表中选中某一团队成员作为超级管理员权限接收者
  • 当前超级管理员与权限接收者分别完成手机验证

一些小提示:

  • 转移超级管理员权限需转移双方都绑定手机号后才能完成,如何绑定手机号可查阅 这里
  • 超级管理员权限转移后,原超级管理员将保留普通管理员权限
  • 超级管理员权限的转移一旦完成操作则无法撤销,请谨慎进行