Hello 朋友们，又到了我们熟悉的社区精选栏目啦！在这里，我们致力于 pick 「飞书开发者广场」的精彩故事，期待未来也能够给你们更多惊喜方案！
今天的主角是开发者——李杰，借助飞书开放能力，他让日常工程更新完全融入了飞书，项目部署只需分分钟！
「 关于我们 」
刚进公司时，我发现不同的测试环境和 CI（Continuous Integration / 持续集成）发布平台的用法都不太一样。如果产品线比较丰富，还很有可能会同时使用多个不同的发布平台。有些发布平台的过程控制做得非常细致，需要先拉取工程打包再进行部署，整个过程都需要操作人员进行确认操作。由于我的记性不太好，常常操作完第一步就忘记第二步（因为步骤之间需要等待超过 1 分钟），过了许久才发现自己没有完成更新。
自己的智慧本来就已经捉襟见肘了，工作的时候常常被发布中断当然不能行。于是我按照自己手动的操作步骤，使用类RPA（Robotic process automation / 机器人流程自动化）技术将发布过程整合到一起，让发布可以一键完成。
现在，有了飞书开放能力的加持，一切沟通、操作及信息同步都可以在飞书中以一种非常直观的方式完成。（不谦虚的讲那就是遥遥领先）
为什么要这样做
中午 12 点，
终于到了吃饭的时候。
我高高兴兴地走到门口，
突然四哥叫住了我，
他要发布下 XXXX，
他想利用我们吃饭的时候
在测试环境验证他的一个修改
理由让人感动，
我不忍拒绝。
已经很晚了，
回家躺在沙发上，
打开手机愉快地学习着。
牧哥打来电话，
他们今天晚上要提测，
现在正在测试环境过冒烟
出了问题想更新测试环境
真是殚精竭虑，
怎么能拒绝。
工位上，
扶苏正在与我进行
激烈且深入的交流，
悟空走过来
说自己改了个线上问题，
要在测试环境验证，
你不给他更新，
他就一直站在你后面，
无法反驳。
南哥改了一波 BUG，
通知到了我，
我发给他了。
然后我发现，
被他标记为已解决的 BUG
在回归中一个都没解决
我当然不相信他
“我这里是好的”
这样的鬼话，
全部给他 ReOpen。
南哥在这个疑难杂症上
花了好多时间无果，
最后虽然发布成功了，
容器启动一直没有成功。
还有非常有责任心的同学，
从你给他点发布开始
就会不停的问你：
发布有没有成功，
新的版本里
有没有他的代码更新...
何等敬业，
当然要及时给予反馈。
具体方案
结合飞书开放能力，如何完美解决上述需求场景？
第一步，触发发布。可以在与开发同学的聊天中直接触发，也可以通过给飞书应用发送指令完成。
下面我们主要介绍通过聊天触发的场景，因为这个场景是完全融入在日常工作中的。
上面这段视频是「CI 发布终端」（应用的名称）典型的应用场景，仅仅通过聊天，就可以以极小的代价，完成整个应用更新。只需要我们一次点击（这一次点击相当于审批通过），CI 发布终端会自动且优雅地完成剩下的一切。
在对话中提取可能被发布的项目名称，及需要部署的环境参数
自动给予对方回复反馈
通过动态卡片在群里实时同步进度（关注该工程的可能不止是对话的2个人）
获取Git更新信息，并更新到动态卡片
获取新项目启动/更新进度
编译失败/启动失败/超时同步错误消息到动态卡片，并自动进入对应服务获取错误详情
通过更新记录@本次更新的相关关注者，失败的情况下加急给负责人
动态卡片同时会顺便帮我们保存所有的发布记录
以上一切都可以自动完成，不需要人工参与，CI 发布终端会代替人工监督整个发布过程，并将可能出现的关键消息通知到人。
你也可以通过图片查看整个流程的效果：
（点击图片跳转至下一步）
现在我们再看看之前需要如何完成这些操作：
当我们准备更新工程时，首先需要打开公司的 CI 平台（可能是 k8s，也可能是其他 CICD 平台），当然我们可能是提前登录好的，接着我们要找到工程对应的项目空间 —— 搜索出目标工程 —— 点击触发构建流水线，这个时候还需要分心去关注构建是否完成/成功，构建完成后还要关注容器替换/运行有没有错误。
这一波操作如果一天要重复十几次··· ···
而现在我们需要在聊天消息上选择快速发布而已，甚至你可以躺在家里的沙发上用手机完成这一切（不需要打开电脑，也不用登录公司 VPN）
当然之所以叫终端，是因为他可以以类似命令行的形式被飞书应用承载。（不过这可能不是本文的重点）
如上图所示，使用者除了可以直接在对话中触发发布，也可以在飞书应用中完成发布或其他应用管理工作。将飞书应用与 CLI（Command-Line Interface / 命令行界面）操作相结合，可以完成复杂的管理操作，不明白的命令与我们在 liunx 上的操作一样，直接「cmd -- help」 就会出现相应的帮助说明。
开发心得
飞书动态卡片
在没有使用动态卡片之前，我们只能发送简单的静态文本消息，状态更新还需要发新的消息。这样不仅导致消息分类检索麻烦，过多的消息也会对正常工作造成影响。
动态卡片完美地解决了这一点，它不仅展示优雅、显示直观，更可以让单次发布的内容聚合在一起，通过更新动态卡片还能显示实时状态。
飞书动态卡片可以完成相对复杂的展示及交互操作，但在更新卡片时，如果涉及不能预测的数据，需要注意业务数据的转译，否则会更新失败。
飞书动态卡片可以通过更新图片实现很好看的进度条的效果，如下图所示，本方案就使用了 100+ 张图片动态替换实现了很平滑的进度条效果（PS：最开始的时候这种方式实现的进度条还是稍微有点卡顿，不过经过飞书几次迭代现在已经十分平滑了）
飞书消息接收事件
飞书消息可以实时获取用户发送给应用的消息，由于我们的应用场景会针对消息进行自动化操作，所以这些消息实际上是不能重放的（不幂等）。
然而，由于飞书或我们自己的服务出现异常，消息可能会被延迟回调。在这种情况下，系统就不能直接处理这些被延迟回调的消息，比如 3 个小时前发出的发布指令，3 个小时后再收到就需要被过滤掉。
我们可以通过消息的 create_time 与当前时间对比过滤掉这类消息 （类似上图效果）
为了实现通过 commit 记录 @ 或加急指定的同学，我们需要提前获取一份组织结构成员信息，用于后面匹配获取 open_id 。
为了尽可能快速地完成对这个树形结构的遍历，我们使用了全异步递归遍历树结构。
这样做速度确实变快了，但是生产上如果组织机构规模较大，很容易（后面是一定会）触发飞书的限流，最后还需要单独处理限流异常。（这里如果需要用户信息，可以每次用到时再查询，并将已经查询过的信息缓存起来，或者一开始全部查询时就慢慢地查，避免一顿操作先提速再被迫降速，还不如不操作）
在使用动态卡片时，可能会遇到同一个卡片处于不同状态时，卡片内容及内容中的可变属性差距较大，这个时候可以根据卡片状态创建不同的卡片信息模板，这样管理及更新卡片的复杂度会降低，操作也会更加方便。
「 开发者说 」
之前我也使用过其他的 IM 工具，「CI 发布终端」也支持在这些 IM 工具上以企业应用的形式使用。
但在整体对接体验中，飞书表现更为优秀。个人感受是，其他工具和飞书的开放能力稳定性都不错，极少出现故障。不过，在开放文档及应用管理方面，飞书还是略胜一筹。
最超出预期的是飞书面向开发者的人工技术支持，只要提出疑问，都能很快得到一对一的支持与反馈。
动态卡片的数据展示能力及交互能力也都很优越，还可以直接在群里共享，能够很完美地应用于需要做信息同步的场景。结合飞书应用提供的其他开放能力，很容易创造出惊喜。
代码仓库👇：（仅供参考）
https://github.com/lulianqi/DeploymentRobotService
© 原创声明：本文内容仅代表作者观点和立场，内容版权归原作者所有，未经许可，不得转载。
福利时刻
转发本文至朋友圈并截图私信至公众号后台
48h 内我们将抽取 5 位幸运粉丝
赠送 定制主题马克杯 ✖️ 1
如果你想了解更多飞书开发的最佳实践、解决方案、代码片段、开发心得，或者想要分享建议 & 助力愿望，欢迎前往飞书开发者广场，共同探索飞书开放的无限可能。
👉 open.feishu.cn/community
点击文末阅读原文，查看该方案的更多细节，给 TA 点赞吧！
