改进Java开发工作流

Question

我想帮助我的团队标准化到一个可再生的Java工具环境，这个环境与一些良好的实践相一致，以改进我们的工作流程。我们主要是一个.NET商店，最近做了相当多的Java开发，并且在当前的Java开发过程中被烧了太多次。

这个过程是临时性的，因为我们对Java的所有东西都是新的。每个开发人员都决定选择他们的工具(这在某种程度上是件好事)，并且由于在第三方依赖管理方面缺乏任何类型的过程，我们经常会遇到构建或部署问题，并且在开发人员机器由于某种原因不得不重建时遇到严重的挫折。我们的Java开发环境在一台机器到另一台机器之间既不一致也不能重复。

我们的.NET项目没有类似的问题。每个人都运行相同版本的Visual、Resharper以及所有第三方和开源库。可能是因为我们支付了大部分的费用，但是在我们的C#项目中也有一个一致的模式，一个人所需要的一切都封装到解决方案文件中，并且这个解决方案所需的所有第三方all都被签入子目录中，这个子目录相对于源代码管理中的父解决方案。Visual在版本检查方面也有所帮助，但这个过程运行良好，我认为它可以复制到我们的Java开发工作中。

为了帮助实现这一目标，我汇编了以下问题清单，以衡量专家们在那里使用的是什么。

1. 您使用什么Java开发IDE？日食，NetBeans还是IntelliJ？
2. 您是使用依赖关系管理工具，比如Apache、Gradle，一个标准化的本地解决方案，还是每个开发人员都决定什么最适合他们？我们所拥有的
3. 如果对2的回答是肯定的，那么如何将这些工具与您的构建系统集成？
4. 您是否对特定版本的IDE、相关工具和运行时进行标准化？例如，所有devs是否都在为Java开发人员运行Eclipse 3.7、IntelliJ 12.1.6、JDK1.7或1.8，是否有任何策略强制所有devs使用相同的版本？
5. 如何确保项目设置在开发计算机上是一致的和可重复的？您是否要求将所有项目设置都签入源代码管理或仅将相应的源文件签入？
6. 对于每个工具，包括IDE、依赖关系管理和构建，您使用了什么选择过程？

以粗体突出显示的项目是我们根据过去的经验正在学习的。但是，从别人正在做的事情中学习是很好的。

首先，我将回答一些问题，列出我们面临的一些问题：

1. 每个开发人员都使用Eclipse。但是，Eclipse和JDK版本可能因机器而异。Dev A可以使用JDK 1.6运行Eclipse，而Dev则使用JDK1.7运行Eclipse伽利略。构建机器可能正在运行一些不同的东西，我们只有在第二天早上构建失败时才会知道有一个问题。WIth资源也分布在各大洲，这会引起严重的头痛。对于IDE标准化，我倾向于IntelliJ的可用性和一致性，仅举几个例子。
2. 我们不使用任何这样的工具。相反，所有第三方库都存储在解决方案树外的一个3 3rdParty中央文件夹中。然后我们有一个Eclipse项目设置来引用这些JAR。这很好，但是这个3 3rdparty文件夹非常大。因此，如果您不想有选择地签出您只需要获得该项目编译所需的JAR，那么您将在漫长的早晨等待从SVN签出整个3 3rdParty文件夹。对于依赖关系管理，我倾向于Maven。
3. 我们使用原始的蚂蚁脚本。每个开发人员都需要确保将构建项目所需的所有内容都签入源代码管理。但是由于这些资源到处都是，记住，第三方文件夹不是项目树的一部分，所以很容易忘记从某个地方下载的新依赖JAR。如果您像我一样使用Maven，我需要将JAR从本地Maven repo复制到相关的centrll 3 3rdParty文件夹，这样构建机器就不会抱怨。但是，由于构建环境也可能有所不同，此构建失败的可能性仍然很大。对于构建和打包，我也倾向于使用Maven来确保构建环境类似于dev环境。我想减轻必须记住将依赖项放在哪里的痛苦。
4. 不是的。见答案1。
5. 我们没有这样做，可能是因为我们没有将整个Eclipse工作区保存到源代码管理中。因此，如果我收到一台新机器并签出一个Eclipse项目，我将不得不在一天的大部分时间里配置本应保存在源代码管理中的项目设置。所有的评论。

