每日构建，现实吗？
在 1 人商店甚至（尤其是）较大的商店中，您到底如何维持日常构建？
如果您更改 API 或数据库表等，您将不得不更改应用程序中的许多层，或者说 sql 初始化脚本等。
您如何期望项目能够针对需要一天以上的时间才能完成的更改进行构建完全的？
确保构建在每次更改中都能正常工作是一个开发目标吗？
（顺便说一句，我从“每日构建”中了解到的是按下一个按钮并准备好生产代码来交付......我有一种感觉我有错误的选择呵呵）
In a 1-man shop or even (especially) larger shops, how in the world can you maintain a daily build?
If you change the API, or database table etc. you will have to potentially change so many layers in the application, or say the sql initialization script etc etc.
How can you expect the project to build for changes that take more than a day to complete?
Is it a development goal to ensure the build works accross every single change?
(btw, what I understand from a 'daily build' is pressing a button and having production ready code to ship...I am having a feeling I have the wrong option hehe)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
日常构建不应该要求您按下按钮。 它应该自动发生，根据特定的时间表或基于其他事件（例如代码签入）触发。
让主分支中的代码处于永久可构建状态是个好主意。 在代码正常工作之前，不要将代码签入该分支。 您可以在自己的分支中进行更大的更改，也可以通过使用标志来阻止应用程序的一些新逻辑。
您可以通过让日常构建脚本完成所有必需的设置来处理数据库架构等需求。 请记住，您不需要更改生产模式，因为您不会每天都部署构建 - 它应该仅用于测试，以便您可以尽快识别回归。
A daily build shouldn't require you to push a button. It should happen automatically, triggered either according to a particular time schedule or based on other events such as code check-ins.
It's a good idea to have code in the main branch in a permanently build-able state. Don't check code into that branch until it works. You can work on larger changes either in your own branch or by blocking out some of your application's new logic with flags.
You can deal with requirements like database schema, etc. by having your daily build script do all of the required set-up. Remember that you don't need to alter the production schema, since you won't be deploying your build every day—it should just be used for testing so that you can identify regressions as soon as possible.
没有人，你怎么能指望将事物保持在一起呢？ 目的是每次签入存储库都可以生成干净的构建。 如果做不到，那么你就没有正确地做事。
当将大量更改放入源代码存储库时，这一点尤其重要。
很简单，只需在存储库上构建即可。 只将有效的内容签入存储库。
是的，这就是目标。 与大多数愿望一样，它可能不会得到满足，但将其作为目标可以提供有关代码库发生的情况的良好反馈。
How in the world can you expect to keep things together without one? The aim is that every checkin to the repository can generate a clean build. If it can't, you're not doing things properly.
This is especially critical when large changes are being put into the source code repository.
Easy, only build on the repository. Only check stuff into the repository that works.
Yes, that's the aim. As with most aspirations, it's probably not going to be met, but having it as the goal gives good feedback on what's happening to the code base.
是的，每日构建的想法是测试您的代码的主分支是否稳定、通过测试并随时准备发布。
如果您的修订控制系统中的更改需要多次提交，那么您应该创建一个开发分支，这样您就可以自由提交而不会破坏主分支的稳定性。
请注意，您的数据库需要为每个分支提供单独的测试架构。 无论如何，我建议为每个测试环境使用单独的数据库实例，因此这应该不是问题。
完成重构和更新测试后，您应该能够手动验证代码是否通过测试，并且您的日常构建不会中断。
然后您可以将开发分支的更改合并到主分支。
Yes, the idea of daily builds is to test that your main branch of code is stable, passes tests, and is ready to ship at all times.
If you have a change that takes more than a single commit in your revision control system, then you should create a development branch, so you can commit freely without destabilizing the main branch.
Note that your database needs a separate test schema for each branch. I recommend a separate database instance for each test environment anyway, so this shouldn't be a problem.
Once you have finished this refactoring and updated tests, you should be able to manually validate that the code passes tests, and your daily build will not break.
Then you can merge the changes from your development branch to the main branch.
我已经使用 CruiseControl 来实现持续集成，它甚至创建新的构建并将其部署在每个 SVN 签入上，所以这个问题的答案是明确的“是”...;)
I have used CruiseControl to implement Continues Integration which even creates new builds and deploys them on every SVN checkin, so the answer to that question is a definitive YES... ;)
我经常听到这样的抱怨，甚至在我的公司也是如此。这只是一种工作方式。 如果您无法始终使您的内容可编译和可测试，那么您可能会以不稳定的方式处理问题，并且一次接触太多代码。 你是个杂技演员。 杂耍者不编程。
在我的所有项目中，我们每小时构建一次。 我们使用 Luntbuild 来做到这一点，一旦构建失败，它将立即向所有项目成员发送邮件，并将继续发送邮件，直到构建成功。 损坏的代码不会被签入，当有人破坏构建时，他必须为整个团队获取cookie（或其他合适的“羞辱”:-)）。
每周我们都会尝试在测试服务器上安装软件，以便我们的测试部门可以测试软件。
您将看到，这将产生更好的代码，并且在项目期间几乎任何时候都是可交付的项目，因为：
我意识到这并不是“如何保持构建工作”问题的真正答案，我认为对此没有真正的灵丹妙药。 你只需要开始做，看看它是否适合你。 我认为大部分专业程序员都认为持续集成、自动化测试和日常构建是一件好事。
我当前的项目有两个问题，一是由于网络问题，构建服务器不发送邮件，二是恐慌太多。 这意味着每小时构建失败的情况要晚得多才能注意到，并且由于未完成的功能而无法进行每周安装。 你可以立即看到这个问题对项目的反映，以及团队成员的积极性。 只是进展并不“顺利”。
我希望这有帮助。 让它们保持绿色！ （即单元测试）
编辑：您所指的“按下按钮”是“单步构建”。 这意味着您有一个脚本可以执行您的构建（或 ant、或 maven 或其他），并且您可以使用该脚本来执行测试。 因此，当您的自动化构建流程正常运行时，您就知道您拥有了一个可交付的产品。 您只需运行脚本并将输出发送给客户。 我们的构建脚本生成一个目录结构，该目录结构被一对一地复制到我们提供软件的 CD 上。
I have heard this complaint a lot, and even at my company.It's just a way of working. If you're not capable of having your stuff compilable and testable at all times, you're probably working on your problems in an erratic way, and are touching too much code at once. You're a juggler. Jugglers don't program.
On all my projects, we do HOURLY builds. We use Luntbuild to do that, and it will mail all project members as soon as the build fails, and will keep on mailing until the build works. Broken code does not get checked in, and when somebody breaks the build, he has to get cookies for the whole team (or other fitting "humiliation" :-) ).
Each week we try to do an installation of the software on our testservers, so that our test department can test the software.
You will see that this will result in better code, and a shippable project at almost any time during the project because:
I realize that this is not a real answer to the "how do you keep the builds working" question, I think there is not a really silver bullet answer for that. You just have to start doing it and see if it works for you. I think the larger part of the professional programmers agree that continuous integration, automated testing and daily builds are a goog thing.
My current project has 2 problems, one being that the buildserver does not mail due to a network problem, and the other being that there is too much panic. This means that failin hourly builds are noticed much later, and weekly installations are not possible because of unfinished functionality. You can immediately see reflections of this problem to the project, and the motivation of team members. It's just not going "smoothly".
I hope this helps. Keep them green! (the unittests, that is)
edit: The "pressing the button" you are refering to is the "single step build". It means that you have a script which does your build (or ant, or maven, or whatever), and you use that script to do the tests aswel. So when your automated buildprocess works, you know you have a shippable product. You just run the script and send the output to the customer. Our build script produce a directory structure which gets copied 1-on-1 to the CD we deliver the software with.
简而言之......
自动化。
在完成之前不要检查它。
是的。
In short...
Automate.
Dont check it in till it's done.
Yes.
进行日常构建的最简单方法是在流中工作。
有一个开发流、一个 QA（或测试）流，最后是一个发布流。
构建您的 QA 并在流发生变化时发布流。 仅在需要时构建您的开发流。
现在，您可以对开发流进行重大更改，然后通过一些更简单的操作将它们合并（在源代码控制中），然后您的自动构建过程就会开始。
The easiest way to have daily builds is to work in streams.
Have a development stream, a QA (or test) stream and finally a release stream.
Build your QA and release streams whenever they change. Build your development stream only when you need to.
Now you can make major changes to your development stream and then merge them (in source control) in a few easier operations and your automatic build process kicks off.
如果它构建在您的计算机上，它也应该构建在服务器上。 问题是，您只需在完成任务后签入，或者使用分支，这样就不会破坏构建。
人们不一定要做到能够在任何一天将产品放入盒子中，当然，在发布之前可能必须完成一些例程，但想法是任何开发人员都可以在服务器中获取最新代码它将内置于他们的机器中。 它还用于自动化单元测试； 如果代码无法编译，则无法运行它们。
几乎每个大型软件公司都使用每日构建（实际上，一天几次构建），所以是的，这是可行的并且是常见的做法。
If it builds on your machine, it should build on the server. The thing is that you just check-in when you're done with your task, or use branches, so you don't break the build.
People don't do that necessarily to be able to put the product in a box at any day, sure, there may be routines that have to be done before release, but the idea is that any developer can get the latest code in the server and it will build in their machines. It is also used for automated unit testing; if the code does not compile, you can't run them.
Pretty much every large software company uses daily builds (actually, several builds a day), so yeah, it is doable and a common practice.
另请检查这个问题：
Check also this question:
在我目前的工作中，我们至少使用 CruiseControl、Ivy 存储库、Ant 和 Java EE 应用程序进行日常构建。 清除案例。 我们是一个大型团队，有能力组建一个（3 人）构建团队并构建服务器。
是的，您提到的问题确实会发生，例如错误的数据库更改、不正确的合并、损坏的编译和错误的编译。 测试。 但总的来说，我们不会有任何其他方式。
On my current gig, we do at least a daily build of our Java EE app using CruiseControl, an Ivy repo, Ant & ClearCase. We're a large team and able to afford a build team (of 3) and build servers.
Yes the problems you name do happen such as mistaken DB changes, incorrect merges, broken compiles & tests. But overall we would not have it any other way.