您如何在团队中分发 IDE 及其配置？
我想知道软件开发团队如何分发他们的标准 IDE？
例如，使用 Eclipse 进行开发、自定义代码格式化程序、svn Resository、版权标头.. 目前，我的团队有一个标准的 zip 文件，然后将其分发给开发人员。
问题： 如果一个文件、一个插件或 IDE 本身发生变化，例如新的编码指南、升级 Eclipse 3.5.1，则整个分发必须重新进行。每个开发人员都需要再次解压捆绑包。想象一下，由于项目历史记录，您使用不同的工作空间（Jetty、不同的 Tomcamt 版本、WTP）无法扩展，
我知道有一些相关的文章
和一些商业程序管理您的 Eclipse 安装。 Eclipse 还有一个新的 Update-Installer 方法
但我没有看到杀手级应用程序。您的团队如何解决这个问题？ 有最佳实践吗？ 我想最好是一个程序让您选择当前的项目，然后从服务器下载配置的 IDE，并让您知道项目配置文件是否已更新
I'm wondering how Software Development Team distribute their Standard IDE(s)?
E.g. developing with Eclipse, custom Code formatter, svn Resository, Copyright Header..
At the moment my Team has a standard zip File which is then distributed withhin the developers.
Problem:
If one file, a Plugin or the IDE itself changes, e.g. new Coding Guidlines, Upgrade Eclipse 3.5.1 the whole distribution has to be done again. Every developer needs to unzip the bundel again. Imagine your working with different Workspaces (Jetty, different Tomcamt Versions, WTP) due to Project History That doesn't scale
I know that there are some related Articels
- A new version of Eclipse just came out. Is there anything I can do to avoid having to manually hunt down my plugins again?
- Manage Your Eclipse Install With A Local Git Repository
And some comercial Programs.
Eclipse also has a new Update-Installer Approach
But I don't see the Killer App. How do your team solve this? Is there a best practice?
I guess best would be a Program letting you choose your current Project and then downloads the configured IDE from the Server and leting you know if Project Config Files are Updated
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对于 Eclipse，请查看 Buckminster 它完全针对您的目标，我想，个人并没有使用它。
For eclipse look at Buckminster it targets exactly your target I suppose, didn't use it personally through.
在我以前的公司，他们编写了一个自定义更新代理，该代理从集中配置的服务器中提取，该服务器由团队负责人更新。它运行良好，直到人们想要安装自己的插件。
基本上，开发人员想要一个插件，徒劳地试图将其包含在默认（托管）存储库中，自己安装它，然后当团队负责人突然灵机一动并包含它时，更新在他的机器上崩溃了。
他们从来没有想出一个“好”的方法来管理它。但是，至少他们没有把我们全部放在带有瘦客户端的终端服务器上。
At my previous company they wrote a custom update agent that pulled from a centrally configured server which was updated by the team leaders. It worked well, until people wanted to install their own plugins.
Basically, a developer wanted a plugin, fought in futility to get it included in the default (managed) repo, installed it himself, then updates broke on his machine when the team lead had a sudden stroke of common sense and included it.
They never did come up with a 'good' way to manage it. But, at least they didn't put us all on terminal servers with thin clients.