大型电商系统开发实施管理

大型电商系统开发实施管理盈天讯张宇Agenda•精益生产的“现场”•构建与发布•集团作战•持续改进的组织精益生产的“现场”•工厂的现场是“车间”•办公室文员的现场是“办公桌”•软件开发的现场是？？•代码库！SCM•代码库必须整洁干净•源代码从SCM弄出来以后可以直接编译运行•如果不能直接运行，需提供README说明步骤•尽可能容易的让项目运行起来•存储过程要放在SCM里面吗？•80%的互联网流行项目使用SVN•越来越多的项目转向使用GIT分支和版本策略•稳定主干策略•多头策略•特性分支策略•Bug修复•主干修复策略•Bug分支策略•并行版本•需要一直为版本进行维护，直到该版本生命周期结束•在bug出现的版本上做修复，然后合并到新版本中稳定主干策略•某大型电器集团公司的B2C，B2B2C商城采用的策略此种分支策略使用主干（Trunk)作为稳定版的发布。主干上永远是稳定版本，可以随时发布。稳定主干策略的特点：（1）bug的修改和新功能的增加，全部在分支上进行。而且每个bug和新功能都有不同的开发分支，完全分离。分支上的开发和测试完毕以后才合并到主干。（2）对主干上的每一次发布都做一个标签而不是分支。多头策略•某大型自有品牌服装B2C商城采用的策略•也叫分支发布策略•主干用作开发基线•与生产对应的releasetag打在分支上特性分支•国际上普遍采用的GIT分支策略•特性分支是指，为每一个功能特性（用例或者用户故事）单独建立分支•有专门的develop开发基线•有与生产对应的master分支，tag打在该分支上•特性分支的好处是，可以灵活的挑选和组合上线的内容•需要强大的SCM的支持，推荐GIT其他考虑•长期分支•MergeorNotMergeisaquestion•Featureswitchisbetterthancodebranch•Featureswitch!!!•多次合并•有些工具支持不好，会出现大量假冲突配置管理不是一个人的事儿•项目经理，架构师，配置管理员要定制符合项目实际情况的分支及版本策略•参与项目的每一个人，都要严格遵守策略，熟练掌握使用的工具•因为•一旦有一个人出错，将会影响到整个团队•没有意义的提交注释（或者压根没有注释）将会给所有人包括你自己带来困扰•不正确的使用工具可能会造成严重后果•提交审查•PeerReview•CommitHook构建与发布——不敢发布，你怕什么？万一出事儿怎么办？我去！又要通宵加班搞发布啊！构建与发布——持续集成与自动化测试•什么是持续集成（ContinuousIntegration，简称CI）？•大白话的说，就是经常性的编译代码，打包，把各个团队开发的模块，整合在一起，看看有没有问题，然后再跑跑测试，看看有没有问题•实际上，有很多软件产品可以自动帮你做这些事情，比如Hudson。•CommitBuild&NightlyBuild•一旦有人提交代码到SCM，就触发一次编译，并自动运行单元测试•每天夜里，当所有人的代码都提交以后，自动编译并运行集成测试自动化测试•UI经常变化，而且主动权往往掌握在前端工程师手中，Ajax和不同浏览器的兼容问题会影响你测试代码的纯洁•基于Web浏览器插件的自动化点击测试，完全模拟用户操作•DomainService太灵活，测试的意义不大，很难做到真实覆盖•答案：TestAgainstYourFaçade•测试团队的测试工程师可以直接根据Façade书写测试用例•最接近UI，达到与用户几乎一致的覆盖，也就可以达到跟测试人员亲自点击测试接近的效果。•自动化自动化测试（AutomateyourAutomationTests）•API调用及应答录制和回放•使用虚拟机的Snapshot管理你的测试数据库为什么持续集成可以提高质量？•半年上线一次VS每天上线一次，哪个更容易出问题？•持续集成可以保证你的待上线分支或者主干总是能够达到“可发布状态”•自动化测试给你自信•小步快跑让问题更容易解决或者回滚，同时减少了来自业务部门的压力自动化运维•自动化分支创建•自动化发布规划•自动化部署•自动化发布管理•自动化监控与自动化响应•波浪式发布•A/BTest•Alpha、Beta小范围内测公测我去！发布都不需要我了！综合考虑构建与发布——发布流程•由CI完成自动化测试后，自动发布到SIT环境•测试团队测试完成后，一键自动发布到PRE环境进行UAT测试•PRE环境完全仿真，软件环境需要与生产完全一致，硬件环境尽量与生产一致。所以，对于开发人员来说，PRE就等于PROD•UAT验收通过后，运维人员通过自动化发布系统完成发布•自动存档•一键回滚•自动发布到所有服务器构建与发布——你还怕吗？发，天天发！敢发布吗？今天！集团作战•团队划分•API管理•构件管理团队划分•分而治之•合适的团队大小•TheTwoPizzaRule•小团队内部沟通成本低，流程成本低，容易达成共识•团队与团队==公司与公司•还记得Façadetofaçade吗？•抓大放小•定制高层流程，确保团队与团队之间的接口和流程的统一•容许自我管理的团队，容许在大框架下面拥有自由性•能够兼容异构系统的存在•你的组织能允许某个子系统使用Node.js来做吗？API管理•FaçadeAPI评审委员会•API门户与文档•API版本的生命周期•API一经发布，就会有很多用户•API的用户团队不会有专门的时间和精力配合你进行版本升级•需要至少保证一定时间的BackwardCompatibility，或保证N个版本的并行•不再支持的API需要被标记为Obsolete•发布旧API版本的RetirementDate•APITestingSandbox•保证每个版本的API都有一个对外的测试环境构件管理•使用Maven进行构件管理•使用Maven进行构件依赖管理•使用Maven统一全团队范围内的第三方库依赖•建立内部的NexusMavenRepository服务•只有CI有向Nexus发布构件的权限持续改进的组织•架构的持续改进•架构优化组•流程的持续改进•流程优化委员会•人员自身修养的持续改进•内部培训•积极参与到社区•需要有人对持续改进负责•持续的ThanksAndQ&A