Я работаю над приложением, которое в значительной степени существует только как расширение другого веб-приложения, и все, что оно делает, представляет / изменяет данные в этом другом сервисе.
Этот сторонний APIтаков, что многие вызовы содержат идентификаторы для пользовательских данных, и, когда происходят изменения в этих пользовательских объектах, приложение должно следовать примеру обновлений своих вызовов.В настоящее время это исходит из конфига.Изменения в пользовательских данных поступают от нашего клиента, который является администратором сторонней службы.В лучшем случае изменения пользовательских данных согласовываются с нами для обновления конфигурации в режиме блокировки.В худшем случае вещи ломаются, и мы должны выяснить, почему.
Кроме того, наше приложение существенно расширяет сущности в их системе, и это также по ID в их сущностях.Чтобы все работало, наши сущности должны соответствовать сущностям в их системе в надлежащем состоянии для того, где сущность находится в нашей системе.
Мы только что обновили песочницу, поэтому все данные продукта были отправлены вэкземпляр песочницы, и мы должны были исправить наши тестовые конфиги env для обновления.К счастью, это в основном копирование конфигов prod.Это утомительно, и все настройки, относящиеся к сторонним разработчикам, с которыми мы интегрируемся, перемешаны вместе.Я думаю, что я определил их все и добавил пару страниц в нашу вики о том, что делать, когда происходит обновление.Я также, по крайней мере, думаю, по большей части, стер данные, относящиеся к другим системным объектам, которые мы расширяем.Есть также процесс шифрования данных в сторонней системе, который мы должны сделать, потому что это вся реальная информация о клиентах.Для многих из них есть сценарии, и их нужно обновлять, поскольку они не запускаются вне обновлений, а по мере развития они устаревают.Страницы вики, которые я добавил, также охватывают это.
На этом этапе они собираются делать запросы функций, нам нужно будет администрировать песочницу, чтобы создавать объекты, соответствующие новым настройкам конфигурации для новых функций,и затем, когда мы запускаем функцию в реальном времени, мы должны убедиться, что они создали новые объекты в сервисе prod, получить эти идентификаторы и убедиться, что конфигурация prod соответствует сервису prod.Сервисы «песочница» и «prod» будут отличаться во время разработки до следующего обновления «песочницы» от prod, где тестовые среды снова сломаются, и нам нужно обновить наши конфигурации, промыть состояние нашего приложения и скремблировать их сущности, содержащие данные клиентов.
Каждый раз, когда появляется «должен быть лучший путь», я упоминаю создание симуляторов для третьих сторон, с которыми мы интегрируемся, чтобы сломать наши зависимости, по крайней мере, на самых ранних этапах разработки, и что это более чем удвоит время для любогоновая работа в будущем, и это в краткосрочной перспективе взорвать усилия больше, чем это.Мы слишком маленькие и не можем себе этого позволить.Кроме того, вы все равно должны запустить свое приложение в песочнице, прежде чем начать работу в какой-то момент.На данный момент у нас нет формального контроля качества, в лучшем случае мы проводим оффшорное ручное тестирование.У меня есть несколько тестов дыма пользовательского интерфейса и подкожных тестов E2E, и я просто выполняю свои новые функции вручную, кажется достаточно хорошим, чтобы не допустить катастрофы.
Есть способы, которыми API предоставляет некоторые из текущихВ пользовательских настройках может быть задание, в котором выполняется синхронизация идентификаторов на основе сопоставления строк, но это зависит от того, происходит ли изменение этих значений в соответствии с тем, что настроено для сопоставления.Это та же проблема.Почти каждый аспект нашего приложения хрупок и будет давать сбой, когда в стороннем поставщике будет изменена неправильная вещь.
Лучшее, что я могу понять, - это создание какой-то постоянной проверки нашего состояния интеграции, которая выполняется в течение дня и срабатывает всякий раз, когда какой-либо вызов API, который мы делаем, перестает работать.Это должно было бы отличить временные ошибки от чего-то законно изменяющегося и требующего обновления конфигурации с нашей стороны, а затем нам все еще нужно поискать новые идентификаторы, перенастроить, в зависимости от части перезапуска, затронутой приложением, и в худшем случае поспоритьс их администратором о том, что они делают с нашим приложением посредством внесения изменений в сторонние организации, либо исправления, либо попросите их вернуть его обратно.К счастью, по крайней мере, они очень заботятся о том, чтобы наше приложение работало, оно становится ядром их бизнеса.
Кажется, что слишком много работы, чтобы получить одобрение для нашего конвейера.Какие-либо предложения?Какие инструменты / методы я пропускаю?