【问题标题】:How do I learn how to create/deploy/administer a website?我如何学习如何创建/部署/管理网站?
【发布时间】:2011-01-20 01:17:27
【问题描述】:

我习惯于用 C#.NET 编写桌面应用程序。我有一个很好的小解决方案文件夹,它也在版本控制之下。因此,在任何时候,我都可以在任何计算机上检查我想要运行编译器的任何版本的软件并拥有我的程序的工作副本。

现在我正在研究开发网站,其中文件和数据更加分散。我正在使用 ASP.NET,但实际上我的问题更笼统,可以适用于任何网站框架。

我正在尝试了解开发我的网站、版本控制服务器和用户将看到的实际实时网站之间的正确工作流程。显然,根据网站的类型和规模,这可能会有很大差异,但我只考虑一个非常简单的网站。我才刚刚开始接触这些东西。

下图显示了我目前的想法。该站点的所有源文件都将存储在一个颠覆服务器上,我会将该服务器检出到我的本地计算机上。我的本地计算机将有一个本地数据库,我将使用它来开发站点。接下来,我将发布到我的托管服务器上的测试版本,该版本将指向一个单独的测试数据库。此测试数据库可能会定期被实时数据库的副本替换。

如果一切顺利,我会发布到指向实时数据的网站的测试版。然后用户可以查看测试版以提供反馈。最后,如果仍然没有问题,将更新实时站点的源文件。

这有意义吗?有没有人有任何关于如何改进的cmet?有没有关于开发这类工作流程的好书或在线教程?

另外,我真的不确定的一件事是如何管理对数据库实际架构的更改。我认为每个版本都可以生成一个 SQL 脚本,用于更新主机上的 Test 和 Live 数据库。但是,我还希望能够轻松地为我的站点的任何版本设置一个新数据库,而不必为每个版本运行每个更新 SQL 脚本直到所需的版本。使用像 NHibernate 或 Subsonic 这样的 ORM 是最好的解决方案,所以我总是可以直接从我的代码中生成我的数据库模式?

【问题讨论】:

    标签: asp.net web workflow


    【解决方案1】:

    我目前使用的工作流程与此非常相似。它并非完美无缺,但在大多数情况下它运作良好。听起来您几乎已经弄清楚了重要的部分。

    在我工作的地方,我们有一个强大的网络服务器。我们的 subversion repos 也存在于这个服务器上。对于我自己,作为 LAMP 开发人员,我在本地 Linux 机器(或 VM)上使用本地 MySQL 数据库进行所有开发,并在本地工作副本上运行。

    我始终维护应用程序的两个主要分支:一个 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]
    

    在网络服务器上,我们维护着三个独立的软件实例:Live(或 Production)、Beta 和 Dev。下面应该说明我们如何使用这些版本来

    • Dev - 始终指向我们在 `/repo/trunk' 的开发版本。使用非版本化配置文件指向开发数据库。然而,开发从来没有在这里完成;相反,我们在本地机器上工作,我们的工作副本指向主干,并在本地机器上进行所有开发测试。但是,在多个开发人员多次提交之后,在开发服务器上进行测试以确保我们走在正确的轨道上并且没有人破坏其他人的更改,这一点很重要。

    • 实时 - 始终指向最新的稳定生产版本。在这种情况下,它指向/repo/archive/2010.12/。此版本全球通用。

    • Beta - 大多数时候,Beta 将是 Live 内容的镜像,并指向我们存储库中的相同生产版本 (/repo/archive/2010.12)。每当我们需要在 Live 上修复错误时,我们都会在这里制作、测试它们,然后实时提交和更新。 (如有必要,我们还将它们合并到 Trunk 中。)

    当 Trunk 中的版本被认为已完成并准备好进行测试时,我会在存储库中为即将发布的新版本(即 2011.01)创建一个新的存档分支,svn copying 现有的生产分支。然后我将 Trunk 版本合并到新的分支中并提交,这样我们就有了一个反映 Dev 上当前内容的版本。当然,现在下一个版本的积极开发可以在 Dev 上继续进行,而我们在 Beta 上测试这个新的存档版本。 Beta 测试完成后,我们会提交所有修复并将 Live 切换到新版本 (/repo/archive/2011.01)。

    现在,您可能已经发现数据库合并有点棘手。我们使用 MySQL,据我所知,没有适合 MySQL 的版本控制系统。因此,对于每次迁移(VM 到 Dev、Dev 到 Beta、Beta 到 Live),我将首先备份当前数据库,然后进行必要的更改。我个人使用 SQLYog 的商业版本,它允许我同步数据库模式(超级方便)。

    【讨论】:

    • 谢谢,这真的很有帮助。你是对的,听起来你正在做我打算做的事情。虽然这对我来说会更简单,因为我不必担心除我自己之外的任何开发人员承诺回购。但是,是的,我仍然不能 100% 确定如何管理本地、测试版和生产之间的数据库架构更改。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2016-10-17
    • 1970-01-01
    • 2019-12-03
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多