每日构建，是否现实？

Question

在一个单人商店甚至（尤其是）大型商店中，您如何在世界范围内维持日常生活？

如果更改API或数据库表等，则必须在应用程序中更改这么多层，或者说sql初始化脚本等等。

您如何期望项目能够为需要一天以上完成的更改进行构建？

确保构建能够在每次更改中发挥作用是否是一个发展目标？

（顺便说一句，我从'每日构建'中理解的是按下一个按钮并准备好生产准备代码......我感觉我有错误的选择嘿嘿）

Answer 1

每日构建不应要求您按下按钮。它应该自动发生，根据特定时间表或基于其他事件（如代码签入）触发。

将主分支中的代码置于永久可构建状态是个好主意。在它工作之前，不要将代码检查到该分支。您可以在自己的分支中处理更大的更改，也可以使用标记阻止某些应用程序的新逻辑。

您可以通过让每日构建脚本执行所有必需的设置来处理数据库架构等需求。请记住，您不需要更改生产模式，因为您不会每天部署您的构建 - 它应该只用于测试，以便您可以尽快识别回归。

Answer 2

  

在1人店甚至（特别是）   更大的商店，世界上你怎么样   保持每日建设？

你怎么能期望在没有人的情况下把事情放在一起？目标是每次签入存储库都可以生成干净的构建。如果不能，你就没有做好事。

当将大量更改放入源代码存储库时，这一点尤其重要。

  

你怎么能期望这个项目   构建需要更多的更改   一天要完成？

简单，只在存储库上构建。只将内容检查到有效的存储库中。

  

确保这是一个发展目标吗？   每个单独的建筑工程   改变？

是的，这就是目标。与大多数愿望一样，它可能不会得到满足，但以目标为基础可以很好地反馈代码库中发生的事情。

Answer 3

是的，每日构建的想法是测试您的主分支代码是否稳定，通过测试，并且随时可以发货。

如果您的修订控制系统中的更改需要多次提交，那么您应该创建一个开发分支，这样您就可以自由提交而不会破坏主分支的稳定性。

请注意，您的数据库需要为每个分支单独的测试架构。无论如何，我建议为每个测试环境建立一个单独的数据库实例，所以这应该不是问题。

完成此重构和更新测试后，您应该能够手动验证代码是否通过测试，并且您的每日构建不会中断。

然后，您可以将开发分支中的更改合并到主分支。

Answer 4

我已经使用CruiseControl来实现Continues Integration，它甚至可以创建新的构建并在每个SVN签入上部署它们，所以这个问题的答案是肯定的YES ...;）

Answer 5

我已经听过很多这样的抱怨，甚至在我的公司也是如此。这只是一种工作方式。如果你无法让你的东西随时可编辑和可测试，那么你可能会以一种不稳定的方式处理你的问题，并且会立即触及太多的代码。你是一个变戏法者。变戏法者不编程。

在我的所有项目中，我们都进行了HOURLY构建。我们使用Luntbuild来做到这一点，它会在构建失败后立即邮寄所有项目成员，并将继续邮寄，直到构建工作。破碎的代码没有被检入，当有人打破构建时，他必须为整个团队获得cookie（或其他适合的“屈辱”:-)）。

我们每周都会尝试在我们的测试服务器上安装该软件，以便我们的测试部门可以测试该软件。

您将看到这将导致更好的代码，以及项目期间几乎任何时候的可交付项目，因为：

• 您被迫以更小，更容易理解的方式分解您的工作，因此更容易编码，这将导致更少的错误。
• 您被迫经常更新和签入，这使得项目更快，因为您可以从项目早期重新使用您的同事中受益。
• 代码会更干净，因为你想能够为它编写单元测试（否则“覆盖警察”会给你）

我意识到这不是“如何保持构建工作”问题的真正答案，我认为没有真正的银弹答案。你只需要开始这样做，看看它是否适合你。我认为大部分专业程序员都认为持续集成，自动化测试和日常构建都是一件好事。

我当前的项目有两个问题，一个是由于网络问题，构建服务器没有邮件，另一个是存在太多恐慌。这意味着很快就会注意到每小时构建失败，并且因为未完成的功能而无法进行每周安装。您可以立即看到此问题对项目的反映，以及团队成员的动机。这不是“顺利”。

我希望这会有所帮助。保持绿色！ （单位测试，即）

编辑：您所指的“按下按钮”是“单步构建”。这意味着你有一个脚本可以构建你的构建（或ant，或maven，或其他），并且你使用该脚本来进行测试。因此，当您的自动构建过程工作时，您知道您有可交付的产品。您只需运行脚本并将输出发送给客户。我们的构建脚本生成一个目录结构，该结构可以一对一地复制到我们提供软件的CD上。

Answer 6

简而言之......

自动化。

不要检查它，直到它完成。

是

Answer 7

每日构建的最简单方法是在流中工作。

拥有开发流，QA（或测试）流，最后是发布流。

构建您的QA并在它们发生变化时发布流。只在您需要时才构建开发流。

现在，您可以对开发流进行重大更改，然后将它们（在源代码管理中）合并到一些更简单的操作中，您的自动构建过程就会启动。

Answer 8

如果它构建在您的计算机上，它应该在服务器上构建。问题是，当你完成任务或使用分支时，你只需要办理登机手续，这样你就不会破坏构建。

人们不一定能够在任何一天将产品放入盒子中，当然，可能有一些例程必须在发布之前完成，但是想法是任何开发人员都可以获得最新的代码在服务器中，它将在他们的机器中构建。它还用于自动化单元测试;如果代码没有编译，则无法运行它们。

几乎每个大型软件公司都使用每日构建（实际上，每天构建几个），所以是的，它是可行的并且是常见的做法。

Answer 9

在我目前的演出中，我们使用CruiseControl，Ivy repo，Ant＆amp; amp;至少每天构建我们的Java EE应用程序。 ClearCase的。我们是一个庞大的团队，能够负担得起（3个）构建团队并构建服务器。

是的，您发生的问题确实发生了，例如错误的数据库更改，错误的合并，破坏的编译和试验。但总的来说，我们不会有任何其他方式。

Answer 10

还检查这个问题：

• Best Continuous Integration Setup for a solo developer