本文和大家探讨 Qunar 机票项目管理的利器：奥丁桌面。

在 JIRA 的提测&发布栏右上角，有一个名为“奥丁桌面”的按钮，就是本文重点介绍的工具平台：

对这个奥丁桌面，Qunar 的很多同学并不陌生，也有很多业务线同学在使用它进行发布管理。它是国内机票 QA 自主研发的流程管理平台，支持发布管理、信息整合、持续集成。

使用奥丁桌面进行发布，则无需再通过 Jekins 平台发布、Git 获取工程信息、JIRA 找分支和发布人员、去环境管理平台自行发布等等各种平台的切换。奥丁做了发布系统和信息的整合、奥丁方便填写分支发布和回滚、奥丁集成了日志查看、奥丁有环境和机器绑定。

使用奥丁桌面，无需再担心回滚的分支不对，无需再担心所使用的测试环境和别人有冲突，无需再担心人员对代码检查、自动化测试等流程的执行情况。

以上是奥丁的一些主要功能，但并非全部功能，奥丁承接的和能够实现的，比上述功能还要都很多，下面来顺着笔者的思路，看看我们是否可以让奥丁更强大，让项目管理流程更智能化、标准化。

桌面管理

既然是桌面管理，首先奥丁做了发布系统、环境信息、JIRA 项目信息、代码信息、人员信息、监控信息、工具类等信息的整合。

如图所示是当前奥丁桌面能够看到的功能展示：

本文重点介绍几个有趣的、值得推广和探讨的功能。

环境信息

在奥丁背后，对接了容器化环境管理平台。当测试环境创建、销毁、更新时，会发送消息，奥丁后台的阿波罗系统监听消息，将环境完整的信息持久化入库，并提供接口，供奥丁桌面和其它工程使用。

这些信息包括：环境列表、环境中的工程信息、端口、路径、module、工程类型、环境名称和标识、应用部署基本信息等等。

同样，奥丁会获取 JIRA 中的项目信息，包含：人员信息、工程信息、分支信息、模块信息。将这些信息整合展示在奥丁桌面中。

有了上述的工程和代码分支信息以及发布信息，那么奥丁自然而然可以后台去获取该工程最新的上一次 master 代码，进行有效回滚分支号的自动填充，方便回滚操作、rebuild 操作。

奥丁能够获取到 JIRA 的所有相关人员，于是提供了“一键群聊”的功能，点击自动创建以项目名称命名的含所有项目成员的内部沟通群。提效、避免沟通遗漏。

除了这些，还整合了测试发布过程中会用到的监控平台、数据平台、mock 平台、case 平台、发布周知等等入口。支持入口随时添加修改。

聪明如你，看到奥丁桌面能够整合如此完整的信息，是否已经开始了各种设想？各种流程管理的方案呢？

在此，简单举几个在实践的、运用的很好的案例供大家参考：

容器化环境管理是面向全员的，缺少权限管理和环境分配策略。其初衷是人手一套环境，但这个在现实中很难完全落地实现。

于是，在奥丁中将环境通过标记进行区分隔离，例如 Dev 角色成员只能在 Dev 标签下操作，所选环境只能是 Dev 环境，有效做到环境按角色隔离。

同时，做环境工程占用管理。判断当前 PMO 要发布的工程信息和环境中的部署情况，如果待选环境中已有同样工程的另外分支或 PMO 占用，则该环境不可选。

当 PMO 关闭或手动解绑环境时，释放环境资源。

上面的过程中，奥丁已经实现了发布、环境分配、人员和分支状态的判断逻辑，那么，只要我们后端实现了对应工程的自动化测试，则只需要自动化给奥丁系统提供一个调度接口，奥丁就会判断该工程在提测、发布、灰度发布等等环节做自动化环境的自动部署和自动执行，并将结果反馈。

同时，可以做流程管理功能，如自动化执行不通过，则将线上发布选项置灰，不允许发布线上。

目前 Qunar 机票自动化即采用上述的奥丁流程自动强拦截控制。有效保障自动化落地程度。

Qunar 机票近期开发了全链路灰度测试方案，该方案拟在发布前，首先要求先发布灰度环境，灰度验证无误后，再发线上。通过灰度监控对比的方式，在小流量范围内提升线上问题的主动发现率。

其触发原理简单：识别灰度标记的机器，识别需要走灰度发布的工程，在该工程的关键节点触发灰度部署，后台发消息给灰度链路系统，触发监控染色。

基于容器化的环境管理思路，奥丁可以实现在分支创建后，自动调用环境接口，自动创建环境，自动检查环境可用度，主动提供全新可用的测试环境。

只是由于机票环境模板的巨大，这个功能暂未在机票团队落地。其它业务线如有需要，可以随时实现。

奥丁可以整合业务监控面板的调取、发布雷达的信息获取、集合监控自动埋点平台的使用、集成故障演练降级等平台的使用…

之所以叫做奥丁平台，源于它的无限创造力和支撑力。

奥丁是项目管理的有力支撑工具，是流程管理的最有效管控手段，是信息整合和输出的理想平台。

留一些想象空间，给有需要的你 : )

作者介绍：

王怀坤，Qunar 机票事业部 QA，多年互联网经验，秉承技术驱动的工作理念，潜心耕耘质量体系建设之路。