第一次做项目发布员的一些总结

在以前做钱掌柜的时候就想着做项目发布员，因为做这项工作可以帮助你对整个项目实际运转情况摸得更清楚，但后来还是放弃了，主要是感觉自己比较毛糙，不太适合做这项风险较高的工作。可这次计费中心项目让我没有退路，只有自己可以顶上去。

计费中心是个新项目，发布环境和生产环境都为0，难点就在于需要从头开始搭建基础设施。这个项目构建用的是maven而不是以前阿里自制的antx，所以项目结构和构建脚本与以前项目都不太一样。但对于我这个项目发布新手来说，又恰恰是较为有利的一面，可以让我没有任何历史包袱，可以完全遵循自己的设计，发布过程中出现了问题自己处理起来更游刃有余一些。下面总结一下整个发布过程中的沉淀。
项目发布流程图

各种环境的功能和职责：

• Build机
  主要是三个功能：1）svn up各环境需发布的代码，并用maven打成可部署的ear包。2）把各环境的ear包分发到相应的预发机上。3）控制各预发机，比如重启各预发机的服务器。
  因此Build机需要一个能完成以上功能的脚本，脚本的操作面板如下所示：
  
• 发布及预发机
  此项目把发布机和预发机合成一块，也是说此环境肩负预发环境和分发项目到正式环境的职责。因此主要有三个功能：1）预发运行环境。2）把ear包分发到相应的正式机上。3）控制各正式机，比如重启各正式机的服务器。脚本的操作面板如下所示：
  
  实际上此脚本和Build机上脚本的功能非常类似，主要不同点是此环境不需要构建ear包的功能，另外还担负着预发验证的职责，因此是个可部署和运行环境。
• 正式机
  供实际用户使用的运行环境。除本身服务器环境的控制脚本，不需要其他额外的操作脚本，也不需要控制其他环境，因此无特殊需求不需要直接在此环境中进行操作。

经验总结：

• 用健壮的脚本代替实际命令的操作
  发布过程中用到的脚本都非常简单，无非是把需要用到的命令集合起来，但效果却非同一般，因为敲击这些命令也费不了多大的事，但在正式发布过程中还是有一定的风险，并且发布过程绝非一帆风顺，往往需要重复多次发布，也往往会通宵战斗。通过简单的选择操作绝对比敲击命令来得稳当和高效。因此，一定要把可以预见的操作转变为可执行的脚本，哪怕是很简单的操作。
• 把发布过程中需要的信息集合到一起，便于查阅
  发布过程中需要很多信息，比如登录密码、验证服务是否启动的命令、查阅生产库的sql、各环境的域名和IP等等，一定得把这些信息聚集在一块，避免发布过程中四处查找
• 保证测试环境和正式环境一致性
  这次预发到凌晨2点的一个重要原因就是系统间接口调用不顺畅，虽然最终具体原因还不清晰，但可以肯定是由于测试环境和正式环境不一致导致在测试阶段没发现此问题，增加了正式发布的风险。因此，一定得严格核实环境差异，特别是基础环境，这次就是由于apche配置和跨机房的差异。
• 需熟识底层技术和项目关联的各种细节
  这次发布遇到的一个主要问题就是系统间接口调用不顺畅，但和项目本身的开发代码没有任何关系，是底层环境导致。最后还是通过抓包和分析TCP/IP三次握手才定位出问题是apache的keepAlive参数需改成off，需要技术细节我就再详述，但可见处理问题的人需要对底层技术和协议有足够的熟悉，不然无从下手，也暴露出问题是搭建环境的人（就是我自己）没有对底层环境的各参数了解清楚
• 发布是个通力合作的工作，需要和依赖方提前沟通好
  发布是一个需要发布员、开发人员、测试、PD、SA和DBA一起合作完成的工作，一定要保证各环节的依赖方就位，不能就位的要找好backup

总体说来，第一次发布还算成功，但也暴露出一些问题，当然这些问题也是自己需要提高的方向。