Мой нынешний работодатель использует сторонний хостинг-провайдер CRM, и у нас есть довольно сложный уровень интеграции между двумя системами. Среди возможностей поставщика CRM для разработчиков является создание бизнес-логики на языке Java, как и на таких событиях, как пользователь, нажав на кнопку или отправив новую учетную запись в систему, есть проверка и / или бизнес-логика выстрелить.

Одна из возможностей, которую мы используем, заключается в том, что бизнес-код, запущенный на хост-провайдере, вызывает веб-службы, которые мы размещаем. Канонический пример - это торговый представитель, который вводит новый интерес к продажам и нажимает кнопку, чтобы проверить наши системы, чтобы узнать, можем ли мы идентифицировать этот новый интерес на основе адреса email, имени company/first/last и т. д., И если да, верните внутренний GUID, который представляет этого человека. Все это прекрасно работает для нас, но мы снова и снова натыкаемся на стену, пытаясь настроить разумную среду разработки для работы.

Таким образом, хотя наш вариант использования немного нюансирован, это обычно может применяться к любому дому разработки, который строит APIs для потребления третьей стороной: каковы некоторые рекомендации при проектировании конвейера разработки и среды, когда вы строите APIs для потребления внешним миром?

В нашем офисе все наши разработчики находятся за брандмауэром, поэтому текущий код не может быть поражен внешним миром, в нашем случае провайдером CRM. Мы могли бы проделать дыры в брандмауэре, но это не идеально с точки зрения безопасности поверхности. Особенно, если # разработчиков, которые должны быть в DMZ, как область высока. В настоящее время мы пробуем одну машину dev в DMZ, а затем удаляемся в нее по мере необходимости для выполнения работы dev, но это создает проблему нехватки ресурсов, если несколько разработчиков нуждаются в коробке, не говоря уже о том, что они делают потенциально конфликтующие изменения (например, разные ветви).

Мы рассмотрели только издевательство / подделку входящих запросов путем создания поддельных клиентов для этих служб, но это довольно большие накладные расходы при создании наборов функций (хотя это по своей природе усиливает тестируемость нашего APIs). Это также не устраняет тот факт, что иногда нам действительно нужно диагностировать/отлаживать проблемы, исходящие от самого реального клиента, а не от какой-то поддельной полезной нагрузки запроса.

Что сделали другие в таких сценариях? В этот день и век мэшапов, должно быть много людей там w/ опыт разработки APIs-что работает (и не работает так) хорошо для людей там?

У меня есть два отдельных репозитория mercurial. На данный момент имеет смысл, что они "become one", потому что я хочу работать над двумя проектами одновременно.

Мне бы очень хотелось, чтобы каждый из этих двух проектов был подкаталогом в новом репозитории.

1. Как объединить эти два проекта?
2. Это хорошая идея, или я должен это сделать держать их отдельно друг от друга?

Кажется, я должен уметь переходить из одного хранилища в другое... Может быть, это действительно прямолинейно?