我习惯于在C#.NET中编写桌面应用程序。我有一个很好的小解决方案文件夹,也在版本控制下。因此,在任何时候,在任何计算机上,我都可以查看我想要的任何软件版本,运行编译器并获得我的程序的工作副本。
现在我正在研究开发网站,其中文件和数据分散得多。我正在使用ASP.NET,但实际上我的问题更为通用,可以应用于任何网站框架。
我正在努力了解开发我的网站,版本控制服务器和用户将看到的实际实时网站之间的正确工作流程。显然,这可能会有很大差异,具体取决于网站的类型和规模,但我只考虑一个非常简单的网站。我刚刚开始使用这些东西。
下图显示了我目前的想法。该站点的所有源文件都将存储在subversion服务器上,我将检查到我的本地计算机上。我的本地计算机将有一个本地数据库,我将用于开发该网站。接下来,我将发布到托管服务器上的测试版本,该版本将指向单独的测试数据库。该测试数据库可以定期由实时数据库的副本替换。
如果一切顺利,我会发布到指向实时数据的网站的测试版。然后,用户可以查看测试版以提供反馈。最后,如果仍然没有问题,将更新实时站点的源文件。
这有意义吗?有没有人对如何改进这一点有任何意见?有没有关于开发这类工作流程的好书或在线教程?
另外,我真正不确定的一件事是如何管理对数据库实际架构的更改。我想每个版本我都可以生成一个SQL脚本,可以用来更新主机上的Test和Live数据库。但是,我还希望能够为我的站点的任何版本轻松设置新数据库,而不必为每个版本运行每个更新SQL脚本,直到所需版本。是使用像NHibernate或Subsonic这样的ORM的最佳解决方案,所以我总能直接从我的代码生成我的数据库模式?
答案 0 :(得分:0)
我目前使用的工作流程与此非常相似。它并不完美,但在大多数情况下它运作良好。听起来你几乎已经找到了重要的部分。
我工作的地方有一个功能强大的网络服务器。我们的subversion repos也存在于这台服务器上。对于我自己,作为LAMP开发人员,我使用本地MySQL数据库在本地Linux机器(或VM)上进行所有开发,并在本地工作副本上运行。
我始终维护应用程序的两个主要分支:Dev分支(主干)和Live分支(反映当前的生产版本)。我的回购看起来像这样:
/repo/trunk/ [My current active development version]
/repo/archive/ [All other versions not in active development live here]
/repo/archive/2010.12/ [This happens to be the current production version]
在Web服务器上,我们维护三个独立的软件实例:Live(或Production),Beta和Dev。以下内容应说明我们如何使用这些版本
Dev - 始终指向我们在`/ repo / trunk'的开发版本。使用非vesioned配置文件指向开发数据库。然而,开发从未在这里完成;相反,我们在本地机器上工作,我们的工作副本指向Trunk,并在我们的本地机器上进行所有开发测试。但是,经过多次开发人员的多次提交后,在Dev服务器上进行测试以确保我们处于正确的轨道并且没有人破坏其他人的更改是非常重要的。
直播 - 总是指向最新的稳定版本。在这种情况下,它指向/repo/archive/2010.12/
。这个版本可以通过世界访问。
Beta - 大多数情况下,Beta会反映Live上的内容并指向我们存储库中的相同生产版本(/repo/archive/2010.12
)。任何时候我们需要Live上的bug修复,我们在这里制作它们,测试它们,然后提交&更新直播。 (如有必要,我们也会将它们合并到Trunk中。)
当Trunk中的版本被认为已完成并准备好进行测试时,我会通过svn copy
现有的生产分支在存储库中为即将发布的新版本(即2011.01)创建一个新的归档分支。然后我将Trunk版本合并到新分支并提交,因此我们有一个版本可以反映当前Dev上的内容。当然,现在可以继续在Dev上继续开发下一个版本,而我们在Beta上测试这个新的Archived版本。 beta测试完成后,我们会提交任何修复程序并将Live切换到新版本(/repo/archive/2011.01
)。
现在,您可能已经发现数据库合并有点棘手。我们使用MySQL,据我所知,MySQL没有合适的版本控制系统。因此,每次迁移(VM到Dev,Dev到Beta,Beta到Live)我都会先备份当前数据库,然后进行必要的更改。我个人使用SQLYog的商业版本,它允许我同步数据库模式(超级方便)。