远程Java编译器 [英] Remote Java compiler

问题描述

我正在寻找一种提高团队效率的方法，其中一种方法是缩短编译时间。单元测试&包装&部署我们的Java EE应用程序越来越大。

I'm looking for a way to boost my team's productivity, and one way to do that would be to shorten the time it takes to compile & unit test & package & deploy our Java EE application which is getting bigger and bigger.

我所知道的简单解决方案是设置一台功能强大的N台处理器（N~ = num of开发人员）和一个超快速的磁盘系统和大量内存，并在这台计算机上运行所有内容并通过X远程连接到它。它肯定比编译我们的笔记本电脑快得多，但仍然比购买每个开发人员他/她自己的超级计算机更便宜和更容易维护。

The trivial solution that I know of is to set up a powerful computer with N processors (N ~= num of developers) and a blazingly fast disk system and a lot of memory, and run everything on this computer and connect to it via X remotely. It would certainly be much faster than compiling on our laptops, but still cheaper and easier to maintain than to buy each developer his/her own supercomputer.

还有另一种方式解决这个问题？例如，我们可以在本地运行我们的IDE然后告诉它远程编译java源代码吗？ Netbeans / Eclipse / IntelliJ /等可以这样做吗？或者是否有一个特殊的工具可以实现远程Java编译，也可以使用多个处理器？它不一定是免费/开源的。

Is there another way to solve this problem? For example, could we run our IDEs locally and then tell it to remote compile java source? Can Netbeans / Eclipse / IntelliJ / etc. do this? Or is there a special tool that enables remote java compilation, also that makes use of multiple processors? It need not be free/open source.

不幸的是我们的笔记本电脑必须运行一个（公司管理的）Windows Vista，所以去另一台服务器计算机的另一个原因是让我们在它上面使用linux并最终摆脱它令人讨厌的托管环境。

Unfortunately our laptops MUST run a (company managed) Windows Vista, so another reason to go for the separate server computer is to let us use linux on it and finally get rid of the annoying managed environment.

编辑：总结答案到目前为止，缩短构建时间的一种方法是保留编译单独的开发人员（因为编译应该是快速的），跳过运行单元测试和热部署（没有打包）到容器。

to sum up the answers so far, one way to shorten build times is to leave compilation for the developers individually (because compiling is supposed to be fast), skip running unit tests and hot-deploy (without packaging) to the container.

然后，当开发人员决定检查他/她的代码，连续集成服务器（如Hudson）被触发清理&构建和运行测试&包装&部署。

Then, when the developer decides to check his/her code in, a continuous integration server (such as Hudson) is triggered to clean & build & run tests & package & deploy.

解决方案：我接受了Thorbjørn的回答，因为我认为这将是我最接近我计划进行的方式。虽然出于好奇，我仍然有兴趣解决原始问题（=远程Java编译）......

SOLUTION: I've accepted Thorbjørn's answer since I think that's going to be the closest to which way I'm planning to proceed. Although out of curiosity I'm still interested in solving the original problem (=remote Java compiling)...

推荐答案

你本质上需要两个工作流程。

You essentially need two workflows.

1. OFFICIAL 构建，它​​会检查来源，从头开始构建整个事件，运行所有单元测试，然后构建最终将在测试后发送给客户的位。


2. 开发人员热部署后，每个源代码更改为IDE知道的容器。

1. The OFFICIAL build, which checks out the sources, builds the whole thing from scratch, runs all the unit tests, and then builds the bits which will eventually ship to the customer after testing.
2. Developer hot-deploying after each source code change into the container the IDE knows about.

这两个实际上可能大不相同！

These two can actually be vastly different!

正式版，启动并运行 Jenkins 并告诉它观察您的源存储库并在存在时构建改变（告诉那些破坏构建的人）。如果您可以使用大型计算机进行构建，请将其用于此目的。

For the official build, get Jenkins up and running and tell it to watch your source repository and build whenever there is a change (and tell those who break the build). If you can get the big computer for building, use it for this purpose.

对于开发人员，请查看具有非常好的IDE部署选项的合适容器，并将其设置为为每个开发人员使用。这将很快得到回报！ JBoss以前非常适合这个目的。

For the developers, look into a suitable container with very good IDE deployment options, and set that up for usage for each and every developer. This will VERY rapidly pay off! JBoss was previously very good for exactly this purpose.

而且，不，我不知道有效的远程java编译选项，我不认为这是你应该为开发者追求什么。

And, no, I don't know of an efficient remote java compilation options, and I don't think this is what you should pursue for the developers.

看看Joel对构建服务器的看法： http://www.joelonsoftware.com/articles/fog0000000023.html

See what Joel thinks about Build Servers: http://www.joelonsoftware.com/articles/fog0000000023.html

如果你不喜欢詹金斯，还有很多其他人存在。

If you don't like Jenkins, plenty others exist.

（2016编辑：Hudson改为Jenkins。请参阅 https：// stackoverflow .com / a / 4974032/53897 关于名称变更背后的历史记录）

(2016 edit: Hudson changed to Jenkins. See https://stackoverflow.com/a/4974032/53897 for the history behind the name change)

这篇关于远程Java编译器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！