在公司从事运维工作期间，发现了一些更新上线项目发布的问题：
1，程序中写有大量的接口调用使用的是ip地址。
2，程序中的垃圾代码很多，用我的话说程序不干净，很明显是因为交接造成的。
3，生产环境更新的备份文件压缩文件到处乱放
tomcat等的日志有分割但是没有定期清理，高达上G。配置文件 写的一沓混乱。
4，运维人员离职居然没有交接文档，更没有生产环境的维护文档。
更甚的是我这个倒霉蛋居然来了都没人给个口头交接，只是口头仅此而已，没有。
5，更新上线没有提前通知规定，没正式流程
都要过年了居然还同意上线，稳定性意识不够，估计还是因为没人看吧
6，上线进行时，开发人员围着运维同志乱转乱叫，完全没秩序
更倒霉的是上线人员提前也不知道都上什么不上什么
我的建议：
1，杜绝ip地址在程序中出现，没有域名的用写hosts代替，需要特别标明。
2，清理程序中的垃圾代码，保证程序的整洁。
3，清理生产环境，统一规范安装路径备份路径，定时压缩清理无用的日志。
4，完善文档制度，补充生产环境配置部署文档。
5，完善更新流程，统一更新上线时间安排，及上线做好提前通知，标明上线修复的bug，及更新内容
采用邮件形式。大更新提前1周，小更新提前1-2天。合理安排测试结束时间，建议上线最迟半日完成测试
6，灵活安排上线项目的具体次序，程序开发不得影响运维人员，有什么特殊需求提前说明。
下面说说公司常见的项目上线工具Git的详细使用过程
Git 代码管理
很多互联网公司都开始使用Git，替换了svn。Git非常适合互联网迭代以及多人多版本开发
如果让我说为什么喜欢使用Git，我喜欢切换分支，以及分支之间merge的方便快捷
新建分支以及合并分支的便利性，会造成一些问题，分支不自然的就会过多
所以需要定时的需要删除一些过时的分支
项目分支
一般来说，互联网项目有上线分支，预上线分支，测试分支，开发分支等
保证不同的分支做不同的事情，防止分支污染
-
上线分支，是发布到线上的分支，以这个分支为准，其他分支都是以这个分支为基础拉取。
-
预上线分支，在预上线环境当中，防止出错的最后一道保证。
-
测试分支，可能测试环境大家共用一套，所以把代码都merge到这里，然后发布
这样大家各自测试自己的，互不打扰。如有多个测试环境，直接使用开发分支测试也是可以的
-
开发分支，从上线分支拉取，根据需求修改的新分支。
开发流程
上面的这张图看起来有一点复杂。总体上来，可以分为这么几步
-
第一步，需求来了之后，从上线分支拉取一个开发分支。
-
第二步，在开发分支进行开发，自测。
-
第三步，合并到测试分支，通知QA测试。
-
第四步，如果通过测试，合并到预上线分支，然后继续测试。如果不通过测试，进入第二步。
-
第五步，如果预上线测试通过，将预上线分支合并到上线分支。如果不通过测试，进入第二步。
-
第六步，上线，然后线上测试。如果通过测试，那么这个需求开发就结束了
如果没有通过测试，就撤回上线，然后进入第二步
分支规范
-
测试分支以及预上线分支要定时清理，和上线分支同步
-
上线分支以及预上线分支，merge权限保证在少数人手里
merge的时候，需要检查提交以及对线上的影响
-
只能在开发分支修改代码，其他分支都是等着被merge
-
提交之前，需要保证和上线分支没有冲突
-
防止分支被污染，特别是受到测试分支污染
流程规范之外
人是最难管理的，以及人是懒惰的
这些话是非常准确的，所以会遇到一下问题，还得需要解决
-
需求改动非常小，是不是还得走整体流程。
-
我只是修改文案，是不是还得走整体流程。
具体怎么做，每一个公司和组都有自己的做法，是不是都必须都得走一遍流程
但是，分支规范是必须的，不能随意修改。直接在上线分支修改，坚决说NO!