Web应用程序：开发到生产

Question

以下是我公司将更改从开发服务器移至生产服务器的当前流程：

1. 需要更新的文件从生产中删除，以确保不会在生产中进行任何更改（不应该发生;但是，确实会发生）。旧的开发文件被赋予一个〜前缀作为一种“备份”。
2. 开发人员进行必要的更改。
3. 正在开发的更新文件将从该服务器复制并粘贴到生产服务器上的相应位置。旧的生产文件被赋予一个〜前缀作为一种“备份”。

我知道这是一种可怕的做事方式，但最好的办法是什么？我最初的想法是将所有代码都转换为颠覆。然后，当需要更新某些内容时，在开发中进行更改，提交到存储库，然后从存储库更新生产服务器。

任何人都有任何替代/改动/建设性批评？我们的开发团队只有6个人，我们的代码库是ASP（非常古老，可怕的遗产），PHP（稍微更新）和Java EE（最新代码;所有应用程序都构建为单独的WAR）。

提前致谢

编辑：为了开发我们的Java EE应用程序，每个开发人员都在他的机器上运行Glassfish v2。对于PHP / ASP，我们有一个中央开发服务器。对于生产，我们有一个用于PHP / ASP（IIS）的服务器，另一个用于Java（Glassfish v2）。

Answer 1

如前所述，源代码控制是明确的。它是所有编码和部署都应该发生的工具。

话虽如此，您可能还希望使用Capistrano之类的部署工具或Phing之类的构建工具。

我使用Capistrano部署我们的PHP应用程序，并使用单个终端命令：

1. 从源代码管理
查看项目副本
2. 放入版本化部署文件夹
3. 运行自定义任务 - 例如将符号链接写入公用文件夹，运行数据库任务，将环境变量从暂存切换到生产等等。
4. 在我的应用的公共文件夹和服务器doc根
之间创建符号链接

如果出现任何问题，它将自动回滚到上一次良好的部署。这是一个非常有用的工具。不能推荐它。

编辑：刚刚意识到这不是一个只有PHP的问题。根据您的平台，部署工具会有所不同。 Capistrano适用于Rails或PHP。 Phing是Apache Ant的PHP版本。您可能想询问所选平台的最佳工具。

Answer 2

你是对的，使用源代码管理（颠覆，git，mercurial等）会让你的生活更轻松。

以下是更改生产环境时需要采取的基本步骤：

1. 开发人员在项目主干中的分支中进行更改
2. 完成所有更改并通过测试后，将更改合并回主干
3. 制作主干的标签
4. 将该标记导出到您的生产环境中。如果出现问题，您可以随时恢复以前部署的标记。

Answer 3

是的....肯定需要某种源代码控制。就个人而言，我喜欢SVN并觉得它很容易设置。

在您深入了解之前，我会考虑您的部署策略应该如何运作。您想如何处理并发开发？您是否需要/需要部署到的QA或用户测试环境？与你的小组其他成员坐下来，提出一个用例列表，以确保你在同一个页面上，你的策略适合，并且你们都在使用该解决方案。

Answer 4

我会说你的思路正确。获得源代码控制，颠覆或其他方面至关重要。然后使用某种持续集成（如CruiseControl）来管理直接部署或创建部署包。并尽一切可能确保生产中不会发生任何变化，这确实会给整个过程带来麻烦。

Answer 5

正如你所说，在您的情况下，颠覆可能会有所帮助：使用某些版本控制系统很好，并且颠覆工作正常 - 您可能不需要任何分散系统< em>（比如git / mercurial /...)。

主要优点是：

• 更容易分享团队中每个开发者所做的修改
• 一个中心位置“ <源代码的官方版本
• 可能更容易部署。

虽然，我不会在我的生产服务器上使用svn checkout：好吧，它在某些情况下可以正常工作，但是，特别是如果你有时直接在生产服务器上修改文件（你肯定不应该这样做） ！），你最终会在生产服务器上遇到麻烦（比如冲突） ...

是的，你可以在干运行中使用svn merge，但它并不总是足够......并且svn更新没有干运行 - 而且PHP文件中的冲突通常意味着解析错误;当它在生产服务器上发生时很糟糕^^

相反，我会：

• 正常工作，在可以这样做的时候提交SVN
• 偶尔（例如，部署到生产的前一天），执行svn导出并将解压缩的应用程序部署到登台服务器
  • 表示您可以在比开发平台更接近生产的环境上进行测试
  • 并且还意味着没有任何东西应该直接投入生产，而不需要在登台环境中进行测试！
• 如果登台服务器上的一切正常，则将相同的软件包部署到生产服务器。

哦，顺便说一下，关于部署过程，你可能会对我前一段时间给出的答案感兴趣：Updating a web app without any downtime

作为旁注：开始使用这种过程并不总是那么容易，所以：

• 在开始之前尽可能多地思考;发布SO是一个良好的开端，但不要忘记与将使用该系统的同事讨论！
• 花点时间：可能没有匆忙，而且几天的思考总是有用的;-)
  • 即。考虑一下您可能遇到的情况以及您的使用案例，以确保您实施的流程能够为您服务。

Answer 6

Capistrano是一个很棒的工具，但我觉得它对非Rails项目来说太过分了。这是从存储库将PHP项目部署到多个环境的良好指南：http://themetricsystem.rjmetrics.com/2010/02/01/simple-deploy-script-for-php-applications/