编辑:只是为了增加我们有一个CI服务器，并使用Jenkins/ANT脚本来构建。

克劳斯

Answer 1

我觉得你做错了。你要去一个不可维护的意大利面环境。

Java项目往往会增长到数十个或多个依赖项。你从番石榴，JodaTime，SLF4J开始.这也没什么。只是不要试图手动维护它。Maven/Gradle是必须的！

永远不要提交Eclipse工作区文件。只是不管用。

让我们从头开始吧。

1. 设置CI服务器。一个独立的工具，它将从存储库中提取代码，构建代码，运行测试，并在构建失败时发送电子邮件。詹金斯是个很简单的工具。
2. 你肯定需要Maven或Gradle。(你可以试试Ant+Ivy，但我不能那样做)。大多数IDE与Maven集成得非常好和透明。
3. 拥有相同版本的JDK1.7是件好事。但是，您可以在Maven中设置源和目标版本。
4. 不要试图强迫任何人使用任何IDE。这不重要。

如果我是在回答你的问题：

1. 不重要。让任何人选择一个他/她知道的关键捷径和最有效率的。
2. 马文！或者Gradle，但是Maven有更好的IDE集成。
3. 这是一个构建系统。将IDE与它集成在一起，它就能工作了。
4. 不重要。
5. 您所需要的只是源代码和pom.xml (如果是Maven)。没有其他文件。您只需选择自己选择的IDE并导入/打开Maven项目。
6. 依赖关系管理/构建系统您需要任意选择。Maven更容易，并且具有更好的集成。Gradle可能需要一些工作，但它更易于扩展。蚂蚁是一条痛苦之路。让每个人都选择。

我们刚刚完成了将Ant+Eclipse-commited-workspace+3rd-paarty-libs-in-SVN项目迁移到Maven项目.

Answer 2

1:我使用IntelliJ (作为以前的JetBrains雇员，我有偏见)；其他人使用IntelliJ或Eclipse。我试图使用Eclipse，但非常不喜欢它。

目前，我们使用的是一个自定义的封闭源代码工具。在此之前，我们都使用了IDEA，并使用了它的依赖控制。另一组用了Maven。

3:目前，IDEA和Eclipse都有定制的构建插件，但我还是更喜欢命令行。(在Linux环境中，命令行是一个很友好的地方。)

4:没有标准化，因为IDEA似乎很好地处理来自其他版本的项目文件，只要版本没有太大的差异。不确定Eclipse的情况。

4:当我们标准化IDEA时，我们将项目文件签入VCS。现在我们没有，而是将自定义工具的构建文件保存在VCS中。

5:开发人员有他们自己对IDE的偏好(除非他们开发了非常好的IDE，否则选择是显而易见的)。我用社区版的想法。

Answer 3

R1。我们使用Eclipse或其他什么，包括IntelliJ

Eclipse提供了“一流”支持:我们确保在开发环境中所做的任何更改都不会破坏任何人，并确保开发人员的体验尽可能顺畅。它也是用于培训的IDE。

也就是说，人们可以使用他们喜欢的任何环境，而且我们有大量的人使用IntelliJ。协议是，他们仍然应该遵守所有基于Eclipse的需求(例如代码格式化约定、警告设置等)--并且应该由他们来解决。

我们有一个Eclipse的“推荐”版本，但是您可以使用其他的东西--您只是属于“任何”类别。

R2。我们用maven。

maven命令行构建实际上是引用。如果在命令行中不工作，那么Eclipse中的某些东西是否工作并不重要。

Eclipse与maven都有很好的集成，因此确保maven项目顺利和正确地打开所需的额外工作是最少的。

R3。我们的构建系统基于Jenkins，因此相当于命令行构建(这是参考)。

R4。CI服务器始终是引用:您在本地使用什么并不那么重要，除非您破坏了构建(或测试)，然后它可能意味着您有足够的分歧，这很重要。把它修好。

R5。我们通常使用源代码管理eclipse .project、.classpath和.settings。

虽然理论上它并不是严格要求的，而且可以生成，但是检查它们可以确保开发人员之间的一致性。它还为复杂的设置提供了便利，在这些设置中，m2e或maven-eclipse插件不太可靠，或者，为了顺利运行，IDE需要的信息略多于pom中可用的信息。(它还使导入项目的开发体验更加顺畅)。

R6。无论当时人们喜欢什么(或者认为是好的)。