使用“一键构建”将您的更改从开发环境转移到实时服务器是一件非常好的事情，并且经常提倡。
我加入了一个运行在LAMP堆栈中的小团队并使用SVN进行版本控制，目前部署在单个生产服务器上（另一个用于开发的服务器，很快将成为一个单独的mysql服务器）。我刚刚加入了许多在我加入之前一直缺失的组织事项。
我很想看到
我感兴趣的一些特殊挑战是处理数据库更改（架构）以及人们使用什么样的“包”来保持组织有序（例如RPM，PEAR等）。
答案 0 :(得分：7)
Hudson也可以与其他构建系统一起工作，而不仅仅是java项目。它允许您设置多个构建目标，并自动或手动运行它们。它还会强制您实现一种从单个命令运行构建的方法。
它无法解决在为部署的服务器运行构建期间服务器不可用的通信问题。
对于我们的架构更新和更改，我们设置我们的ant脚本来做两件事：
确实需要几次尝试才能做到正确，但突然间我们解决了多个开发人员处于不同模式的问题。导入转储以更新开发模式非常容易，您可以每天执行此操作。
答案 1 :(得分：2)
答案 2 :(得分：2)
我认为没有一个简单的食谱答案，因为这很大程度上取决于你的环境。无论你想出什么，我强烈推荐一种基于脚本的方法，部署脚本本身就是源代码控制。这些脚本还可以更好地与构建解决方案集成（见下文）。
在生产环境中运行的最简单的此类脚本只是从源代码管理中获取最新（或获取特定版本）的命令。
下一个挑战是数据库部署。我对大中小型项目最喜欢的解决方案是在每个数据库中维护一个模式版本表，并在源代码控制中包含所有DDL和数据更新脚本（包括它们在压缩归档中使用的数据源）。脚本是连续编号的（从000001 ...开始，000002 ...等），我运行的部署脚本只是先备份现有数据库，然后从模式版本表中获取最后一次运行数据库脚本，然后运行在源代码管理中以正确的顺序找到的任何新数据库脚本，相应地更新架构版本表。
这种方法允许我很快从头开始重建数据库。
这两种方法结合在一起，可以快速将代码库部署到几个不同的登台机，QA环境，测试版等。
对于更复杂的场景，您应该运行一个持续集成构建服务器，如Kieveli等。人。建议，它基本上“定期”重建你的整个部署，因此包含完全按照上面“手动”运行的脚本。
通过为每个数据库脚本创建回滚脚本，也可以使数据库部署更加复杂。然后你应该编写一个小控制器应用程序来处理这些。有几种OSS解决方案可以满足您的需求。
但是，请确保您永远不会将数据库自动部署到生产环境; - ）
答案 3 :(得分：2)
PHP项目的最佳构建工具可能是Phing，它与Ant非常相似，但是用PHP编写。它包含了你需要的所有必要的东西，例如从你的svn repo中抓取东西。
答案 4 :(得分：1)
“make”是你的朋友。虽然它有一个学习曲线，但它是值得的。您可以更新源代码，编译，测试等等。
答案 5 :(得分：0)
一旦你进行了一步构建，就可以轻松地将其转换为连续构建。
我们已经在中央服务器上获得了所有已完成的构建，标记了它们的构建变更编号。当一些东西被提交时（我们使用Perforce，但这适用于SVN），我们的一个构建盒上的cronjob注意到有一个比构建更新的更改，激发下载源树的http请求，并开始构建（主要是GMake）。只需几个简单的步骤即可持续构建:)
在此之后，让所有测试自动化自动运行是一个很短的步骤。每次提交后都完全构建并经过测试（可能是可部署的！）代码。
答案 6 :(得分：0)
对于脚本语言，使用ant-variant或CruiseControl变体这样的常用建议并不重要，因为您不需要编译任何东西。
让我们坚持数据库。在持续集成方面，三个重要的事情是自动化，自动化和自动化。这意味着您必须拥有从构建空数据库，从外部数据导入以及升级到新版本脚本并准备好使用某些脚本运行的所有内容。一个很好的例子可能是像MediaWiki，它让你使用PHP本身配置和安装。我建议运行构建服务器在白天部署新数据库，运行单元测试并发送电子邮件，如果有任何失败。
答案 7 :(得分：0)
我想到的方式是你想要一个脚本将所有内容拉到一起，基本上从源代码控制中获取所有文件\资源，执行所有步骤以创建最终的“产品”
在我的头脑中，这一步可能包括获取最新，编译，获取任何其他文件需要完成产品，创建安装程序（如果需要），运行单元测试，在服务器上共享输出（无论这可能意味着什么特定项目），并通知用户已创建新版本（或告诉他们是否有一个版本，以及为什么）。还有你可能需要做的其他事情。
过去我通常从某种批处理文件开始，然后创建一些自定义的构建器exe。但保持这一点总是成为一种痛苦。最后我将一个应用程序移到第三方应用程序......现在我只使用以下两种产品中的一种。