У меня есть 2 приложения с общей библиотекой. И приложения, и библиотека находятся в активной разработке. Оба приложения включают файл проекта в свое решение.
Папки расположены в системе контроля версий как:
Root
App1
App2
Library
В настоящее время у нас есть отдельные сборки круиз-контроля, настроенные для запуска каждый раз, когда файл фиксируется в иерархиях папок app1, app2 или библиотеки. После успешной сборки библиотеки будут запущены сборки app1 и app2.
По большей части это работает хорошо; проблема в том, что кто-то фиксирует изменения и в библиотеке, и в приложении 1 (или в приложении 2). Обычно это происходит в результате реализации функции, которая требует модификации / добавления чего-либо в библиотеке для реализации. Когда это происходит, активируются триггеры для создания библиотеки (изменение в Library \ foo.cs) и App1 (изменение в app1 \ bar.cs). Оба увидят, что файл Base \ Library \ foo.cs был изменен, и попытаются восстановить библиотеку. Успех будет достигнут только у одного, потому что первый, кто начнет писать объектный файл для библиотеки, получит исключительную блокировку файла; второе сразу терпит неудачу. Это происходило несколько раз, заставляя кого-то войти и вручную перезапустить сборку, которая не удалась из-за блокировки.
Чтобы попытаться снизить риск повторения этого события, мы изменили интервалы опроса для каждого из триггеров, чтобы они устанавливали разные значения, чтобы попытаться избежать двух срабатываний одновременно. Это все еще не идеально, потому что циклы между библиотекой и AppN будут происходить в одно и то же время каждые N * M секунд (N и M - соответствующие интервалы опроса).
Есть ли более элегантное или менее вероятное решение для сбоя?