我的问题是,如何以良好的方式版本控制生产环境?
这是我们目前的环境:
(内部服务器)开发 – 版本控制的源代码
(客户服务器)验收testing环境
(客户服务器)分段环境
(客户服务器)生产环境
当我们发布验收testing的新function时,我们在Visual Studio中进行发布,压缩更改并将其应用到testing服务器上。 在那里,我们创build一个备份文件夹(以便我们可以恢复更改),并制作一个发布文件夹,以便我们在批准时将这些更改移到暂存。
这是大量的手工创build备份文件夹,释放文件夹,重新创build目录结构,并尝试跟踪什么function进入什么版本。 这是很费力的,并且一些开发者没有遵循释放程序总是有问题。
如何在windows Server 2003上从IIS 6提供文件?
NGEN显示返回在C#winforms中使用Process.Start()运行时,与高位CMD不同的结果
WPF绑定Canvas.left / Canvas.top到Point DependencyProperty,使用PointAnimation
Mono / Ubuntu – 冲突的定义
如何刷新未决的fileSystemWatcher事件?
理论上我可以为testing环境创build一个存储库。 (忘记源代码,这是关于已发布的应用程序)在每个版本中,开发人员都会进行提交并提供有关他所发布function的评论。
当function从testing移动到分段时,我们导出从更新分段环境更新的更改并将其复制到分段应用程序中。 在那里,我们做了一个提交,以后可以提取发布到生产环境。
这样做的缺点是,使用Subversion会将应用程序与这些.svn目录混淆。 这可以通过禁止访问IIS或web.config中的这些目录来修补。 另一种解决scheme是在应用程序根目录上的目录中使用Git。 但是,在windows环境下,Git更难与无经验的开发人员一起工作。
有没有人有这个问题的经验? 你如何控制你的生产环境? 如果您需要还原发行版,那么您是否有在发行之前创build的备份文件夹?
我已经和我们的开发人员讨论过这个问题,他们也看不到使用Subversion进行testing/临时/生产环境的版本控制和备份的问题。 相反,他们会很高兴不要在每次需要发布新function时都创build发布/备份文件夹。
同时对此也有一些不安全感。 没有人听说过这个,在版本控制系统中有应用,我们不确定这些缺点是什么。
如果您有这种情况的经验,我会很乐意听到这个消息。
Mikael Lundin
我怎么能听监视器被添加或删除?
包含无法从windows中看到的文件
如何使我的服务停止自动发布到windows应用程序事件日志
当我的DLL版本改变了,我应该改变我的ProgID版本吗?
UWP的@R_301_5979@bar后退@R_403_5554@
另一种做事的方法是使用构建服务器。 每次检入代码时,构建服务器都会在开发环境中构建并打包新构建。 然后用代码检查可部署的包。
然后,您可以将打包的版本部署到其他环境。 这样您就不必在那里备份版本,因为您已经拥有主版本库中的所有内置版本。 如果确保部署完全自动化并且可以使用一个命令(powershell?)完成,则不需要在服务器上保留备份。
这实际上比您提出的解决方案更好,更易于维护。 因为构建的每个版本都与代码一起保存,所以您始终可以为任何构建包找到完整的开发环境。 如果你单独控制你的服务器,并且在某个地方发现了错误,那么很难找到导致错误的代码版本。
我一直使用汞 (Hg)作为生产版本控制系统。 (不是代码,但实际部署的二进制文件)。 这工作得很好。 Subversion在我的场景中使用不太合适,因为我确实希望能够将生产更改(如配置文件)同步到测试甚至是开发。 颠覆很难在不同的仓库之间同步/合并(大量的手动应付)。 与hg标签和hg更新有一个微风恢复到稳定(或不稳定)的标签。
哦,我完全同意,你应该使用buildserver(cruisecontrol.net)或其他东西,并保持所有的东西在那里。 我的情况是不够的,因为客户生产系统的配置是自定义特定的,甚至是广泛的测试,什么不是可以有一些配置不再做两个版本之间的相同的事情(或传入数据已经显着改变)
我们使用subversion作为部署东西到我们不同的服务器(prod,demo,dev等),并没有遇到任何困难。 唯一需要注意的是数据库差异和配置文件的差异。 配置文件可以进行模板化,以免覆盖每个不同部署中的文件,但是您不会针对特定平台的更改进行版本化。
通过这种系统,您可以使用Subversion的标签轻松地更新/回滚到特定的部署版本。
感谢您的回答和建议。
我看到我需要重新考虑处理这些环境的发布方式。 拥有所有版本的构建服务器可以解决问题的一部分。 我将得到关于源代码的提交评论,并更好地控制什么功能进入什么样的构建。 我仍然需要跟踪在什么环境下构建什么版本,以便在出现问题时能够恢复发布。
@Jonke我会看看Mercurial。 也许一个版本控制的生产环境是过度的,如果你有一个构建系统,其中每个版本都有版本控制的源代码。 但是,如果在部署新功能的过程中出现任何问题,我仍然希望能够快速恢复到以前版本的更改。 我也喜欢在服务器上获得版本控制配置文件的方式,因为生产环境总是与开发环境有不同的配置。
也许我正在寻找银子d:)
总结以上是内存溢出为你收集整理的版本控制的生产环境全部内容,希望文章能够帮你解决版本控制的生产环境所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)