如何将您的办公室转变为构建自动化？
标题应该说明一切，然后我可以在 Joel 测试中再确认 2 个刻度。
我已经使用 makefile 和 python 脚本实现了构建自动化，并且我了解基础知识和选项。
但我，作为一个新读博客的人，如何才能让我的同伴相信其固有的功效呢？
The title should say it all, then I can solidify 2 more ticks on the Joel test.
I've implemented build automation using a makefile and a python script already and I understand the basics and the options.
But how can I, the new guy who reads the blogs, convince my cohort of its inherent efficacy?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
请求原谅，而不是许可。
让它私下工作（看起来你已经做到了），然后展示它的优势。
总是让人们感兴趣的一件事是使用 CruiseControl 的托盘实用程序 - 当人们可以通过系统托盘看到构建成功时，他们会喜欢它。 （假设您处于 Windows 环境中，CruiseControl 将与您现有的系统配合使用等。）
注意：如果请求宽恕而不是许可将导致立即终止，您可能不想执行上述操作。 您可能还想在其他地方寻找工作。 你的旅费可能会改变。
Ask for forgiveness, instead of permission.
Get it working in private (which it looks like you have) and then demonstrate its advantages.
One thing that always gets people is using CruiseControl's Tray utility - people love it when they can see, through their system tray, that the build succeeded. (this is assuming you're in a Windows environment, that CruiseControl will work with your existing systems, etc.)
NOTE: If asking for forgiveness instead of permission will result in instant termination, you might not want to do the above. You might also want to look for work somewhere else. Your mileage may vary.
实施构建灯光 ...我们对熔岩做了类似的事情灯，它引起了巨大的轰动。 为了获得额外的奖励分数，请在每个开发人员的办公桌上放置一盏红灯，并在构建中断时亮起正确的灯。
Implement build lights ... we did something similar with lava lamps and it was a huge hit. For added bonus marks give every developer a red light over their desk and have the right light come on when the build breaks.
拿起一台旧的备用电脑& 把它放在你办公室的角落里。 设置它来构建您的项目。 编写一个小脚本，其功能是：
当你休息时，富有同情心地把它修好。
还可以考虑添加一个步骤来运行单元测试。
如果您能够避免责骂人们的错误，很快人们就会对您到达以来构建的可靠性留下深刻的印象。 从那里开始构建。
诀窍是花很少的时间为你的团队创造大量价值，而不惹恼任何人。
Grab an old spare computer & put it in the corner of your office. Set it up to build your project. Write a small script that does:
When you catch a break, compassionately get it fixed.
Consider adding a step to run unit tests, too.
If you can avoid scolding people for their mistakes, pretty soon people will be impressed with how reliable the build has been since you arrived. Build from there.
The trick is to spend very little of your time to generate a lot of value for your team, without pissing anyone off.
设立一个汽车制造商。 一旦你让它自动构建和运行测试，即使你说服其他人节省自己的时间也没关系:)
如果你使用 git 进行版本控制，这里有一个自动构建器，它可以自动找到开始导致问题的确切签入失败的测试： http://github.com/apenwarr/gitbuilder/
Set up an autobuilder. Once you have it building and running the tests automatically, it won't matter if you convince other people to save their own time :)
If you're using git for version control, here's an autobuilder that automatically finds the exact checkin that started causing the tests to fail: http://github.com/apenwarr/gitbuilder/
我会拿一个备用盒子，安装一个持续集成服务器（Hudson 或 CruiseControl（在 Java 世界中））并设置一个作业，每次有人签入某些代码时都会构建您的应用程序。
您可以尝试说服您的同事，或者只是等待有人破坏构建。 在后一种情况下，只需发送以下电子邮件：
通常不需要很长时间，每个人都会出现在列表中
I would take a spare box, install a continuous integration server (Hudson or CruiseControl in the Java world) and set up a job that builds your application each time someone checks in some code.
You can either try to convince your coworker or just wait until someone breaks the build. In the latter case, just send the following email:
Usually it doesn't take that long until everyone is on the list
我会将自动构建设置为每晚的过程，以便每天晚上它都会获取最新的代码修订，构建它并生成报告。 现在，您每天早上第一件事都会知道构建是否被破坏，如果是，您可以通知团队。 如果损坏的构建对您的项目来说是一个很大的问题，那么人们可能会首先开始来找您，以了解同步到最新代码是否安全，因为您将是那个在任何一天都倾向于知道是否或构建并没有被破坏（顺便说一句，自动化的单元测试套件也有助于解决这个问题）。 如果幸运的话，人们将开始意识到您的夜间构建是一件有用的事情，并且您将能够将每日构建报告设置为发送的电子邮件。
I would set up the automated build as a nightly process such that every night it grabs the most recent code revision, builds it, and generates a report. Now you will know first thing every morning whether or not the build is broken, and if it is, you can notify the team. If broken builds are much of a problem on your project, people will probably start coming to you first to find out if it is safe to sync to the latest code, since you will be the person who tends to know on any given day whether or not the build is broken (by the way, an automated suite of unit tests helps a great deal with this as well). With any luck, people will start to realize that your nightly build is a useful thing to have, and you'll be able to just set up your daily build report as an email that goes out.
James Shora 有两个重要的链接：
对于硬件
http://jamesshore.com/Blog/Continously- Integration-on-a-Dollar-a-Day.html
对于“Humanware”
http://jamesshore.com/Change-Diary/
（他是如何做到这一点的历史。读起来很长，但改变组织更困难）
James Shora has two great links:
For hardware
http://jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html
For "Humanware"
http://jamesshore.com/Change-Diary/
( The history of how he did it. The read is long but changing an organization is harder )
当团队需要定期进行构建时，这非常容易。 您指定一名团队成员（定期轮换）来进行构建。 如果构建过程足够复杂，团队将自行想出一种至少部分自动化构建的方法。 在最坏的情况下，您必须自己自动化构建，但没有人会反对自动化。
When the build is needed by the team on a regular basis, it's pretty easy. You appoint a team member (rotated periodically) to do the build. If the build process is complicated enough, the team will on its own come up with a way of at least partially automating the build. In the worst case, you'll have to automate the build yourself, but no-one will be against the automation.
示范是最好的，也是改变那些拒绝以不同方式做事的人的想法的唯一方法。
在这里，我们展示了自动化构建的有用性，让 QA 能够直接从构建服务器获取绿灯构建并安装它并进行测试，而无需开发人员的任何指导。 他们能够继续工作，他们知道它至少通过了单元测试。 它有助于集成测试和开发，减少系统中出现错误的时间。
Demonstration is the best, and really the only way to change anyone's mind who is resistant to doing things differently.
Here we showed how useful automated builds are by having the ability for QA to grab a green light build straight from the build server and install it and test without any direction from the developers. They are able to continue working, they know that it at least passes it's unit tests. It helped integrate testing and development reducing time bugs were in the system.