在单个测试服务器用于Web开发的情况下,我对svn的正确使用感到困惑。
我们正在努力避免为每个开发人员创建本地测试服务器,因为系统相当复杂,因此难以配置且运行繁重。因此,我们正在考虑使用单个测试服务器,其中所有开发人员(实际上只有少数同时)可以测试他们的更改。
假设我们使用svn进行版本控制,我们该如何进行?我们考虑过这些选项:
所有修改都通过svn。当我想修改文件时,我更改了本地副本并提交了它们。但是,由于我无法进行任何本地测试,因此我们经常会破坏代码并恢复svn中的更改。这有多糟糕?
修改直接在测试服务器上完成,经过测试,然后才提交给svn。在这种情况下,我们失去了本地副本/合并的优势,因此可能会有几个开发人员修改同一个文件的问题......
修改是在服务器上的代码的多个“本地”副本中完成的,我们可以从一个副本切换到另一个副本或同时运行它们来进行测试。这需要特殊的配置和服务器上的大量空间。
我们缺少一个更好的选择,或者哪个是最差的选择?感谢。
答案 0 :(得分:1)
分支可能对查看(http://svnbook.red-bean.com/en/1.1/ch04.html)很有用。您可以为每个开发人员创建一个分支,当他们确定他们的更改不是有害的时,他们可以推送到主干。
答案 1 :(得分:1)
如果空间不是问题,我建议在同一台服务器上使用多个svn副本。当你到达里程碑时,让你的主目录svn update
,然后有几个dev文件夹作为你的工作副本。
如果空间太大问题,除了直接在实时代码上工作或在个人计算机上运行它之外别无选择。
答案 2 :(得分:1)
无法在本地测试更改的环境有多复杂?如果环境太大而且太复杂而无法在开发人员的工作站上运行,那么真的想要研究模拟和单元测试。你真的有两种对立的力量:
单元测试(当然,要求代码以离散的可测试单元编写/维护)和模拟不是这个问题的最终答案,但它会有所帮助。很多。
如果您选择第一个选项,那么持续集成和持续部署到您的测试环境至关重要。需要立即识别错误或者您的开发人员将在错误上创建错误,整个系统将很快变得混乱。
你的第二个选择是禁忌。如果开发人员和源代码控制之间存在不受控制的步骤,那么您将完全破坏源代码管理的“控制”部分。也可以只在FTP共享上存储代码。
第三种选择可能是你最好的选择。选择该选项也为未来的改进打开了大门。毕竟,如果您可以为每个开发人员隔离并基本上为新实例/环境添加橡皮图章,那么每个开发人员应该距离本地环境很近。硬件很便宜,依赖可以被嘲笑等等。
答案 3 :(得分:1)
您似乎可以从更好的开发环境中受益。我知道每个开发人员机器上的完整测试系统可能很重,但是在检查代码之前,应该在开发人员机器上进行良好的单元测试。
您将受益于持续集成。您的测试环境可以成为您的集成环境,可以进行完整的端到端测试,也可以进行集成测试。应该每天使用工作分支中的最新代码进行全新部署来更新您的测试环境。
答案 4 :(得分:0)
从长远来看,第一种方法会杀了你。如果您只有一个开发人员进行更改然后回滚,那就没问题了。但是有几个开发人员在每个人身上引入了heisenbugs。然后回滚变化...... 耸肩。
如果真的无法让每个开发人员都拥有自己的系统本地副本,我会给你的第三个选择。在强大的测试服务器上为每个开发人员单独设置一个应用程序“实例”。
作为旁注:也许虚拟机可以帮助你吗?
答案 5 :(得分:0)
由于你的系统设置起来非常复杂,我会给每个开发人员一个在中央测试服务器上的“沙盒”,为“稳定”增加+1,一旦完成它们就会合并到一起。
我还要补充一点,修复因处理1份代码而导致的额外错误和问题的成本远远高于额外服务器空间的成本(几乎在所有情况下)。请你的开发者帮忙,给他们每个沙盒都可以玩。你的底线,从长远来看,会感谢你,你会有更快乐的开发者。