Что такое «переключатели функций» и «ветви функций» и в чем разница между ними?
Каковы плюсы и минусы? Почему одно лучше другого?
Я нашел несколько статей в Google по этому поводу, и я склонен быть сторонником «переключателей функций», но я не уверен, что «переключатели функций» - лучший выбор во всех случаях.
Переключатели функций - это методология, используемая в цепочке непрерывной интеграции / непрерывной доставки (CI / CD) (методология проекта Agile / Kanban). По сути, вы отправляете новые функции в производство в отключенном состоянии, а затем в консоли администратора включаете эту функцию (или выключаете, если обнаруживаете, что она сломана).
Ветви функций могут быть частью методологии выпуска и интегрироваться в цепочку непрерывной интеграции. Вы можете разработать в функциональной ветви, развернуть ветвь в DEV / QA, получить сертификацию, объединить функциональную ветвь с транком, а затем отправить транк в среды SIT / UAT / PROD.
У этого подхода есть свои плюсы и минусы. Переключение функций требует очень строгой дисциплины, так как сломанный / темный код готовится к производству. Это отлично подходит для стартапов и магазинов, где руководство знает, как это сделать, и имеет инструменты системной автоматизации (Chef / Puppet / cfengine и т. Д.). Google, Facebook, LinkedIn, WordPress - все они развертываются в производственных средах с использованием переключения функций и автоматизации системы. .
Существуют некоторые предварительные "технические средства" для правильного переключения функций: непрерывная доставка / развертывание, непрерывная интеграция, автоматическое модульное тестирование, автоматическое тестирование интеграции, автоматическое стресс-тестирование / тестирование производительности, автоматизация системы. Если у вас их нет, рассмотрите более простую стратегию выпуска (например, ветвление функций).
Я подробно обсуждаю это в своем блоге: http://geekswithblogs.net/Optikal/archive/2013/02/10/152069.aspx
Короче говоря, функциональные ветки дадут вам лучшую изоляцию, но потребуют от вас решения проблем отложенной интеграции и слияний. Переключатели обеспечивают непрерывную интеграцию, но требуют, чтобы вы спроектировали / внедрили свой код таким образом, чтобы поддерживать переключатели, и создают риск того, что незаконченный код функции может отрицательно повлиять на производство.
Вы можете использовать как ветви, так и переключатели вместе (они не исключают друг друга). Что касается решения, какой из них использовать в каждом сценарии, я считаю, что переключатели должны быть выбором по умолчанию, если только следующее не верно:
Если хотя бы одно из этих условий верно, я бы, вероятно, использовал функциональную ветку вместо переключения.
feature branch -> main. Я видел много успехов, когда делали это наоборот, непрерывно интегрируя, вытягивая последние из main в feature branch, так что в то время, когда вам нужно интегрироваться обратно в main, ваше слияние происходит быстро, а значит, безболезненно.
- person pgpb.padilla; 25.09.2015
Переключение функций требует очень строгой дисциплины, так как сломанный / темный код готовится к производству.
Я согласен с Electrawn, я использую ветвление функций на протяжении 6 лет, потому что в нашем случае у нас нет предварительных требований.
Также важно понимать, что «Стратегия Toogle» переносит усилия, затраченные на Стратегию Функциональных Ветвей (Слияние), на другой момент.
http://martinfowler.com/bliki/FeatureToggle.html
Очень важно убрать переключатели после того, как отложенные функции будут внедрены в производственную среду. Это включает в себя удаление определений в файле конфигурации и всего кода, который их использует. В противном случае вы получите кучу переключателей, которыми никто не сможет вспомнить, как ими пользоваться. В одном памятном примере, о котором я слышал, потребовалась специальная перекомпиляция ядра Linux для обработки достаточного количества ключей командной строки.
Примечание. Следуя принципам SCM, если кто-нибудь откроет и отредактирует файл, это может стать некорректным кодом.
Итак, на мой взгляд, я не верю в «лучший выбор во всех случаях», потому что это зависит от культуры вашей команды и наличия у вас тестового покрытия.
Что ж, это очень полемический вопрос.
В моем случае я по-прежнему предпочитаю стратегию функциональных веток. Сохраняя передовой опыт SCM и планируя дорожную карту, процесс слияния, как правило, оказывается простым. В течение этого года я слышал, как многие люди жалуются на процесс слияния, но в большинстве случаев проблема слияния остается той же, по моему опыту: «Связь не работает» :)
Извините за неточный ответ, но я думаю, что есть некоторые человеческие аспекты, связанные с этим предметом лучшего выбора в SCM.
