多名开发人员如何在一个force.com应用程序上高效工作？
我工作的公司正在构建一个托管的force.com 应用程序，作为与我们提供的服务的集成。
由于force.com Eclipse 插件提供的劣质工具，我们在同时处理同一组文件时遇到了问题。如果 2 个开发人员正在处理同一个文件，其中一个开发人员会收到一条无法保存的消息 - 一旦他合并，他必须手动强制插件将他的更改推送到服务器，同时单击 2“你真的确定吗”消息。
基本上，该工具在合并更改方面做得很差劲，并且如果其他人修改了他正在处理的文件，则每次开发人员想要保存时都会强制执行几分钟的工作。
我们目前正在解决这个问题，方法是让同事知道谁正在编辑文件，从而“锁定”单个文件。
感觉在这个时代必须有更好的方法。有谁知道我们可以使用不同的工具集，我们可以改变流程，或者我们可以做些什么来使这变得更容易？
The company I work for is building a managed force.com application as an integration with the service we provide.
We are having issues working concurrently on the same set of files due to the shoddy tooling that is provided with the force.com Eclipse plugin. If 2 developers are working on the same file, one is given a message that he can't save -- once he merges he has to manually force the plugin to push his changes to the server along with clicking 2 'Are you really sure' messages.
Basically, the tooling does a shoddy job of merging in changes and forces minutes of work every time the developer wants to save if another person has modified the file he's working on.
We're currently working around this by basically 'locking' individual files by letting co-workers know who is editing a file.
It feels like there has got to be a better way in this day and age. Does anyone know of a different toolset we could use, process we could change, or anything we can do to make this easier?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
查看《开发生命周期指南：Force.com 平台上的企业开发》。您可以在developer.force.com 的文档页面上找到它。
Take a look at the "Development Lifecycle Guide: Enterprise Development on the Force.com Platform". You can find it on developer.force.com's documentation page.
您可能需要考虑处理单独的静态资源和页面，然后在编辑对象、类等时要小心。如果您的大部分开发发生在客户端代码（页面、静态资源、闪电组件/应用程序）上，您可能会感兴趣该项目： https://github.com/bvellacott/salesforce-build 。无论如何，我强烈建议使用版本控制。如果不在服务器上，那么至少在您的本地计算机上，以防您的同行覆盖您的工作。
You might want to consider working on separate static resources and pages and then just being careful when editing objects, classes etc.. If most of your development happens on client side code (page, staticresource, lightning component/app) you might be interested in this project: https://github.com/bvellacott/salesforce-build . In any case I strongly suggest using version control. If not on a server then at least locally on your machine, in case your peers overwrite your work.
在使用 Force.com 平台时，我当前的组织发现根据具体情况可以采用多种不同的方法。我们都使用 Eclipse Force.com 插件，没有出现任何问题，并且发现以下设置运行良好。
我们有一个集中式版本控制系统，我们使用一系列 ant 命令将其部署到开发人员组织实例。然后，根据工作范围，我们要么将其分成多个块，每个开发人员都有自己的开发组织，合并更改并定期测试它们，要么在一个开发组织中一起工作（如果您有 2 个开发人员，则应该没有）主要问题）让您几乎可以即时集成。
如果你们都尝试处理同一个文件，那么无论如何都应该进行结对编程，但是如果一起处理类似系统的两个组件，共享同一个组织可以让您通过创建以下框架以快速灵活的方式进行开发：您希望使用的系统，然后单独充实细节。
我已经广泛使用了这两种方法，并且我说，根据具体情况，效果非常好。
When working with the Force.com platform my current organisation has found a number of different approaches can work depending on the situation. We all use the Eclipse Force.com plugin without issues and have found the following set ups to work well.
We have a centralised version control system that we deploy from using a series of ant commands to a developer org instance. We then depending on the scope of the work either separate it off into chunks with each developer having their own development org and merging the changes and testing them regularly, or working in a single development org together (which if you have 2 developers should be no major problem) allowing you to have almost instant integration.
If you are both trying to work on the same file you should be pair programming anyway, but if working on two components of a similar system together, sharing the same org can allow you to develop in a fast and flexible manner by creating the skeleton of the system you wish to use and then individually fleshing out the detail.
I have used both methods extensively and a I say, work really well depending on the situation.
每个开发人员都可以在单独的开发沙箱中工作（如果您有企业版，我认为费用中包含 10 个具有完整配置和有限数据量的沙箱？）。有时您会合并您的更改（来自任何版本控制系统的差异工具应该足够了）并在集成环境中测试它们。链条开发->集成->系统测试->问答->问题解答出于其他原因，生产也可能很有用。
例如，如果两个人使用同一个触发器，则可以使用单独的技巧来考虑。我是在面向开发人员的“DEV 401”课程中学到的。
if来测试每个选项列表值是否存在，并进入或离开对相关类的调用。这会浪费 1 个查询，但您确信只会调用您想要的代码。我发现当其他人的代码不是最优的并且消耗了太多资源时，这个技巧特别有用。我刚刚在我的用户帐户上禁用了他的功能并继续工作。
这个技巧在某种程度上也可以应用于 Visualforce 页面（如果您可以将它们划分为组件）。
如果您不想浪费查询 - 使用一些逻辑，例如“用户的名字包含 X”；）
Each developer could work in separate development sandbox (if you have enterprise edition, I think 10 sandboxes with full config & limited amount of data are included in the fee?). From time to time you would merge your changes (diff tool from any version control system should be enough) and test them in integration environment. The chain development->integration->system test->Q&A-> production can be useful for other reasons too.
Separate trick to consider can be used if for example 2 guys work on the same trigger. I've learned it on the "DEV 401" course for Developers.
ifthat tests presence of each picklist value and enters or leaves the call to relevant class. This wastes 1 query but you are sure that only the code you want will be called.I found this trick especially useful when other guy's code turned out to be non-optimal and ate too many resources. I've just disabled his feature on my user account and kept on working.
This trick can be to some extend applied to Visualforce pages too (if you can divide them into components).
If you don't want to waste query - use some logic like "user's first name contains X" ;)
我们遇到了完全相同的问题，我们有一个由 10 名开发人员组成的团队正在开发一个force.com 应用程序，该应用程序具有大量的 apex 类（> 300）和 VF 页面（> 300）。
我们开始使用 Eclipse 插件，但发现它：
解决了许多合并问题接下来，我们尝试在自己的单独沙箱中进行开发，然后合并代码。这对于小型项目来说没问题，但是当您有大量文件并且需要在沙箱之间推送更改时，就无法管理，因为唯一比force.com 开发工具更糟糕的是force.com 部署/构建工具。没有自动化，全是手动。在沙箱之间移动数据也没有简单的方法。
我们的第三种方法是在浏览器中编辑所有 VF 页面和 Apex 代码。 （不使用显示在页面下半部分的嵌入式编辑器，因为这有问题且速度慢），但仅使用 setup > 下的常规编辑器发展>顶点课程。这工作正常。为了补充这一点，我们还有一个预定的工作，它将下载我们所有的代码并将其保存到我们的 SVN 存储库中。我们还构建了一个工具，允许我们单击桌面上的文件夹并压缩其内容并将其部署为静态资源。
然而，这种方法仍然有其缺点，即在云中开发缓慢且痛苦，他们（销售人员）的“开发即服务”想法是疯狂的。此外，我们没有真正的 SCM，我们只是将其用作备份。
底线是force.com是一个CRM而不是一个开发平台，如果可以的话？跑，逃跑，尽快逃离它。将其用于除 CRM 之外的任何用途都比其价值更麻烦。甚至他们的口号“无软件”每次都让我发笑
We had/have the exact same problem, we have a team of 10 Devs working on a force.com application that has loads of apex classes (>300) and VF pages (>300).
We started using Eclipse plugin but found it:
Next we tried developing in our own individual sandboxes and then merging code. This is ok for a small project but when you have lots of files and need changes to be pushed between sandboxes it becomes impossible to manage as the only thing worse then force.com development tooling, is force.coms deployment/build tools. No automation its all manual. No easy way to move data between sandboxes either.
Our third approach was to just edit all our VF pages and Apex code in the browser. (not using their embedded editor that shows up in the bottom half of the page because that is buggy and slow) but just using the regular Editor under setup > develop > Apex classes. This worked ok. To supplement this we also had a scheduled job that would download all our code and save it into our SVN repository. We also built a tool that allow us to click a folder on our desktop and zip its contents and deploy it as static resources for us.
However this approach still has its short comings, i.e. it is slow and painful to develop in the cloud, their (salesforce) idea of Development As a Service is crazy. Also we have no real SCM we only have it acting as backups.
Bottom line is force.com is a CRM and not a Development platform, if you can? run, flee, get away from it as fast as you can. Using it for anything apart from a CRM is more trouble then it is worth. Even their Slogan "No Software" makes me laugh everytime
我不熟悉force.com，但是您不能使用源代码管理并将所有文件从force.com 拉入您的存储库吗？然后你们就可以完成你们的工作，并将你们的更改合并回主线。那么什么时候需要将主线推到force.com呢？
I'm not familiar with force.com, but couldn't you use source control and pull all the files down from force.com into your repository. Then you could all do your work, and merge your changes back into the mainline. Then whenever it's necessary push the mainline up to force.com?