我目前的雇主使用第三方托管的CRM提供商，我们在两个系统之间拥有相当复杂的集成层。 CRM提供程序的功能之一是，开发人员可以使用类似Java的语言编写业务逻辑，并在诸如用户单击按钮或向系统提交新帐户等事件中创建业务逻辑，从而启动验证和/或业务逻辑。
我们使用的功能之一是在托管提供程序上运行的业务代码，以调用我们托管的Web服务。典型的例子是销售代表进入新的销售线索并按下按钮来ping我们的系统以查看我们是否可以根据电子邮件地址，公司/名字/姓氏等识别新的潜在客户，如果是，请返回表示该个人的内部GUID。这一切对我们来说都很好，但我们一次又一次地试图设置一个理智的开发环境来反对。
因此，虽然我们的用例有点微妙，但这通常适用于为第三方消费构建API的任何开发人员：在构建API时设计开发管道和环境时的一些最佳实践被外界消费？
在我们的办公室，我们所有的开发人员都在防火墙之后，因此正在进行的代码不会受到外部世界的攻击，在我们的案例中是CRM提供商。我们可以在防火墙上挖洞，但从安全表面区域来看，这不太理想。特别是如果需要在像DMZ这样的区域中的开发者的数量很高。我们目前正在尝试在DMZ中使用单个开发机器，然后根据需要进行远程工作以进行开发工作，但如果多个开发人员需要这个框，则会造成资源稀缺问题，更不用说他们正在进行潜在冲突的更改（例如，不同的分支机构） ）。
我们考虑过通过为这些服务构建虚假客户端来模拟/伪造传入请求，但这是构建功能集的一个相当大的开销（尽管它本质上强化了我们API的可测试性）。这也无法避免这样一个事实，即有时我们确实需要诊断/调试来自真实客户端本身的问题，而不是某些伪造的请求负载。
在这些类型的场景中，其他人做了什么？在混搭的这个时代，必须有很多人有开发API的经验 - 对那些人来说有什么用（而不是那么有效）？
答案 0 :(得分：1)
在这与我有关的事件中（事实上，事实并非如此），我们倾向于组合在内部托管解决方案的开发副本并嘲笑我们无法托管的内容
我个人认为你可以在个人开发盒上托管的越多越好 - 如果你的开发者的PC足够强大，可以运行整个东西以及他们需要开发的任何其他东西，那么他们应该这样做。它允许他们在不担心其他人的情况下开发出大量的灵活性。
答案 1 :(得分：1)
对于dev，使用模拟对象并编写定义手头任务的良好单元测试是有意义的。这将有助于确保开发人员了解业务需求。模拟库非常复杂，有助于解决这个问题。
然后可能是一个连续的构建过程，将代码移动到DMZ中的开发框。一个强大的QA流程对一般的UAT测试更有意义。
此外，对于一般调试，您还需要访问远程进入的DMZ中的计算机。
这可能是一个“理想”的情况，但你确实要求最佳实践：）。