|
|
8 回复 | 直到 9 年前
|
1
5
这绝对是错误的。任何现代版本控制工具都支持提交前和提交后挂钩,此时您可以运行任何您想要的代码。 在Subversion中,每次开发人员签入代码时,我们都使用post-commit钩子将应用程序的副本部署到dev服务器。 在我们的实际生产服务器中,我们有代码来验证并部署稳定的次要版本标记,因为它们由发布管理器提交给repo。 |
|
|
2
6
版本控制与版本管理或部署几乎没有关系,所以VCS也不尝试这样做是有意义的。 我在这个地区看到的是建筑或 Continuous Integration (CI) servers . 这些程序听取VCS中的更改,在任何提交时执行新的签出,然后尝试构建所有内容。因此,他们集成了VCS和构建工具,从中收集日志,并将所有内容呈现在一个漂亮的Web UI中。 这样,每个工具都可以保持简单。 [编辑]CI服务器的附加值:
|
|
|
3
1
这取决于你想在这个系统上投资多少钱和时间。 许多人使用简单的版本控制(如SVN),并管理手动发布(使用标签和分支) 还有其他(免费)工具用于持续集成(持续构建应用程序),比如CruiseControl。 在数据库字段中,我不知道自由世界中有什么好消息,但是这里的某个人可能会完成这个任务。所以现在我手动管理数据库版本…… |
|
|
4
0
我想你在这里所说的发布管理通常被称为 build automation . 在这个空间中有各种工具(make、ant、nant等),但它们往往作为单独的工具存在。通常可以从单独的源代码控制中提取代码,并且您可以得到设计用于监督流程的产品(当流程自动完成时,称为连续集成)。 有些供应商提供的端到端工具在标题下 Application Lifecycle Management |
|
|
5
0
-->我的理解是“更现代”的版本控制工具只支持源代码管理部分。这种理解正确吗? VCS只处理源代码管理部分,如果您无法收到更改通知,这是毫无意义的(在某人实现了VCS基础知识之后,提供这一点不会有困难;-) -->我曾经工作过的大型机商店有一个自动化的发布管理工具,它不仅控制对源的并发修改,而且还负责运行编译器、预编译程序、数据库绑定实用程序等,使之成为我们的全自动化部署工具。 这被称为构建自动化,是的,如果项目中最好的部分在有人做出更改但没有必要时“准备好发布”,这是非常可取的。你可以 使用前面提到的工具做任何你想做的事情(它们是可扩展的)。 连续积分实践是这些点的插值方式。 这样,您在存储库中只有一个干净、稳定、高贵的代码。 有一些所谓的CI服务器连接VC和BA部件。 检查此页面的CI http://martinfowler.com/articles/continuousIntegration.html 如果有人需要与许多BA工具和许多VCS兼容的CI服务器 看看JetBrains TeamCity 希望这有帮助 |
|
|
6
0
在RubyonRails世界中,Capistrano是首选的部署工具。 |
|
|
7
0
我目前正在开发一个用于发布管理的Web应用程序,如果您想成为beta用户,请通知我。我有一个用于基本版本管理过程的工作版本,比如能够通过挑选您想要的更改(同时自动处理依赖性更改)来创建版本,并将版本历史中的任何一点推出或回滚到许多不同的环境(测试或生产服务器)。目前,它支持与SVN的集成。 拜托 http://www.ngashint.com 用于项目的博客网站。你可以留下你的电子邮件开始接收测试版,或者发邮件给我kzt001[at]gmail.com |
|
|
8
0
这个问题引起了我的注意,因为
在问题中,因为问题被标记为 version-control … 我也来自大型机世界,大型机“SCM”(=软件变更管理)是我们在过去25年左右所做的一切。 我有点惊讶(也许是“震惊”?看到所有 所谓的 同义词 版本控制 标签。尤其是 scm 标签(我不确定SE流程建议什么,不要再将其视为同义词)。至少在大型机领域,SCM远不止是版本控制(这只是SCM的一部分)。这些以某种方式相关的主题(即,imho,SCM的子功能)是什么?
为了说明它们的重要性,我经常问这个问题:“应用(bug)需要什么?”-在飞机上安装自动驾驶软件…飞行!?!?“换言之:“在您乘坐的航班中,在您感到舒适之前,必须采取的所有步骤和程序是什么?”. 从之前提供的各种答案中,我还不确定他们中的哪一个(如果有的话)可以选择用于这种空中错误修复。 |
