Что такое "Переключатели функций" и "Филиалы функций" и какая разница между ними?
Каковы плюсы и минусы? Почему один лучше другого?
Я нашел в Google некоторые статьи об этом, и я, как правило, попал в лагерь "Feature Toggles", но я не уверен, что "Feature Toggles" - лучший выбор во всех случаях.
Функциональные переключатели - это методология, используемая в цепочке непрерывной интеграции/непрерывной доставки (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
Короче говоря, ветки функций дадут вам лучшую изоляцию, но потребуют от вас устранения боли отложенной интеграции и слияния. Toggles дают вам непрерывную интеграцию, но вам необходимо разработать/реализовать свой код таким образом, чтобы поддерживать привязки, и представить риск того, что незавершенный код функции может отрицательно повлиять на производство.
Вы можете использовать обе ветки и переключатели вместе (они не являются взаимоисключающими). Что касается решения, какой из них использовать в каждом сценарии, мои мысли состоят в том, что переключатели должны быть выбором по умолчанию, если не верны следующие значения:
Если любое из этих условий истинно, я бы, вероятно, использовал ветку признаков вместо переключения.
Функция переключения требует очень строгой дисциплины, так как сломанный/темный код превращая его в производство.
Я согласен с Electrawn, я использую функцию ветвления через 6 лет, потому что в нашем случае у нас нет предварительных требований.
Также важно понять, что "Стратегия Google" переносит усилия, проведенные в Стратегии "Филиалы" ( "Слияние" ) в другой момент.
http://martinfowler.com/bliki/FeatureToggle.html
Очень важно уйти в отставку, как только ожидающие функции сломаются в производстве. Это включает удаление определений в файле конфигурации и всего кода, который их использует. В противном случае вы получите кучу переключателей, которые никто не может запомнить, как использовать. В одном незабываемом примере я слышал, потребовалось произвести специальную перекомпиляцию ядра linux для управления достаточными ключами командной строки.
Примечание. Следуя принципам SCM, если кто-нибудь откроет и отредактирует файл, он может быть поврежден.
Итак, с моей точки зрения, я не верю в "лучший выбор во всех случаях", потому что это зависит от культуры вашей команды и если у вас есть тестовая обложка.
Ну, это очень полемический вопрос.
Я по-прежнему предпочитаю стратегию веток в моем случае. Сохраняя лучшие практики SCM и планируя дорожную карту, процесс слияния имеет тенденцию быть простым способом. В течение этого года я слышал, как многие люди жалуются на процесс слияния, но во многих случаях проблема слияния в моем опыте одинакова: "Сбой связи":)
Извините за нечеткий ответ, но я думаю, что в этом вопросе лучшего выбора в SCM есть некоторые аспекты людей.