История изменений
Исправление alpha, (текущая версия) :
Ты путаешь модель доставки (срезал и заморозил) и модель разработки (CI).
Разработка не может быть по принципу заморозки, она всегда идет вперед. Да, в какой-то момент ты берешь срез текущего состояния, доводишь до ума и релизишь. Пользователи рады, но ты-то уже пошел разрабатывать дальше.
Если сравнивать разработку без CI и разработку с CI, то выглядит это примерно так:
в первом случае ты в течение некоторого времени накидываешь изменения в ветку в репе (если разработка проекта), в rawhide-репу (если разработка дистрибутива). После некоторого периода разработки ты включаешь режим интеграции: пытаешься смерджить свою ветку в mainline, или пытаешь собрать и запустить исошку и прогнать какие-нибудь тесты.
И практика показывает что сложность интеграции растет экспоненциально от количества изменений которые ты между шагами интеграции сделал.
Кроме того сложность вот этого интеграционного шага - «срезали и довели до ума» становится абсолютно непредсказуемой по трудоемкости. Это такая большая подстава, которая ждет тебя в (условном) конце разработки, когда ты уже вроде как собрался в отпуск и осталось «только собрать». Оказывается что это очень дорогостоящая операция, ломающая все планы, дедлайны и бонусы топ-менеджерам, и часто приводяющая к тому что часть фич надо просто заново переписывать, потому что они не проинтегрировались а стали работать друг против друга.
Отсюда концепция CI: интегрироваться как можно чаще, на как можно меньшем объеме изменений. Это медленнее с точки зрения разработки конкретной фичи, но сильно быстрее если рассматривать жизненный цикл проекта целиком.
Это не значит что и релизить обязательно каждую неделю. Но поддерживать состояние кода близкое к релизному. Так что если в какой-то момент будет принято решение что-то срезать, заморозить и зарелизить - это будет не интеграционный взрыв а вполне подъемная операция.
Это нормальная модель разработки?
Это модель разработки которую все пытаются делать с переменным успехом. На уровне проектов уж точно. На уровне дистрибутивов это немного сложнее. Но Fedora тут не первопроходец к сожалению, с CI для пакетов мы малость отстаем.
См про debian
https://archive.fosdem.org/2017/schedule/event/distribution_ci/
Исходная версия alpha, :
Ты путаешь модель доставки (срезал и заморозил) и модель разработки (CI).
Разработка не может быть по принципу заморозки, она всегда идет вперед. Да, в какой-то момент ты берешь срез текущего состояния, доводишь до ума и релизишь. Пользователи рады, но ты-то уже пошел разрабатывать дальше.
Если сравнивать разработку без CI и разработку с CI, то выглядит это примерно так:
в первом случае ты в течение некоторого времени накидываешь изменения в ветку в репе (если разработка проекта), в rawhide-репу (если разработка дистрибутива). После некоторого периода разработки ты включаешь режим интеграции: пытаешься смерджить свою ветку в mainline, или пытаешь собрать и запустить исошку и прогнать какие-нибудь тесты.
И практика показывает что сложность интеграции растет экспоненциально от количества изменений которые ты между шагами интеграции сделал.
Кроме того сложность вот этого интеграционного шага - «срезали и довели до ума» становится абсолютно непредсказуемой по трудоемкости. Это такая большая подстава, которая ждет тебя в (условном) конце разработки, когда ты уже вроде как собрался в отпуск и осталось «только собрать». Оказывается что это очень дорогостоящая операция и ломающая все планы, дедлайны и бонусы топ-менеджерам, и часто приводяющая к тому что часть фич надо просто заново переписывать, потому что они не проинтегрировались а стали работать друг против друга.
Отсюда концепция CI: интегрироваться как можно чаще, на как можно меньшем объеме изменений. Это медленнее с точки зрения разработки конкретной фичи, но сильно быстрее если рассматривать жизненный цикл проекта целиком.
Это не значит что и релизить обязательно каждую неделю. Но поддерживать состояние кода близкое к релизному. Так что если в какой-то момент будет принято решение что-то срезать, заморозить и зарелизить - это будет не интеграционный взрыв а вполне подъемная операция.
Это нормальная модель разработки?
Это модель разработки которую все пытаются делать с переменным успехом. На уровне проектов уж точно. На уровне дистрибутивов это немного сложнее. Но Fedora тут не первопроходец к сожалению, с CI для пакетов мы малость отстаем.
См про debian
https://archive.fosdem.org/2017/schedule/event/distribution_ci/