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

Question

我意识到“好的做法”这个词有点可疑和过度使用，但我认为这适用于我的问题。

我有一些良好的网络开发经验，但我想听听在为项目管理做自由职业时有哪些好的基本做法。

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

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

我已经设置了两个数据库，mydb _ dev和mydb _ rel。在_dev上完成我的所有工作然后将结构转移到_rel是否有意义？第一次发布后会发生什么？

如果您可以回答其中一些问题或将我链接到一个好的资源，那就太好了。到目前为止，我的搜索只产生了HTML教程！

Answer 1

我通常建议的是以下内容。团队应该有3种“部署”环境：

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

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

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

Answer 2

我们做什么。

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

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

3. 我们使用部署非常整洁的产品。使用WAR或EAR文件部署Glassfish / Java应用程序。 Django应用程序使用Python的setup.py安装程序。这样我们就可以安装到生产环境中，摆弄数据库，我们就可以运行了。我们使用配置文件来确保我们使用数据库，目录等的“生产”名称。

第一个版本涉及第一次构建数据库。我们提供了一个脚本（或者在Django的情况下，我们运行manage.py syncdb命令）来构建数据库。

进行架构更改时，我们要么有脚本或说明。我们必须在测试中再次进行生产。

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

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

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

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

Answer 3

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

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

• 在整个项目过程中出现问题日志（在维基页面或其他地方）。不是通过随机电子邮件轰炸您的客户或意外忘记及时提问，保留日志将让您每隔几天发送一个连贯的编译电子邮件，与项目相关的问题。

• 在本地进行所有开发（MAMP，XAMPP等）。通过这种方式，您的客户永远不会访问网站，因此可以避免不必要的混淆（为什么我现在得到空白屏幕？！？他们在5分钟前工作!!）。< / p>

• 通过Capistrano从本地开发推送到您的登台服务器。这可以再次进行生产。更容易跟踪任何构建脚本（例如，迷你JS）并且比FTP更有效

• 使用SVN管理所有资产 - 内容，模板，组合，工作站点，数据库导出等。如果您从一开始就设置好组织，那么组织良好的回购将不会失控。永远不会伤害额外的备份，即使您知道再也不会再触摸文件了。

Answer 4

至于版本控制，我会说把一切都置于非动态创建的控制之下。例如，如果您的应用程序动态生成一堆.txt文件，则不需要对这些文件进行版本化，但只需创建一次的任何文件，都需要受版本控制。

至于你选择的版本控制系统，我推荐的不是SVN（可能是Git或Mercurial），但这更多只是我个人的偏好，而不是任何实质性的原因。