更新上线项目发布的问题：
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
-
提交之前，需要保证和上线分支没有冲突
-
防止分支被污染，特别是受到测试分支污染
问题1：
产品部门与市场、营运部门信息对接存在不足 市场、营运、产品、研发等部门属于有强关联的部门，目前存在信息传达不到位，或者传达后，没有得到有效确认的机制，导致最后的输出结果有分歧。
解决方案：
1、软件产品部门对整个需求开发负责，但需求提供部门需给出相关的辅助资料和最新信息,建立一个4人小组，每个部门出1个人，小组所有成员对最终结果负责。 2、重要信息的传达，需要明确对接人，且需要书面传递和签字确认，保证信息能完整的传递。 3、基本信息的传达，可通过钉钉进行短信钉。保证接收人能看到。4、日常信息的传递需建立微信群，所有涉及到对产品有改动的辅助信息都需要共享，产品部门也需要将所有的改动点分享在群里。
问题2：
各部门信息不对等问题 目前软件产品开发是以市场为导向的设计，而产品策划对市场和营销的情况了解较少，且不同步，缺乏一个信息沟通的有效方式，造成信息滞后和不对等的问题，导致最后输出的产品在理解上存在一定误差。
解决方案：
1、建议搭建一个公司内部高层的信息沟通平台，有些保密性高的信息，可以在高层之间沟通，保证每个部门起码有一个人知晓重要信息。 2、需要推送到各个部门负责人的信息，建议使用钉钉，由专人负责发送，进行短信钉或者电话钉，保证所有人都能触达。 3、重要的市场变更信息需要落实在产品上的，可走特殊的绿色加急通道，由重要领导人签字确认。且重要领导人签字的红头文件，一律优先处理原则。4、各部门都需要列出一块公示板，公示板放置在显眼位置，写明当前正在处理的任务和进度。
问题3：
各部门流程及职能划分模糊 功能开发时，涉及需要协调各个部门提供内容，经常遇到职能范围模糊，或者职能重叠，在双方配合不足的情况下，易出现遗漏等问题。
解决方案：
1、明确规范各部门的职责，对开发过程中需要配合完成的任务，由项目经理进行责任分解，且对分解后的结果负责。 2、对各个部门的职能和负责的具体范围进行公示，让责任人自身和其他相关人员知晓 3、每一个项目，需由项目经理来确定基本流程之外的工作由谁负责。 4、为避免人员疏忽造成的越流程操作，工作流程中的每一步都需要书面化的签字，以代表每一个环节都有做到位
问题4：
对突发情况考虑不周 新版本上线后，对发布后存在的突发情况考虑不周全，没有建立应急体系。
解决方案：
1、因产品部门职只能看到逻辑层面的风险，缺乏市场方面的最新信息，每次发布新版本前，各个部门除了知晓发布时间外，都要提前提供可能出现的风险场景。 2、对不可预知的突发情况，相关部门除了提出问题外，还要改提出纸面通告和解决方法。让开发部门对产品改动有据可依，避免再次出错。3、对技术本身所存在的短板或风险，在执行前，需提供备用方案，避免上线后出了问题无法在线修复
问题5：
软件产品部门缺少产品负责人 前期软件产品部门有专门的负责人，后期因缺乏专人处理，开发文档和需求无法一一确认，只能通过默许的方式进行开发，导致众多问题出现。
解决方案：
1、新增软件产品负责人，对所有需求进行确认。产品经理向产品负责人汇报工作。 2、产品负责人可对各部门提出的需求进行筛选和过滤，可提高工作效率 3、产品经理向产品负责人确认结果，也可向产品负责人提产品迭代需求，加快产品本身的优化速度。4、产品负责人可对公司所有软件产品进行梳理，防止有产品死角和遗漏等问题，弥补目前专人负责专项的不足。
问题6：
对发布版本后的第一时间，没有做到相关责任人在场 版本上线时，各相关的责任人没有在现场对预发布环境进行再次确认测试，如针对文字信息的模块，运营部门的责任人没有在场进行仔细检查；针对UI页面的部分，UI责任人没有在场查看；针对整体功能模块，产品责任人没有在场把控协调。
解决方案：
1、在预发布的的环境上各责任人需在场针对自己负责的相关功能模块进行测试，如有不符合需求处应及时指出，产品经理针对提出的各个问题进行梳理整合；2、应有相对充足的时间在预发布环境测试，至少要预留一天的时间，而不是在发布前几个小时，否则当有问题时已无修改时间，产品经理要提前告知各个部门测试时间，以让各部门提前做好安排工作；
问题7：
信息变更流程不明确 当有一些计划变动时，相关部门没有及时通知或不予告知，导致涉及到的其它部门不知道计划变动从而做了无用功或因时间紧急做出粗糙工程。
解决方案：
1、提交需求计划的部门要明确需求的可行性和可实施度，在提交需求后尽量不变更，如必须变更的需重要领导签字同意，同时，产品经理也应做到实时的提醒和建议； 2、要有明确的变更流程，具体变更的责任人、变更缘由、问题导向、解决方案需要列明通知到位； 3、信息确认变更后，后续的计划也应大致说明，以备后续的工作实施再做准备；
问题8：
各环节，确定人不清晰，导致无法确认而模糊开发 需求的各模块具体功能内容和责任人不明确，使得设计内容时以自己认为对的来设计、开发以自己认为对的来开发、测试以自己认为对的来测试并且在出现问题的时候找不到相关责任人处理。
解决方案：
1、在各环节执行的过程中，需要项目经理把控节点促使每个环节得到最终确认，产品经理应该作为辅助从中协调；
2、各个部门相关人员需相互知道各个环节的责任人，当问题需要确认时直接找到负责该问题的责任人，促使工作正确执行；
问题9：
职能范围认知不统一的问题 产品经理在各环节没有明确的话语权，如在某个功能已被开发出来后，产品经理觉得该功能逻辑存在问题需要修改，但因时间问题、难度问题、职位问题等不被采纳。
解决方案：
1、在需求评审时，需要各部门对接人在场。明确每个人的责任范围和具体工作。 2、明确开发过程中的责任划分问题，应尽量采用捆绑责任制。且明示在此项目中，特殊职位所拥有的特权。3、需求开发前，需确定两个评判者（如需求对接人和产品经理），对于有争议的需求，两个评判者共同协商确定，如有重大争议的询问重要领导；
问题10：
需求文档到高保真图到最后开发确认，缺乏核查机制 在每一个环节中缺乏流程制度，功能需求的确认、UI页面的确认、文字内容的确认、最终版本的确认都没有一个明确的确认流程，导致最后的成品出现偏差。
解决方案：
1、首先，制定出一个完整的开发流程制度，各个部门按照流程制度执行； 2、产品经理要贯穿整个开发流程，把控协调各个环节的工作，协同各个部门一起推动工作，如在某个环节出现问题时，该环节的责任人和产品经理对问题进行调节解决； 3、产品经理作为沟通的桥梁和纽带，及时向上级领导汇报工作进度困难，及时与各团队汇报产品的进度，各个部门也应及时反馈相关问题。