Thoughts, stories and ideas.

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

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

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

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

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

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

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

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

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

defclass 的自我介绍

大家好,我是 defclass,目前是熊组的一名后端开发,以捉别人的 BUG 和卖自己的 BUG 为生。读书时代略内向,现在也有一点,偶尔逗逼,总的来说是一个经常假装不正经的但其实很正经的一个人。

大学学的制药工程,毕业后短暂在药企待过,主要是配制药品。总有一些好奇宝宝问我是不是配制过枸橼酸西地那非片(我知道好多好奇宝宝会自己去查这个学名),虽然厂里产这种小药丸,其实我并没有配这个药。我是正经人,配的是正经药——一种抗肿瘤的注射剂,目标人群是癌症病人。这个药比较贵的,医院打一针要 1.5K。有病没病都可以续 1s 的哦,要不要来一针?

读书的时候花了很多的时间折腾 Linux、Emacs 啥的(是的,并没有什么 X 用),在药企心心念地还是想写代码(教练, 我想写代码……),后面索性就转行了。从此一入 IT 深似海,从此(头|妹)(发|子)是路人, 一转眼竟 5、6 年了。看到这里,请不要误会我是一只单身狗。其实我已经结婚多年而且是一位爸爸(严肃脸)。看着熊组同学们都辣么年轻,不服老不行了,哎。

当然,如果有集美貌与智(财)慧(富)于一身的优质妹子觉得错过我了,也不用过于遗憾,我可以免费给你们介绍介绍我们熊组才华横竖都溢,唯独堆栈不溢,外号一枝梨花压海棠江湖人称老司机的@hbc 同学认识认识,钱多活好不解释。哎呀,波波的脑袋就不用凑过来了,你没有机会啦,再过来给你夫人打小报告了。好了,老板,自我介绍写完了,可以发了工资了吗?谢谢各位阅读,如有不适,请说服我们老板不扣工资,我马上删掉……

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

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

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

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

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

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

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

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

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

期待大家的声音 XD

什么?RSS 机器人还能做这些事情?

虽然在短短几十年的互联网时代里 RSS 已经是一个相对古老的技术,但是它至今也仍在然起着很多不可替代的作用。利用RSS 我们可以避免耗费精力的主动查询,让网络世界更加自动化,而且相对于微信公众号等封闭的内容订阅平台,RSS 是完全开放的,生态圈更加丰富和多样。

倍洽(BearyChat)支持 RSS 机器人 已经有 两年 了,使用它可以很方便的把一些好的内容来源,自动给自己或者给团队同事分享阅读。

然而利用 RSS 机器人,是不是只能获取有 RSS 支持的内容呢?其实答案是否定的,因为还有很多工具可以帮助你把想要的内容 RSS 化,让机器人可以识别,我们来看看下面几个场景:

我想跟踪社交媒体,看看对于自己的产品,用户们是怎么说的?

有一个叫 Queryfeed 的工具,可以支持把多种社交网站(Twitter Facebook Google+ Instagram 等)的内容转化为 RSS 源。

我们以 Twitter 举例,用它来生成关于游戏「纪念碑谷」的 RSS 源。

  1. 先用 Queryfeed,填入「纪念碑谷」生成 Twitter search 的 RSS 源。
  2. 把生成的 RSS 源,地址复制出来。
  3. 建立一个 RSS 机器人,在「订阅地址」里填入刚刚复制的 RSS 源地址。
  4. 设置完成,你立即会收到用户最近和 「纪念碑谷」有关的 Tweet。

怎么样是不是很容易?只需简单几步,就不会轻易错过用户的声音了,我们再看下一个应用场景。

我的软件使用了一些关键的第三方库,我想及时知道他的更新要怎么办?

Libraries.io 是一个开源软件的索引服务,支持众多主流开源软件仓库。

我们这里要监控一下 hubot-bearychat (BearyChat 的 Hubot adapter)这个包在 NPM 上有没有新更新。

  1. 在 Libraries.io 里搜索 「hubot-bearychat」
  2. 进入详情页,在侧栏就可以看到 releases 的 RSS 源,如下图:
  3. 同样复制地址,建立机器人。
  4. 设置完成,你立即会收到最新的版本号推送。

通过这个机器人,我们就可以及时知道,我们使用的库是不是又修复了什么 BUG,有没有新功能可以用上。(GitHub Repo 也支持 releases 的 RSS 输出,也是另一种跟踪方式)

当然,上面的两个例子都是一个特定场景,社交网站和开源软件,那么......

如果我想对任意的页面进行监控呢?

现实是没有那么美好,大部分的互联网页面是都不支持 RSS 输出的,但是这也不是没有办法,再介绍两个终极武器:将任意页面转为 RSS 源的工具 FeedityFeed43

我们以抓知乎的搜索结果为例子,把知乎「搜索 AlphaGo」的地址 https://www.zhihu.com/search?type=content&q=AlphaGo 复制到其中一个工具里。

其中 Feedity 支持你鼠标圈选你关心的内容,并可以把同一类内容(比如标题)一起选择抓取,从任意页面选择你所需要关心的内容,不过 Feedity 是收费服务,最基础的套餐是 9 美元一个月,如下图:

而 Feed43 使用起来难度比较大,需要你有一些 HTML 基础,自己去写规则来匹配出你想要的内容,把需要的内容通过一些语法筛选出来,但是优势是有免费的套餐。

这两个工具,都可以先试用,测试生成你想要的 RSS 源。这样绝大部分页面都可以通过各种各样的工具 RSS 化了。

好了,介绍的这些工具不知道对你有没有启发,如果有就动起手来,让 RSS 机器人发挥它最大的价值吧~

在 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