我很好奇其他人是如何在企业中管理从DEV到TEST再到PROD的代码升级的。
您使用哪些工具或流程来管理"繁文缛节"、进入/退出标准方面的问题？
我目前的组织在一些自定义的在线表单类型功能和基于纸张的依赖关系之间左右为难，无法提交文档、收集批准和审查。
所有这些都交给了项目经理来跟踪已经提交、通过审查、批准的内容，并在将申请推广到下一个环境之前，如果存在任何需要"忽略"批准的障碍，则向管理层提出建议。
基于浏览器的应用程序将是理想的。。。那外面是什么？请让我看看你的谷歌比我的好。
通过谷歌很难找到一个好的。有大量的工具可以用于问题管理，所以我会提到我们使用什么以及我们想使用什么。
我们目前使用serena产品。他们过去为我们工作得很好。Team Track是我们的问题管理，处理我们处理的任何问题的生命周期。Version Manager是我们的源代码管理，具有实施DEV TEST和PROD等促销小组的功能。我们使用DEV、TSTAGE、TEST、PSTAGE和PROD来表示从一个问题到另一个问题的移动，但基本相同。这两个产品很好地集成在一起，因此与问题相关的源代码是链接的，但我们在这个环境中没有构建过程设置。它很贵，但效果很好。
我们正在寻找一个更通用的系统，使用Jira进行问题管理，使用Subversion进行源代码管理，使用Fisheye将两者联系在一起，使用Cruise control进行构建管理。这比较便宜，一个企业级的总共几千美元，提供了所有相同的功能，但增加了SVN的好处，这是一个非常好的代码版本漫画。
我希望这能有所帮助。
这些年来，我经历了一些不同的场景：
开发->测试：通常有一个代码冻结日期，它会停止对新功能的工作，并获得一个测试环境——已经标记/标记/存档的代码。然后将其复制到机器上，测试就可以顺利进行了。这通常也是所有推送中最不详细的。
测试->生产：这需要进行一些小的更改，生产必须关闭，这可能意味着"钓鱼"页面会打开，或者IIS没有任何站点在运行，代码会被重新复制。在某些特殊情况下，负载均衡器可以充当交换机，这样就可以进行促销，而且不会有客户出现任何停机时间，因为旧服务器上的客户在会话结束后会移动。
为了详细说明切换的想法，设置是有两个潜在的实时服务器，其中只有一个服务器接受负载平衡器只将所有流量发送到一台机器的请求，当另一台服务器有更新的代码要运行时，就可以切换这台机器。
也可以有一个介于测试和生产之间的过渡环境，在这个环境中，流程是相似的，因为升级的日期是固定的。
在我过去工作的地方，会有一些合并日，开发人员花了一天的大部分时间在Perforce中合并代码，以便将其从一个环境升级到另一个环境。
现在有几种情况没有使用：
"修补程序"或"热补丁"会出现在我以前工作的地方，在这种情况下，特定的文件会被复制到暂存和生产环境中，因为代码更改必须尽快进入生产环境，因为生产中出现了问题，或者必须完成一些需要2分钟才能完成的新事情。在这种情况下，被推入的代码更改在发出之前必须经过审查和批准。
这些都是我见过的不同方法，通常情况下，时间表和时间表可能需要更改，或者引入额外的资源来制定一个艰难的日期，比如如果会议在某个特定的周末举行，那么某个人已经做好了准备。
当然，在一些地方，有人会说，"哦，它坏了吗？让我看看……"几分钟后，"不，看看它对我来说没有坏"，有人在未经许可的情况下更改了东西，或者公司仍然有他们所说的"牛仔编程"
另一点是发布的规模：1） 微小-这种情况下，一个网页上升，用户X可以做Y。
2） 小-一小部分文件，这些文件并不复杂，但也不完全是琐碎的。
3） 介质-从一个环境到另一个环境需要更改一堆文件，并且通常需要移动脚本。
4） Big-有预定的促销活动，并询问各种开发商在直播推送完成时谁将轮班。我在一个案例中遇到了这种情况，除了发布一些新的电子商务网站外，还需要进行数据迁移。
5） 长毛象——所有东西都是全新的，包括如何使用。我想我从来没有见过这么大的版本，但我想微软或谷歌会有这样大的版本。
在这一范围内的某个地方，大多数发布都会下降，因此规划和准备的程度可能会有很大的差异，我们不要忘记，在完成一些事情时，法规遵从性可能是其自身的痛苦。