-1

我目前的雇主使用第三方托管的 CRM 提供商，我们在两个系统之间有一个相当复杂的集成层。CRM 提供商的功能之一是让开发人员以类似 Java 的语言编写业务逻辑，并在用户单击按钮或向系统提交新帐户等事件时触发验证和/或业务逻辑。

我们使用的一项功能是让在托管提供商上运行的业务代码调用我们托管的 Web 服务。典型的例子是销售代表输入一个新的销售线索并点击一个按钮来 ping 我们的系统，看看我们是否可以根据电子邮件地址、公司/名字/姓氏等识别新的销售线索，如果可以，返回代表该个人的内部 GUID。这一切对我们来说都很好，但是我们一次又一次地试图建立一个理智的开发环境来工作。

因此，虽然我们的用例有点细微差别，但这通常适用于任何构建 API 以供第三方使用的开发公司： 当您构建供外部使用的 API 时，设计开发管道和环境时有哪些最佳实践世界？

在我们的办公室，我们所有的开发人员都在防火墙后面，因此正在进行的代码不会受到外部世界的影响，在我们的例子中是 CRM 提供商。我们可以在防火墙上戳洞，但从安全表面区域的角度来看，这并不理想。特别是如果需要在类似 DMZ 的区域中的开发人员数量很高。我们目前正在 DMZ 中尝试单台开发机器，然后根据需要进行远程处理以进行开发工作，但如果多个开发人员需要该机器，就会产生资源稀缺问题，更不用说他们进行潜在的冲突更改（例如不同的分支）。

我们考虑过通过为这些服务构建虚假客户端来模拟/伪造传入请求，但这是构建功能集的一个相当大的开销（尽管它本质上确实增强了我们 API 的可测试性）。这也不能排除这样一个事实，即有时我们确实需要诊断/调试来自真实客户端本身的问题，而不是一些伪造的请求有效负载。

其他人在这些类型的场景中做了什么？在这个混搭时代，必须有很多人有开发 API 的经验——对于那里的人来说，哪些工作（和不工作）好？

4

2 回答 2

1

In the occasions when this has been relevant to me (which, truth be told, is not often) we have tended to do a combination of hosting a dev copy of the solution in-house and mocking what we can't host.

I personally think that the more you can host on individual dev boxes the better-- if your dev's PCs are powerful enough to have the entire thing running plus whatever else they need to develop then they should be doing this. It allows them to have tonnes of flexability to develop without worrying about other people.

于 2008-08-27T03:55:35.177 回答
1

对于开发人员来说，使用模拟对象并编写好的单元测试来定义手头的任务是有意义的。这将有助于确保开发人员了解业务需求。模拟库非常复杂，有助于解决这个问题。

然后可能是一个持续的构建过程，将代码移动到 DMZ 中的开发箱。一个强大的质量保证流程加上一般的 UAT 测试是有意义的。

此外，对于一般调试，您再次需要访问您远程所在的 DMZ 中的机器。

这可能是一个“理想”的情况，但您确实要求最佳实践:)。

于 2008-09-30T16:03:17.603 回答