开发环境和 API 开发的最佳实践？

Question

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

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

因此，虽然我们的用例有些细微差别，但这通常适用于任何为第 3 方使用构建 API 的开发公司：在构建 API 时设计开发管道和环境时有哪些最佳实践被外界消费？

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

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

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

Answer 1

在与我相关的情况下（说实话，这种情况并不常见），我们倾向于结合在内部托管解决方案的开发副本和嘲笑我们无法托管的内容.

我个人认为，您可以在单个开发盒上托管的内容越多越好 - 如果您的开发者的 PC 足够强大，可以运行整个系统以及他们需要开发的任何其他东西，那么他们应该这样做。它使他们能够灵活地进行开发，而不必担心其他人。

Answer 2

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

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

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

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