Questions tagged «deployment»

最近，我一直在大量阅读使用SVN或GIT进行的各种Web应用程序部署过程，以期重新设计我们目前在我的工作地点进行部署的方式。 就像许多种敏捷方法一样，我们假设提交给主服务器或主干的任何东西都已准备就绪。GitHub和Etsy（http://codeascraft.etsy.com/2010/05/20/quantum-of-deployment/）都说他们是在此基础上工作的（尽管Etsy实际上有一个暂存环境）。 此过程假定所有单元测试和CI测试都已运行。您在本地和CI上运行测试，然后提交到中继。所以，在这一点上，您的代码在技术上是正确的。 您的代码在技术上可能是正确的，但是用户/功能测试可能会发现更多错误，尤其是在涉及前端测试时。 我的问题是这个。质量检查和企业所有者在哪里测试您实施的功能更改？在提交中继之前是在本地开发计算机上还是在QA /登台计算机上？ 如果您有一台在主干上运行的登台计算机，并且假定提交到主干的所有代码都已准备好投入生产……嗯..那么，什么时候该代码已被批准，并且可以从技术和业务上投入生产透视？如果您只有一台登台计算机，并且有许多开发人员，并且要对这些代码进行质量检查，那么随着许多开发人员的更改可能正在等待注销，您如何从主干进行部署。 我很想听听其他人如何做到这一点？

9 git  unit-testing  svn  testing  deployment 

我正在尝试确定一种分发可能具有每周和/或每月更新的托管/站点Web应用程序软件更新的方法。我不希望使用现场产品的客户不必担心手动更新，而只希望它可以自动下载并安装Google Chrome。我打算提供一个包含Ubuntu和安装和配置的软件的OVF文件。 我关于如何分发软件的第一个想法是创建六个Apt存储库/通道（目前不确定哪个会更好），可以使用密钥通过SSH访问它，因此，如果客户不续订，我们可以禁用其帐户： Beta-在测试数据内部使用，以检查包装是否存在重大缺陷。 内部-内部用于实时数据以检查包装是否有缺陷（狗食阶段）。 外部1-部署到我们用户群的1％（随机选择）以检查缺陷。 外部9-部署到我们用户群的9％（随机选择）以检查缺陷。 外部90-部署到其余90％的用户。 托管-部署到托管环境。 如果报告了问题，则将在每个阶段进行签名以移入下一个存储库。 我对社区的问题是： 有人曾尝试过类似的方法吗？ 谁能看到这种程序的弊端？ 有没有更好的办法？

9 deployment  software-updates  package-managers  automatic-update