【20181014】Release Manager再思考

家里有了小鱼鱼的这一个多月，真的是非常难忘的人生体验... 陪产假结束重新投入工作，我们继续对Release Manager的思考~

参见之前的总结和认识，Release Manager即是以“精益”为目标，践行“持续交付”，实现更好的软件交付质量和客户满意度。

首先在践行“持续交付”时，不免要涉及多个领域团队，此时要运用敏捷&Devops的理念将需求、开发、测试、运维等团队融合为一体，打破以前各团队各扫门前雪的孤立局面，让每个团队从需求阶段就提前介入，持续关注交付过程并对交付质量全程负责。

搭建好团队基础后，就可以逐步建立持续交付的承载实体：流水线，让交付过程变得“流动”和“可视化”。此时持续交付不再是需要N多人评审和争论的流程文档，而是清晰高效的系统工具。除了流动之外，还需要有全面的遥测监控体系和持续改进方法，来分析流动过程中哪些环节是可以提升的，让流动性变得越来越好。

在Release Manager各阶段的工作中需要运用到包括需求管理、变更管理、版本控制、持续集成、自动化测试、环境管理、持续部署、数据监控等多种软件工程的流程方法论和工具手段。其中位于最前端也是最重要的即是需求管理，建立和维护清晰合理的特性-需求结构关系能够帮助后续的研发过程有序可追溯，并且能有效帮助开发、测试、运维领域统一目标深入融合；变更管理和版本控制则是研发管理的基础手段，所有的代码、脚本、用例、环境配置、部署方案等均应该纳入版本控制范围，并通过变更管理与相对应的特性-需求一一对应起来，实现从前到后清晰的生命线；持续集成和自动化测试属于研发管理的常用手段，能够有效保障软件的日常质量水平；环境管理和持续部署对于那些涉及大规模服务器集群进行高频率部署&回滚的业务场景特别有效，但即使对于部署频率较低的业务场景也应如此；数据监控则是涵盖了研发的各个层面：应用程序性能、部署方案可行性、基础设施稳定性等等。

最后，开展整个持续交付工作的前提，是要清晰理解IT软件的商业目标，明确自身的发布策略，确保我们所做的工作在商业导向和技术导向是一致的。因为IT软件千千万种，不同行业不同类型的IT软件有自己的目标客户，也有自己的商业模式，更有自身的发布模式限制，不能一概而论。可以尝试根据软件部署到用户感知的代价大小简单划分一下， 举个例子：

服务主机端应用软件比如门户网站、在线管理系统等，用户直接通过网络流量来获取其最新的功能和信息，这种软件的商业目标要满足海量用户不间断的访问体验，而且用户感知到软件部署的代价非常小几乎为零，因此其发布模式通常要求部署频率比较高，能迅速解决用户的问题。相对应地其持续交付工作重点在于环境集群管理、持续部署和数据监控等，能够确保部署的及时性和可回滚；

客户PC端应用软件比如IDE等，用户通过一次性下载安装包安装来获取其相应功能，这种软件从部署到让用户感知的代价非常大，因此它的持续交付重点在于通过合理的架构设计实现部分功能支持在线更新从而能进行小规模持续部署等；

移动端应用软件比如芯片软件、手机软件等，通常会通过特殊机制（OTA等）来进行持续部署，并通过重启来完成用户感知，这类业务的环境配置通常难以大规模重现，因此其持续交付工作重点在于环境管理和OTA升级机制管理等。

另外在搭建持续交付流水线时，可以考虑自己组合各类开源工具或者直接购买成熟的解决方案，当前比较火热的持续交付流水线解决方案包括AWS的Code Pipeline、Azure的、Aliyun的等。后面我们会单独对这些解决方案进行分析。

总结一下，Release Manager既需要开阔的眼界和对整体策略的把控，也需要对业务场景和工具技术的掌握，更要面对不同团队的管理协调，故而“任重而道远”。