协助管理企业环境中的应用程序升级流程的工具
我很好奇其他人如何管理企业内从 DEV 到 TEST 再到 PROD 的代码升级。
您使用什么工具或流程来管理“繁文缛节”、进入/退出标准方面？
我当前的组织在一些自定义在线表单类型功能和基于纸张的依赖项之间陷入困境，以提交文档、收集批准和审查。
所有这些都留在项目经理手中，以跟踪已提交的内容、通过审查、批准的内容，并在应用程序升级到下一个环境之前是否存在任何可能需要批准“忽略”的障碍，并建议管理层。
基于浏览器的应用程序将是理想的...那么那里有什么呢？ 请告诉我你的 googlefu 比我的好。
I am curious on how others manage code promotion from DEV to TEST to PROD within an enterprise.
What tools or processes do you use to manage the "red tape", entry/exit criteria side of things?
My current organisation is half stuck between some custom online forms type functionality and paper based dependencies to submit documents, gather approvals and reviews.
All this is left in the project managers hands to track what has been submitted, passed review, approved and advise management if there are any roadblocks that may need approval to be "overlooked" before an application can be promoted to the next environment.
A browser based application would be ideal... so whats out there? please show me that you googlefu is better than mine.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
通过谷歌很难找到一个好的。 有大量用于问题管理的工具，因此我将提及我们使用的工具以及我们想要使用的工具。
我们目前使用 Serena 产品。 他们过去为我们工作得很好。 Team Track 是我们的问题管理，负责处理我们处理的任何问题的生命周期。 版本管理器是我们的源代码控制，具有实现 DEV TEST 和 PROD 等促销组的功能。 我们使用 DEV、TSTAGE、TEST、PSTAGE 和 PROD 来表示从一种到另一种的移动，但它们大致相同。 这两个产品很好地集成，因此与问题相关的来源是链接的，但我们在此环境中没有构建过程设置。 它很贵，但效果很好。
我们希望转向一个更通用的系统，使用 Jira 进行问题管理，Subversion 进行源代码控制，Fisheye 将两者连接在一起，Cruise Control 进行构建管理。 这更便宜，企业许可证总共需要几千美元，并提供所有相同的功能，但还有 SVN 的额外好处，SVN 是一个非常好的代码版本管理器。
我希望这有帮助。
It's hard to find one that's good via google. There is a vast array of tools out there for issue management so I'll mention what we use and what we woudl like to use.
We currently use serena products. They have worked well for us in the past. Team Track is our issue management and handles the life cycle of any issue we work on. Version Manager is our source control and has the feature of implementing promotional groups like DEV TEST And PROD. We use DEV, TSTAGE, TEST, PSTAGE and PROD to signify the movement from one to the other, but it's much the same. The two products integrate nicely so that the source associated with the issues is linked, but we have no build process setup in this environment. It's expensive, but it works well.
We are looking ot move to a more common system using Jira for issue management, Subversion for source control, Fisheye to link the two together and Cruise Control for build management. This is less expensive, totaling a few thousand for an enterprise lisence and provides all the same features but with the added bonus of SVN which is a very nice code version mangager.
I hope that helps.
多年来我经历过几种不同的场景：
开发 -> 开发 -> 开发 -> 开发 -> 开发 -> 开发 测试：通常会有一个代码冻结日期，该日期会停止新功能的工作，并获取一个测试环境，其中已标记/标记/存档的代码已构建。 然后将其复制到机器上并且测试顺利进行。 这通常也是所有推送中最不详细的。
测试->产品：这需要进行一些微小的更改，生产必须停止，这可能意味着“钓鱼”页面出现，或者 IIS 没有任何站点运行，并且代码将被再次复制。 在特殊情况下，负载均衡器可以充当交换机，以便进行促销，并且不会有任何客户遇到任何停机时间，因为旧服务器上的客户一旦会话结束就会移动。
为了详细说明这种切换的想法，设置是有 2 台潜在的实时服务器，其中只有一台服务器接受请求，负载均衡器将所有流量发送到一台机器，当另一台服务器具有要上线的更新代码时，可以切换该机器。
还可以有一个介于测试和生产之间的暂存环境，其中流程相似，促销发生时有固定的日期。
在我以前工作的地方，会有一些合并日，开发人员会花大部分时间在 Perforce 中合并代码，以便可以将其从一个环境升级到另一个环境。
现在有几种情况不使用此功能：
在我以前工作的地方会出现“修补程序”或“热补丁”，在这种情况下，特定文件会自行复制到登台和生产环境中，因为代码更改必须尽快进入生产阶段，因为生产中出现了一些问题，或者一些必须在 2 分钟内完成的新事情才能完成。 在这种情况下，推送的代码更改必须在发布之前经过审查和批准。
这些是我见过的不同方法，通常需要更改时间表和时间表，或者引入额外的资源来确定一个艰难的日期，就像会议在某个特定的周末举行一样，这样或那样的准备。
当然，在一些地方，有人会说，“哦，那东西坏了吗？让我看看……”几分钟后，“不，看看它对我来说没有坏”，有人在没有询问的情况下就改变了东西许可或任何公司仍然拥有他们所谓的“牛仔编程”的东西。
另一点是发布的规模：
1) 微小 - 这是一种情况，其中一个网页打开，以便用户 X 可以执行 Y。
2) 小 - 少数文件，不是真正复杂，但也不是微不足道的。
3) 中 - 从一个环境到另一个环境需要更改一堆文件，并且通常需要移动脚本。
4) 大 - 那里有预定的促销活动，并且当实时推送完成时，各个开发人员被询问谁正在轮班。 我遇到过这种情况，除了发布一些新的电子商务网站之外，还需要进行数据迁移。
5）猛犸象 - 一切都是全新的，包括如何使用。 我想我从来没有见过这种尺寸的产品，但我想微软或谷歌也会发布这种尺寸的产品。
大多数版本都属于这个范围，因此规划和准备的程度可能会有很大差异，我们不要忘记，在完成某些事情时，遵守法规可能是其本身的痛苦。
There are a few different scenarios that I've experienced over the years:
Dev -> Test : There is usually a code freeze date that stops work on new features and gets a test environment the code that has been tagged/labelled/archived that gets built. This then gets copied onto the machines and the tests go fine. This is also usually the least detailed of any push.
Test->Prod : This requires the minor change that production has to go down which can mean that a "gone fishing" page goes up or IIS doesn'thave any sites running and the code is copied over again. There are special cases to this where a load balancer can act as a switch so that the promotion happens and none of the customers experience any down time as the ones on the older server will move once their session ends.
To elaborate on that switch idea, the set up is to have 2 potentially live servers with just one server taking requests that the load balancer just sends all the traffic to one machine that can be switched when the other server has the updated code to go live.
There can also be a staging environment which is between test and production where the process is similar in terms of there is a set date when the promotion happens.
Where I used to work there would be merge days where a developer spent most of a day in Perforce merging code so that it could be promoted from one environment to another.
Now there are a couple of cases where this isn't used:
"Hotfixes" or "Hot patches" would occur where I used to work and in this case the specific files were copied up into the staging and production environments on its own since the code change had to get into Production ASAP since something broke in production or some new thing that had to get done that takes 2 minutes gets done. In this case, the code change getting pushed in had to be reviewed and approved before going out.
Those are the different approaches I've seen used where generally there are schedules and timelines potentially have to be changed or additional resources brought in to make a hard date like if a conference is on a particular weekend that such and such is ready for that.
Of course in a few places there has been the, "Oh, was that broken? Let me see..." and a few minutes later, "No, see it isn't broken for me," where someone changed things without asking permission or anything where a company still has what they call "cowboy programming."
Another point is the scale of the release:
1) Tiny - This is the case where one web page goes up so that user X can do Y.
2) Small - A handful or so of files that isn't really complicated but isn't exactly trivial.
3) Medium - Where going from one environment to another requires changing a bunch of files and usually has scripts to move.
4) Big - Where there are scheduled promotions and various developers are asked for who is taking which shifts when the live push is done. I had this in a case where there was a data migration to do in addition to a release of some new e-commerce sites.
5) Mammoth - Where everything is brand new including how this would be used. I don't think I've ever seen one of this size but I'd imagine Microsoft or Google would have releases of this size.
Somewhere in that spectrum most releases fall and so how much planning and preparation can vary quite a bit and let's not forget that regulatory compliance can be its own pain in getting some things done.