在公司从事运维工作期间，发现了一些更新上线项目发布的问题：

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的方便快捷

新建分支以及合并分支的便利性，会造成一些问题，分支不自然的就会过多

所以需要定时的需要删除一些过时的分支

项目分支

一般来说，互联网项目有上线分支，预上线分支，测试分支，开发分支等

保证不同的分支做不同的事情，防止分支污染

1. 上线分支，是发布到线上的分支，以这个分支为准，其他分支都是以这个分支为基础拉取。

2. 预上线分支，在预上线环境当中，防止出错的最后一道保证。

3. 测试分支，可能测试环境大家共用一套，所以把代码都merge到这里，然后发布

   这样大家各自测试自己的，互不打扰。如有多个测试环境，直接使用开发分支测试也是可以的

4. 开发分支，从上线分支拉取，根据需求修改的新分支。

开发流程

上面的这张图看起来有一点复杂。总体上来，可以分为这么几步

1. 第一步，需求来了之后，从上线分支拉取一个开发分支。

2. 第二步，在开发分支进行开发，自测。

3. 第三步，合并到测试分支，通知QA测试。

4. 第四步，如果通过测试，合并到预上线分支，然后继续测试。如果不通过测试，进入第二步。

5. 第五步，如果预上线测试通过，将预上线分支合并到上线分支。如果不通过测试，进入第二步。

6. 第六步，上线，然后线上测试。如果通过测试，那么这个需求开发就结束了

                   如果没有通过测试，就撤回上线，然后进入第二步

分支规范

1. 测试分支以及预上线分支要定时清理，和上线分支同步

2. 上线分支以及预上线分支，merge权限保证在少数人手里

   merge的时候，需要检查提交以及对线上的影响

3. 只能在开发分支修改代码，其他分支都是等着被merge

4. 提交之前，需要保证和上线分支没有冲突

5. 防止分支被污染，特别是受到测试分支污染

流程规范之外

    人是最难管理的，以及人是懒惰的

    这些话是非常准确的，所以会遇到一下问题，还得需要解决

1. 需求改动非常小，是不是还得走整体流程。

2. 我只是修改文案，是不是还得走整体流程。

    具体怎么做，每一个公司和组都有自己的做法，是不是都必须都得走一遍流程

    但是，分支规范是必须的，不能随意修改。直接在上线分支修改，坚决说NO!

普及一下中小企业项目上线的一般流程