我们目前正在使用一个有点复杂的部署设置，其中涉及一个远程 SVN 服务器，3 个用于 DEV、STAGE 和 PROD 的 SVN 分支，通过补丁等来促进它们之间的代码。我想知道您在小型开发团队情况下使用什么部署?
问问题
3297 次
11 回答
15
用于开发的主干，以及用于生产材料的分支（生产）。
在我的本地机器上，我有一个指向主干分支的 VirtualHost 来测试我的更改。
对主干的任何提交都会触发一个提交钩子，该钩子会执行 svn 导出并同步到在线服务器的开发 URL - 所以如果站点是 stackoverflow.com，那么这个钩子会自动更新 dev.stackoverflow.com
然后我使用 svnmerge 将选定的补丁从主干合并到本地结帐中的生产。我的本地机器上又有一个指向生产分支的 VirtualHost。
当我将合并的更改提交到生产分支时，SVN 导出挂钩再次更新生产（实时）导出并且该站点处于活动状态！
于 2008-08-26T23:45:56.213 回答
3
当我在一个小型开发团队工作时（小的意思是我，另一个程序员和老板），那是相当混乱的一团糟。但是，我们发现分配“看门人”类型的流程对我们有用。
看门人是在应用程序上完成最多工作的人（在这种情况下，我有 2 个我从头开始开发的项目，他有 4 个）。
基本上，每当他必须处理我的项目时，他都会通知我他正在工作，我会确保存储库是最新的并且可构建，然后他会下拉，进行更改，然后提交. 他会告诉我它已经完成，我会拉下，构建和部署。如果有 DB 更改，我们有一个 DB Change 文件夹，其中包含所有可以更正 DB 的脚本。
它显然有很多漏洞，但这个过程对我们有用，并且让我们无法相互建立。
于 2008-08-06T17:18:58.357 回答
3
三个分支听起来像是额外的工作。
可以通过在主干中具有不同版本的相关文件来处理环境差异。即database.yml & database.yml.prod。部署过程应该具有环保意识，只需将每个环境的文件复制到默认文件上即可。
于 2008-08-07T21:35:29.117 回答
3
我对常见的标签/分支/主干组织没有任何问题。
一般的持续开发发生在主干中。
生产中发布的维护发生在适当的发布分支中。
合并仍然与主干相关的发布分支的更改。
当一个新版本准备好部署时，它会从主干标记，然后从该标记创建一个分支。新的发布分支被检出到服务器，与当前发布平行。当需要切换时，路径会被调整（“mv appdir appdir.old && mv appdir.new appdir”）。
支持生产版本的开发人员然后 svn 将他们的工作副本切换到新分支，或者从它进行新的检查。
于 2009-02-04T14:17:08.913 回答
2
一个简单的主干分支包含最新的代码，然后在我们上线时剪切一个分支。这似乎非常有效。每当您为实时系统剪切的当前分支失败时，您都可以轻松转到上一个分支。此外，修复当前活动分支上的错误很容易，并且由于当您剪切一个新分支时该分支实际上会死掉，所以您只需要处理 1 个真正的分支（然后将修复从那里合并到活分支）。
于 2008-08-06T16:53:36.020 回答
1
我们不使用分支来暂存与 Web 相关的内容；仅用于测试需要很长时间（阅读：超过一天）才能合并回主干的实验性事物。以“持续集成”风格的主干代表（希望）工作的当前状态。
因此，大多数更改都会直接提交到主干。CruiseControl.NET 服务器将在同样运行 IIS 并拥有所有额外站点可用资源的最新副本的机器上自动更新，因此可以在内部对站点进行全面、干净的测试。经过测试，文件上传到公共服务器。
我不会说这是完美的方法，但它很简单（因此适合我们相对较小的员工）并且相对安全，而且效果很好。
于 2008-08-17T18:52:14.333 回答
1
Trunk 包含当前的“主要”开发代码库。
开发人员通常会为任何可能占用主干代码库并妨碍其他开发人员的中长期项目创建一个单独的分支。当他完成后，他将合并回树干。
每次将代码推送到生产环境时，我们都会创建一个标记发布。/tags 中的文件夹只是版本号。
为了部署到生产环境，我们正在执行 SVN Export to Staging。当这令人满意时，我们使用一个简单的 rsync 来推广到生产集群。
于 2009-02-04T06:10:35.340 回答
1
我强烈推荐这本书（目前是粗略的）持续交付，它描述了基于持续集成原则（以及其他）管理软件交付的完整过程。
我非常不喜欢分支和合并方法，因为它会变得非常混乱，并且非常浪费，因为您最终将时间花在实际上并没有带来任何新价值的活动上。您已经开发、测试和修复了一次代码，为什么要创建一个需要您重做这项工作的情况（将代码复制到另一个分支）？
无论如何，避免分支和合并的方法是从主干构建可部署的人工制品，并在通过测试、登台等时推广构建的人工制品（而不是源代码）。这样你就 100% 确定你是投入生产与您测试过的相同。
If you've got different features which may need to be released on different schedules, changing your approach to how you implement (make functionality configurable, or better yet modular) can help you keep a single development trunk.
于 2010-04-30T12:41:39.020 回答
0
我们使用发布分支——这对我们来说似乎比我们正在做的功能分支更有效。
不要为不同的环境制作不同的分支。
于 2008-08-26T23:50:45.530 回答
0
我个人在本地工作（开发），添加/修复功能，当我认为它准备好时，我会致力于主干（生产）。在生产服务器上，我只是进行 svn 更新。
于 2009-02-04T11:58:30.190 回答
0
我的工作情况与您目前的情况类似。我的任务是找到一个“更好”的解决方案，它按照以下方式运行。
实时分支代表处于当前状态的服务器。
任何开发工作都应该在取自 live 的分支中完成。这可能是一个人半小时的工作或长达一年的多团队项目。只要喜欢，生活的变化就可以合并到这些开发分支中。
在某项工作上线之前，来自 live 的更改会再次合并，并将其标记为潜在版本。此版本在暂存环境中进行测试，如果通过测试，则从标签中获取新版本。
如果效果更好，可以将多个工作合并到一个版本中。
这意味着让开发分支保持最新状态是相当简单的，如果开发中的一项工作被丢弃，则需要做的整理工作很少。
要从一个项目切换到另一个项目，开发人员可以简单地 svn 将他们的本地工作环境切换到不同的分支。
正如您所描述的，我们在系统中遇到的问题之一是 DEV 可以很快地与 PROD 过时，因此您不会针对实时进行开发，并且在阶段之前很难发现交叉依赖关系。上述解决方案解决了这些问题，同时仍然保持相当轻量级。
于 2009-02-04T13:01:04.387 回答