【问题标题】:Complete Deploy vs Out of Cycle Deploy完整部署与非周期部署
【发布时间】:2010-11-11 20:40:03
【问题描述】:

我不确定你们中是否有人遇到过这种情况。我们有小型项目或 我们需要每隔一天推送到 LIVE 的修复程序。

有一组团队说“在产品服务器上进行干净的构建和部署”。 另一组说我们不必进行完整部署,我们只需进行 dll 删除或 aspx 删除即可。

他们列出了每种方法的一些优缺点。但是想知道您通常遵循哪种方法,每种方法都会遇到重大挫折。

【问题讨论】:

    标签: deployment build-process sdlc


    【解决方案1】:

    对于我控制的站点,我使用 SVN 或 Git 进行版本控制,并在需要时直接在服务器上更新源代码和编译。这确保了发布的完整性,我怀疑这是“在产品服务器上进行干净的构建和部署”团队提出的论点。对于不受我控制的服务器,我会做任何我被告知的事情:)

    【讨论】:

    • 这不仅仅是关于完整性。构建 MSI 测试 MSI 部署并查看它是否正常工作或损坏某些东西也需要人工。所以第二点是“COST”
    • 另外,我不会做任何我被告知的事情:) 我会建议最好的解决方案,如果他们拥有的解决方案没有得到优化,我会让他们改变。感谢您的回答!
    • 关于您的第二条评论,我通常为非常大的客户工作,这些客户不会根据他们雇用的 500 家左右的 3rd 方开发公司之一的心血来潮修改部署过程。但我羡慕你的力量。
    【解决方案2】:

    我首先会尝试尽可能自动化,以尽量减少构建新版本的成本。 (说起来容易做起来难,但通常会投入大量的时间和金钱,尤其是如果你经常发布的话。)

    我在添加新二进制文件时遇到的一个大问题是它通常是一个手动过程,而且这些过程是由人类执行的,他们往往会一遍又一遍地搞砸简单的任务。

    您是否真的在寻找一种“补丁管理系统”来帮助您以可控的方式分发更改并摆脱手动工作?

    这样您仍然可以保持良好的完整性,因为应该对补丁进行版本控制并希望对其进行仔细测试。但是仍然可以开发和部署它们,这比完整版本的开销要少得多。

    【讨论】:

      猜你喜欢
      • 2011-11-04
      • 1970-01-01
      • 2019-04-07
      • 1970-01-01
      • 2017-07-03
      • 2017-07-10
      • 1970-01-01
      • 2016-08-29
      • 2015-06-04
      相关资源
      最近更新 更多