作者：拂晓
推荐理由
当有代码更新时，如何完成一次项目工程的部署？在之前的大部分情况下，当我们准备更新工程时，我们要打开公司的CI平台（可能是k8s，也可能是其他CICD平台）当然我们可能是提前登录好的，然后我们要找到工程对应的项目空间，然后搜索出目标工程，然后点击触发构建流水线，这个时候可能还需要分心去关注构建是否完成，构建完成后还要关注容器替换/运行有没有错误。这一波操作一天很可能要重复十几次··· ··· 而现在我们要做的只是在聊天消息上选择快速发布而已。甚至你可以躺在家里的沙发上用手机完成这一切（不需要打开电脑，也不用登录公司VPN）
一、关于我/我们
刚进公司我就发现，不同的测试环境 CI 发布平台都有着自己的性格，而如果产品线比较丰富，还很有可能并行使用多个不同的发布平台。发布平台的过程控制，有的做的非常细，需要先拉工程打包再部署，整个过程都需要操作人员确认操作，加上自己记性不太好，常常操作完第一步，就忘记第二步（因为步骤之间需要等待超过 1min），过了许久，才意识到自己并没有完成更新。
自己的智慧本来就已经捉襟见肘了，劳作的时候常常被发布中断当然也不能行，随后我按自己手动的操作步骤，把发布步过程使用类 RPA 技术做在了一起，让自己的发布可以一键完成，问题有了一定缓解。
不过后面有了飞书开放能力加持，画风就彻底变了，一切沟通与操作及信息同步，都可以在飞书群聊中以一种非常直觉的方式完成了。
二、需求分析
- 中午 12 点到了，终于到了吃饭的时候，我高高兴兴的走了门口，突然四哥叫住了我，他要发布下 XXXX，他想利用我们吃饭的时候在测试环境验证下他的一个修改，理由让人感动，我不忍拒绝。
- 已经很晚了，我们都回家躺在沙发上打开手机，愉快的学习着，牧哥打来电话，他们今天晚上要提测，现在正在测试环境过冒烟，出了问题想更新下测试环境，真的是殚精竭虑，怎么能拒绝。
- 工位上，扶苏正在与我进行激烈且深入的交流，悟空走过来说自己改了个线上问题，然后你不发他就一直站在你后面，无法反驳。
- 南哥改了一波 BUG，并通知到我，我给他发了，然后我发现被他标记已解决的 BUG 一个都没有解决掉，我当然不相信他“我这里是好好的”这样的鬼话，全部 reopen，南哥在这个疑难杂症上花了好多时间无果，最后发现虽然发布成功了，容器启动一直没有成功。
- 还有些非常有责任心的同学，从你给他点发布开始就会不停的问你发布有没有成功，新的版本里有没有他的代码更新。
三、方案与效果
下面展示如何结合飞书开放的能力完美解决需求分析中提到的那些场景。
我们既可以通过与开发同学的聊天直接触发，也可以通过给飞书应用发送指令完成。下面我们主要介绍通过聊天触发的场景，因为这个场景是完全融入在日常工作中的。
上面这段视频是「CI 发布终端」（应用的名称）典型的应用场景，我们可以看到借助飞书提供出来的开放能力，仅仅通过聊天既可以以极小的代价，完成应用更新。只需要我们一次点击，借助飞书的开放能力 CI 发布终端会自动且优雅的完成剩下的一切。
- 在对话中提取可能被发布的项目名称，及需要部署的环境，
- 自动给予对方反馈
- 通过动态卡片在群里实时同步进度（关注该工程的可能不止是对话的 2 个人）
- 获取 Git 更新信息，并更新到动态卡片
- 获取新项目启动/更新进度
- 编译失败/启动失败/超时同步错误消息到动态卡片，并@/加急到对应的代码提交者。
以上一切都是自动完成不需要人工参与，CI 发布终端会代替人工监督整个发布过程，并将可能出现的关键消息通知到人。
现在我们再看看我们之前需要如何完成这些操作，当我们准备更新工程时，我们要打开公司的CI平台（可能是k8s，也可能是其他CICD平台）当然我们可能是提前登录好的，然后我们要找到工程对应的项目空间，然后搜索出目标工程，然后点击触发构建流水线，这个时候可能还需要分心去关注构建是否完成/成功，构建完成后还要关注容器替换/运行有没有错误。这一波操作如果一天要重复十几次··· ···
而现在我们要做的只是在聊天消息上选择快速发布而已。甚至你可以躺在家里的沙发上用手机完成这一切（不需要打开电脑，也不用登录公司 VPN）
当然之所以叫终端，是因为他可以以类似命令行的形式被飞书应用承载。（不过这可能不是本文的重点）
如上图使用者除了可以直接在对话中触发发布，也可以在飞书应用中完成发布或其他应用管理工作。将飞书应用与 CLI 操作相结合，可以完成复杂的管理操作，不明白的命令与我们在 liunx 上的操作一样，直接「cmd --help」 就会出来相应帮助说明。
四、更多相关开发心得
- 飞书动态卡片：可以帮助我们实现更多可能，没有使用动态卡片前，动态消息只能发简单静态类文本消息，状态更新又需要发新的消息，消息多不仅分类检索麻烦，太多的消息会对正常工作造成影响，卡片完美解决这一点，不仅展示优雅，显示直观，更可以让单次发布聚合在一起，通过更新动态卡片还能显示实时状态。
- 飞书动态卡片可以可以完成相对复杂的展示及交互操作，不过在更新卡片时如果有不能预测的数据需要注意业务数据的转译，不然会更新失败。
- 飞书动态卡片可以通过更新图片实现很好看的进度条的效果，这里就使用了 100+张图片动态替换实现了很平滑的进度条效果（PS：最开始的时候这种方式实现的进度条还是稍微有点卡顿，不过经过飞书几次迭代现在已经十分平滑了）
250px|700px|reset
- 飞书消息接收事件：可以实时获取用户发送给应用消息，因为我们的应用场景是会针对消息进行自动化的操作的，所以这些消息其实是不能重放的（不幂等），当是可能因为飞书或我们自己的服务出现异常导致消息可能会被延迟回调，这时候是不能直接处理的，比如 3 个小时前发出的发布指令，3 个小时后再收到是需要过滤掉的。我们可以通过消息的 create_time 与当前时间对比过滤掉这类消息 （类似下图效果👇🏻）
250px|700px|reset
- 为了实现通过 commit 记录@或加急指定的同学，我们需要提前获取一份组织结构成员信息，用于后面匹配获取 open_id。
为了尽可能的快的完成对这个树形结构的遍历，使用全异步递归了树结构。不过这样快是快了，不过生产上组织机构一大很容易（后面是一定会）触发飞书的限流，最后还要单独处理限流异常。（这里如果需要用户信息，可以每次用到谁查谁，再把已经查询过的缓存起来，或者一开始全部查询的时候就慢慢的查也可以，避免花里胡哨一顿操作先提速再被迫降速还不如不操作）
因为之前还使用过一段时间的钉钉跟企业微信，「CI发布终端」也支持在这些IM工具上以企业应用的形式 C 形式使用。所以其实「CI 发布终端」是同时对接了钉钉，企业微信，飞书的，整体对接（整合应用自身能力）的体验飞书都更为优秀，个人感受开放能力的稳定性钉钉，企业微信，飞书都还是不错的，都极少出故障，不过开放文档及应用管理感觉飞书还是要好一些，最超出预期的是飞书面向开发者的人工技术支持，只要提出了疑问，都能很快给予一对一的支持与反馈。
动态卡片的数据展示能力及交互能力都很优越，还可以直接在群里共享，可以很完美的用在需要做信息同步的场景，结合应用提供的其他开放能力很容易可以创造出惊喜。
