Перед нами не стояла задача наладить хранение артефактов из CI. Артефактори стал бы для нас дополнительной точкой отказа. Подробнее описано в 4 пункте в блоке "Выбор хранилища".
Спасибо за комментарий! Согласен с вами, получать данные из первого источника наиболее верный подход, но по некоторым причинам, в частности, описанными выше, мы выбрали подход с дополнительным хранилищем данных, и именно этот случай описан в данной статье.
Вы правы, это отличный вариант! Но для нас это не решение проблемы, а новое ограничение - сборка одной версии занимает от 15 минут и в таком случае мы теряем возможность делать сборки одновременно, и рано или поздно мы получим очередь из таких задач.
Вы также правы насчет того что проблема race condition не решается в полной мере, но значение этого промежутка не велико, т.к. оно зависит от скорости выполнения скрипта, описанного выше. В нашем случае оно равно, в среднем, 2-3 секунды (пример на скрине). Мы с командой определили что вероятность одновременного создания сборки в интервал 3 секунды, стремится к нулю и мы можем пойти на такой шаг, чтобы не ограничивать себя в выполнении только 1 экземпляра инстанса.
Да, это хороший вариант, но при таком подходе мы не исключаем race condition. Между получением последней сборки и сохранением новой - проходит время (как минимум: билд + отправка через fastlane), и мы не застрахованы что во время этого этапа кто-нибудь из разработчиков сделает новую сборку, соответственно - данные для новой сборки будут неконсистентными
Перед нами не стояла задача наладить хранение артефактов из CI. Артефактори стал бы для нас дополнительной точкой отказа. Подробнее описано в 4 пункте в блоке "Выбор хранилища".
Спасибо за комментарий!
Согласен с вами, получать данные из первого источника наиболее верный подход, но по некоторым причинам, в частности, описанными выше, мы выбрали подход с дополнительным хранилищем данных, и именно этот случай описан в данной статье.
Не совсем понял какой классический вариант вы имеете в виду. Приведите, пожалуйста, примеры.
Вы правы, это отличный вариант!
Но для нас это не решение проблемы, а новое ограничение - сборка одной версии занимает от 15 минут и в таком случае мы теряем возможность делать сборки одновременно, и рано или поздно мы получим очередь из таких задач.
Вы также правы насчет того что проблема race condition не решается в полной мере, но значение этого промежутка не велико, т.к. оно зависит от скорости выполнения скрипта, описанного выше. В нашем случае оно равно, в среднем, 2-3 секунды (пример на скрине). Мы с командой определили что вероятность одновременного создания сборки в интервал 3 секунды, стремится к нулю и мы можем пойти на такой шаг, чтобы не ограничивать себя в выполнении только 1 экземпляра инстанса.
Да, это хороший вариант, но при таком подходе мы не исключаем race condition.
Между получением последней сборки и сохранением новой - проходит время (как минимум: билд + отправка через fastlane), и мы не застрахованы что во время этого этапа кто-нибудь из разработчиков сделает новую сборку, соответственно - данные для новой сборки будут неконсистентными