Я пытаюсь найти способ предупредить моих разработчиков, что их изменения могут нарушить бинарную совместимость.
Наше приложение структурировано таким образом, что оно обеспечивает базовую среду, которую потребляют более 20 (независимо развернутых) дочерних библиотек DLL. Если вносятся изменения в базовую платформу, дочерняя DLL может сломаться.
Для этого конкретного приложения мы не обязательно заботимся о том, чтобы базовая структура поддерживала полную обратную совместимость, так что методы всегда должны выводить одинаковые значения / манипулировать входными данными одинаково. Таким образом, дочерняя DLL, подключенная к базовой платформе, может получить исправления «бесплатно» при изменении компонентов инфраструктуры.
За последние несколько недель мы увидели два случая, оба из которых нарушили двоичную совместимость и потребовали немедленных исправлений:
- Интерфейс изменен с
void SomeMethod(List<...> someList); на SomeMethod(IList<...> someList);
- Статический помощник изменен для добавления необязательного параметра, например, от
public static int FancyCompare(..., string right) до public static int FancyCompare(..., string right, int maxPrecision=3);
В этих случаях проблемы не были обнаружены до производства, потому что наши автоматизированные сборки Bamboo всегда перекомпилируются с учетом последней проверки и тестов, которые мы выполняем, они на самом деле не проверяют сигнатуры методов верхнего уровня. В настоящее время у Bamboo нет способа запустить plugin_vOld против core_vNew.
Я мог бы потенциально обойти интерфейс, запретив все изменения в основных интерфейсах и потребовав от разработчиков создания новых интерфейсов, а затем заставить конкретные реализации реализовывать несколько интерфейсов, но это быстро запутается. Это все еще не решает проблему необязательного параметра.
Кто-нибудь знает, например, плагин VS или Resharper, который предупредит разработчика, что их изменение нарушает бинарную совместимость? Или, может быть, плагин системы сборки Bamboo? Или какой-то другой метод?