Собственные проекты: стабильный выпуск или нет?

Question

Предположим, вы работаете в компании-разработчике программного обеспечения среднего и крупного размера со многими независимо разработанными проектами (независимыми программистами), но полагающимися друг на друга (зависимый код).

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

Преимущество стабильной версии для меня очевидно - более высокая вероятность того, что ваши зависимости будут работать так, как рекламируется. Тем не менее, я также вижу некоторые положительные стороны в том, что следует избегать стабильных выпусков - у каждого проекта есть немного меньше работы, и вы можете очень быстро реагировать на ошибки, которые затрагивают всех, так как ваш код постоянно обновляется. Например, представьте, что есть небольшая уязвимость в метке времени X в одной внутренней библиотеке - ее можно не заметить, пока этот код не будет широко использоваться. Если вы используете стабильные ветки релизов, вам нужно будет заставить каждый другой проект изменять свои зависимости, чтобы обеспечить исправление безопасности. Без веток релиза исправление сразу же подбирается в следующей сборке всех других проектов.

Мне особенно интересно, имеет ли кто-либо опыт работы в отрасли с обеими альтернативами.

Answer 1

Как всегда, у каждого варианта есть свои плюсы и минусы.

Использование веток может быть более стабильным, но оно требует больше обслуживания, когда вам необходимо перейти на более новую ветку. Это также требует, чтобы их команда разработчиков потратила дополнительное время, когда ветвь объединена со стволом.

С другой стороны, использование транка может заставить вас справляться с ошибками других людей и писать грязный обходной код, чтобы обойти его. Это может стать особенно грязным, если у вас возникнут странные проблемы с OutOfMemory / Performance, которые невозможно закрепить за конкретной библиотекой (или вашим собственным кодом). Помните, что это не ваш код, и у вас, вероятно, нет рабочей силы, чтобы помочь им в их усилиях по обеспечению качества ...

Так что, я думаю, последнее слово в том, что это зависит. Я бы предложил принять во внимание эти факторы:

1. Изменится ли используемый вами API?
2. Важно ли работать над "чистым кодом" или вы можете позволить себе возиться с ошибками других людей?
3. Важно ли, чтобы приложение использовало «передовую» версию библиотек?

В качестве дополнительного примечания и из своего опыта могу сказать, что один из наших программистов пропал пару ночей сна, потому что работал с ветками, а обновление до новой ветки изменило весь API и логику. :)

НТН

Answer 2

Думаю, что все зависит от того, насколько важным является программное обеспечение. Если вы можете смириться с легким сбоем и, возможно, с некоторым повреждением данных, и легко собрать новые сборки, предпочтительнее использовать нестабильный код. Теперь, если жизнь или репутация зависят от того, что все работает правильно, или если запуск новой сборки - важный процесс, стабильные протестированные выпуски - единственный путь.

Answer 3

Глядя на другие проекты, мне кажется, что проблема, которую вы поднимаете, решается с помощью ветвей безопасности. Например. Пакеты Debian. Таким образом, вы продолжите использовать стабильную ветвь между проектами. По указанным вами причинам ветки тестирования / незавершенного производства несут слишком большой риск.