Svn Web开发项目管理的良好实践

我意识到“良好实践”一词有点可疑，使用过度，但我认为它适用于我的问题

我有一些很好的web开发经验，但我想听听在做自由职业者工作时，相对于项目管理，有哪些好的基本做法

例如，我的目标域是mydomain.com。我应该在受.htaccess保护的子域（即dev.mydomain.com）或其他方式进行所有测试吗

我熟悉SVN，但不熟悉web开发。控制网站版本的最佳方法是什么

我已经建立了两个数据库，mydb

\uu

dev和mydb

\u

rel。我在_dev上完成所有工作，然后将结构转移到_rel，这有意义吗？第一次发布后会发生什么

---

如果你能回答其中一些问题，或者把我和一个好的资源联系起来，那就太好了。到目前为止，我的搜索只产生了HTML教程

至于版本控制，我想说的是将所有不是动态创建的东西都置于控制之下。例如，如果您的应用程序在运行时生成了一堆.txt文件，则不需要对这些文件进行版本设置，但任何只创建一次的文件都需要进行版本控制

至于您选择的版本控制系统，我建议您选择SVN以外的版本（可能是Git或Mercurial），但这只是我个人的偏好，而不是任何实质性的原因。

我们所做的

使用允许在部署的web服务器之外进行测试的框架。我们在笔记本电脑上开发和测试。有些人使用在Eclipse下运行的Glassfish进行测试。另一个使用Django，它独立运行。我们的笔记本电脑上有用于开发和测试的数据库。我们使用配置文件来确保数据库、目录等使用“开发”名称

在虚拟机上进行集成测试。我们的主机是基于Red Hat Enterprise Linux的，所以我们有Fedora虚拟机，用于测试Apache和MySQL（或Oracle）以及整个技术堆栈。我们在VM环境中有集成测试数据库。我们使用配置文件来确保我们正在使用数据库、目录等的“测试”名称

我们使用的产品部署非常整齐。Glassfish/Java应用程序与WAR或EAR文件一起部署。Django应用程序使用Python的

setup.py

installer。这样我们就可以安装到生产环境中，摆弄数据库，然后我们就可以开始运行了。我们使用配置文件来确保数据库、目录等使用“生产”名称

第一个版本涉及第一次构建数据库。我们提供一个脚本（或者在Django的情况下，我们运行

manage.py syncdb

命令）来构建数据库

在进行模式更改时，我们可以使用脚本或指令。我们必须在测试和生产中再做一次

在部署到全球可见的生产环境时，我们会这样做

我们的托管环境中有一个虚拟机，它是“暂存”的。我们要让它工作。它在互联网上是看不见的。我们签出我们的组件，安装它们，运行DB模式更改脚本（或者执行手动步骤，如果很复杂）。通常，我们处理生产数据库的副本

然后，我们克隆该VM以创建生产VM。我们更改生产配置以使用生产数据库的升级副本

---

我们没有一个名为“prod”的数据库，这很难使用。我们在生产中有“prod_3”，在升级时在阶段中有“prod_4”。然后，我们将配置文件更改为使用“prod_4”。“prod_3”可以挂起，直到我们需要磁盘空间来创建“prod_5”。

我通常建议如下。团队应具有3种“部署”环境：

• 开发环境：这是开发人员工作和发布的地方
• 测试环境：这是进行测试的地方，也可能向客户展示。这里应该只部署工作产品
• 生产环境：运行和使用的产品的最终部署

处理这个概念的东西。我建议的是，“测试环境”（或预发布环境）位于与最终“生产环境”配置相同的服务器上

---

对于与版本控制有关的问题，我将使用它来对源代码进行版本控制。您可以使用任何您喜欢的版本控制（甚至配置管理工具）。在这里，进行分支是一个很好的实践，因此每当您发布产品（将其部署到生产环境）时，您都会创建一个具有相应版本号的分支。同时，您继续在主分支上进行开发。这样做的好处是，您可以修复可能发生在发行版上的错误，并且可以重新部署分支副本，而无需重新部署同时在主开发分支上添加的新功能。在网上搜索分支的最佳实践，有很多东西。然而，我不会直接使用SVN或其他东西来对你的网站进行版本控制。至少我从来没有听说过这样的做法。更好的方法是以某种方式每天在服务器上创建生产环境的备份副本…

我发现一些技巧对我自己的工作很有帮助：

• 我为每个项目维护一个包含所有项目相关数据的个人wiki页面。因为这只是我个人的消费，我可以根据需要有机地组织每一个

• 在整个项目过程中保留一个问题日志（在wiki页面或其他地方）。与其用随机电子邮件轰炸你的客户，或者不小心忘记及时提问，保持日志可以让你每隔几天用project rel发送一封连贯的、经过编译的电子邮件