#continuous-deployment #branching-strategy #github-flow
#непрерывное развертывание #стратегия ветвления #github-flow
Вопрос:
Как вы подходите к работе с постоянно растущим набором флагов функций в вашей кодовой базе для разработчиков, использующих разработку на основе магистрали?
Меня беспокоит то, что если вы будете активно использовать флаги функций для каждого выпуска и каждой новой функции, не начнет ли объем кода с флагами функций делать код менее читаемым и, возможно, более сложным в обслуживании? Ради этого вопроса предположим, что флаги функций обрабатываются внешним FFaaS.
Основываясь на моих собственных рассуждениях, я вижу несколько вариантов:
- Никогда не удаляйте флаги функций. Держите их рядом на случай, если они вам могут понадобиться (например, для установки функции, от которой вы отказываетесь позже).
- Периодически удаляйте старые флаги функций, которые оставались включенными в течение X времени. Это решает проблему читаемости кода, но нарушает парадигму развертывания на основе магистрали, поскольку вы теряете резервную меру включения / выключения флага, поскольку сам флаг удаляется. Вы также можете проиграть в приведенном выше случае, когда вам придется вручную отслеживать функциональность для поэтапного отказа или, возможно, повторно вводить флаги функций, чтобы облегчить аналогичный переход.
Как люди справлялись с логистикой, используя эту систему разработки?
Комментарии:
1. «Резервная мера» не должна быть постоянным решением. В какой-то момент вам придется принять риск того, что в вашем коде все еще будут ошибки, которые вы не нашли, но все же вы удаляете «старый способ» выполнения вещей без флага функции. У вас не может быть 1 версии программного обеспечения в рабочей среде с каждой версией каждой функции каждого выпуска . Начните удалять старые флаги функций. Старый, как и раньше, больше никогда не будет отключен.
2. Способ, которым мы это делаем (ну … пытаемся, я признаю, что у нас также есть несколько флагов долгоживущих функций, которые все еще присутствуют), заключается в том, что как только мы запускаем новую версию в производство с флагом функции, мы также создаем проблему в нашем трекере проектов для удаления флага функции. Это удаление также означает постоянное включение новой функции и, таким образом, избавление не только от операторов if и самого флага, но и от любого старого кода, который был заменен новым. Флаги функций имеют смысл, только если вы сохраняете их временными, в противном случае вы добавите слишком много сложностей, как вы уже обнаружили.
3. Кроме того, не используйте флаги функций для включения материалов для клиентов, это опции, модули, лицензии и т. Д. Флаги функций — это инструмент для развертывания и тестирования, а не средство избежать добавления системы лицензирования, в которой разные клиенты видят разные вещи. И да, иногда вы включаете флаги функций для определенных клиентов, но это в контексте тестирования, а не в ситуации «этот клиент теперь купил модуль X». Для этого вам нужно что-то еще.
4. Однако, в конце концов, единственный (ие), кто действительно может ответить на этот вопрос, — это вы сами. Все, что мы можем сделать, это поделиться мнениями и анекдотами. Вам придется довольствоваться своим собственным процессом. Если вы видите проблемы с оставлением флагов функций на месте, проведите семинар, на котором обсудите альтернативы. Не существует 100% идеальных решений , все они являются компромиссами. Поэтому найдите компромиссы, с которыми вы готовы смириться.