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

Question

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

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

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

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

我已经设置了两个数据库，mydb_dev和mydb_rel。把我在_dev上做的所有工作都转移到_rel上，这样做有意义吗？在第一个版本之后会发生什么？

如果你能回答其中的一些问题，或者把我链接到一个好的资源，那就太好了。到目前为止，我的搜索只得到了HTML教程！

Answer 1

我通常会提出以下建议。团队应该有3种“部署”环境：

• 开发环境:这是开发人员工作的地方，也是发布
• 测试环境的地方:这是进行测试的地方，也可能向客户展示。只有工作产品才能部署到here.
• production环境中:运行和使用的产品

的最终部署

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

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

Answer 2

我们要做什么。

1. 使用允许在已部署的web服务器外部进行测试的框架。我们在笔记本电脑上进行开发和测试。有些人使用运行在Eclipse下的Glassfish进行测试。其他人使用独立运行的Django。我们的笔记本电脑上有用于开发和测试的数据库。我们使用配置文件来确保我们使用的是数据库、目录等的“开发”名称。
2. 在虚拟机上进行集成测试。我们的主机是基于Red Hat Enterprise Linux的，所以我们有Fedora VM，用于测试Apache和MySQL (或Oracle)以及整个技术堆栈。我们在VM环境中有集成测试数据库。我们使用配置文件来确保我们使用的是数据库、目录等的“测试”名称。
3. 我们使用部署非常整洁的产品。Glassfish/Java应用程序使用WAR或EAR文件进行部署。Django应用程序使用Python的setup.py安装程序。这样我们就可以安装到生产环境中，摆弄数据库，然后我们就可以正常运行了。我们使用配置文件来确保我们使用的是数据库、目录等的“生产”名称。

第一个版本涉及到第一次构建数据库。我们提供一个脚本(或者对于Django，我们运行manage.py syncdb命令)来构建数据库。

当进行模式更改时，我们要么有脚本，要么有指令。我们必须在测试和生产中再做一次。

当部署到对世界可见的生产时，我们这样做。

1. 我们的托管环境中有一个虚拟机，它是“暂存”的。我们就能让它工作起来。它在互联网上是不可见的。我们签出组件，安装它们，运行DB模式更改脚本(如果它很复杂，也可以执行手动步骤)。通常，我们处理生产数据库的拷贝。
2. 然后克隆该虚拟机以创建生产虚拟机。我们将生产配置更改为使用生产数据库的升级副本。

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

Answer 3

我在自己的工作中发现了一些有用的技巧：

• I为每个项目维护一个包含所有项目相关数据的个人维基页面。由于这只是我的个人消费，我可以根据需要有机地组织每个问题。
• 在整个项目过程中都会出现一个问题日志(在维基页面或其他地方)。保留日志可以让您每隔几天发送一封连贯且经过编译的电子邮件，其中包含与项目相关的问题，而不是用随机的电子邮件轰炸您的客户或意外忘记及时提出问题。
• 在本地完成所有开发工作(MAMP、XAMPP等)。这样的话，当你在网站上工作的时候，你的客户永远不会访问它，因此绕过了不必要的混乱(为什么我现在得到了空白屏幕？！？他们5分钟前还在工作！！)。
• 通过Capistrano从本地开发推送到您的临时服务器。对于生产，可以再次这样做。更容易跟踪任何构建脚本(例如，小型JS )，并且比FTP
• 更有效。使用SVN管理所有资产-内容、模板、比较、工作站点、数据库导出等。有一个额外的备份永远不会有坏处，即使你知道你再也不会去访问一个文件了。