食堂里的沟通
今天和应用部署系统的产品经理和开发负责人在食堂进行了一个沟通，主要讨论了DevOps平台与应用部署系统的对接问题。
目前存在的问题主要是两个：
1）应用部署系统只支持在WEB页面上进行，不支持通过哑安装/接口的方式实现部署。
2）版本在线上部署完成以后，没有将相关的上线版本信息推送回DevOps平台。
对此，提出了两个希望：
1）实现应用系统在开发测试环境的自动化部署，为CI/CD流水线的自动化扫清最后一公里的障碍。
2）实现版本上线信息的回送，让版本从申请到上线整个生命周期都能在平台的管理下完成，从而让准确计算版本/需求的lead time成为可能。
问题1的讨论
对方表示：1) WEB部署已经很简单，只要UI上几步即可。
回应：目前是开发测试需要API/哑安装，来便利化安装过程。但随着DevOps的推进，一日多次部署（举了09年Flickr的例子）会是必然来到的过程。那个时候这个事情就是运维同学必须要解决应用通过API自动化部署的问题了。所以早解决，早在开发测试环境应用比届时被倒逼着解决要好很多。 另外，如果不能解决的话，我们可能要考虑自己干了。但是既然运维同学开发了应用部署系统，从DevOps的角度来说，我们肯定是首选统一的工具。自己干实在是迫不得已的选择。
对方又表示： 2）目前部署的方式很复杂，尤其是应用首次上线。要解决在CMDB中的配置问题。
回应： 能否把应用首次上线的配置和部署过程分开？ 在代码库中让开发人员提交该系统的上线配置？
对方表示：可以。如果能让开发提供，问题就能解决。但是还有另外一个问题，配置文件格式比较复杂，之前与DevOps小组讨论过，未对格式谁来提供/格式如何达成一致？
回应： 可否由应用部署系统导出？
对方表示：可以考虑增加这个功能。
方案1: 其实应用部署过程是一堆堆的SQL，可以通过导出SQL+配置数据，来实现自动化安装。
（对方开发负责人表示）但是有问题：该系统在设计过程中未考虑自动化安装的需求，采用了很多外键自增+1的设计，导出后再行导入可能会导不进去，数据错乱。
（对方产品经理表示）可以考虑将内部python函数调用过程通过日志输出，形成类似ansible playbook的格式，这样就可以避免SQL直接导入的问题。
于是同意就这个问题可以后续再回去评估下。
问题2的讨论
在讨论问题2时，对方提出该接口其实已经完成，但是由于另一接口（应用部署系统从DevOps平台拉取版本包并解析）时，由于我方提供的版本元数据metadata的格式不规范的问题，导致解析失败，无法保存下来，并且该问题已经和我方口头沟通，至今未解决。因为数据未保存下来，自然无法推送回去。
对方建议：
1）是否可以在接口修改时及时通知？2）请告知对方明确的需要推送的信息（目前是信息最少原则，不说的都不给）
回应：
1）可否在JIRA中报告缺陷（回去就邀请对方加入项目），便于团队沟通，以免点对点沟通造成信息的更新不及时。
2）回去就接口具体信息与团队协商，主要是ITIL中的变更号/版本信息/上线环境等。
后记
由于今/昨两天双方都没有合适的时间，最后约定在食堂里面边吃边聊了。从12点一直聊到了1点钟，食堂都没人了，我们才散。希望今天的这次边吃边聊，能推动平台的整合。
网友评论