Первоначально опубликовано в блоге LaunchDarkly Джавидом Джамае, главным инженером Tout.
Tout — это видеоплатформа для медийных брендов и издателей контента. У нас есть видеоплееры на сотнях известных веб-сайтов и блогов с большим трафиком в США. Используя наш рынок видеопродукции, веб-сайты могут демонстрировать высококачественный видеоконтент от таких производителей, как Time, Yahoo, Condé Nast, The Wall Street Journal, ESPN и десятки других. Сайты также могут позволить своим журналистам и авторам захватывать их собственный видеоконтент с помощью наших приложений для Android и iOS, а затем воспроизводить их на своих сайтах.
Наши службы работают так, что мы предоставляем код для встраивания JavaScript, который сайты наших партнеров размещают в шаблоне своего сайта. Когда их страница загружается, мы внедряем наши видеоплееры в различные части страницы. Решение о том, где размещены видеопроигрыватели, какой у него видеоконтент и как он выглядит, может быть решено на стороне сервера, что сводит к минимуму изменения конфигурации и кода для наших клиентов.
В первые дни у нас было всего несколько сайтов, использующих наши новые продукты. Для простоты мы сохранили большую часть конфигурации нашего продукта в коде и согласовали его на всех сайтах наших партнеров. Когда мы хотели внести изменения, мы договаривались со всеми из них, прежде чем внедрять новую функцию. Это было управляемо, потому что изменчивость была незначительной или отсутствовала, а уведомлять отдельных партнеров об изменениях было легко.
По мере роста нашей клиентской базы нам становилось все труднее поддерживать конфигурацию одного продукта, поэтому мы представили способ настройки продуктов по-разному для каждого партнерского веб-сайта. Но из-за природы встроенного продукта нам стало трудно тестировать изменения внутри компании и демонстрировать изменения нашим партнерам.
Мы провели внутреннее тестирование с использованием прокси-программного обеспечения для веб-отладки под названием Charles. Мы развернем обновленную версию нашего кода в нашей промежуточной (то есть внутренней тестовой) среде, а затем настроим Чарльза для прокси нашего производственного сервера на нашем промежуточном сервере на машине, на которой мы тестировали. Хотя в этом процессе есть несколько препятствий, в целом он работает относительно хорошо. Проблема этого подхода в том, что он работает только для внутреннего тестирования.
Наши клиенты часто хотели предварительно просмотреть новые изменения на своем сайте, прежде чем мы их развернули, чтобы они могли самостоятельно проводить проверку и обучение. Поскольку спрос на предварительные просмотры клиентов увеличился, мы начали рассматривать переключатели функций как решение.
Концептуально переключатели функций просты: вы просто сохраняете старую версию своего кода на месте, но заключаете ее в условное предложение, которое выполняет новую функцию, если функция включена:
if feature_enabled("blah")
run_new_code()
else
run_old_code()
endПоскольку мы используем Ruby on Rails, мы начали с использования библиотеки Ruby, которая называется «feature». Библиотека объектов — это библиотека с открытым исходным кодом, размещенная на Github . Отличительной особенностью этой библиотеки является то, что она позволяет нам создавать переключатели функций в нашем коде в течение нескольких минут.
Использование этой библиотеки также имело несколько недостатков. Поскольку это просто библиотека, у нее нет пользовательского интерфейса для создания или изменения переключателей функций. Он также не имеет функции для передачи переключателей функций из веб-браузеров с использованием параметров запроса или файлов cookie, что чрезвычайно полезно для проверки определенного состояния ваших переключателей. Еще одна вещь, которая отсутствует, это метаданные о том, когда и кто изменил состояние переключателей, что действительно полезно для отладки и судебных целей. Тем не менее, немного поработав над созданием этих инструментов, библиотека возможностей отлично подошла для запуска и запуска, и мы смогли развернуть наш код в нашей работе с новой функцией, отключив ее, а затем включив ее для тестирования или демонстрационных целей. ,
Начав использовать функциональные переключатели, мы поняли несколько непредвиденных преимуществ. Во-первых, если мы обнаружим какие-либо проблемы с новой версией кода, мы можем просто вернуться к старой версии, переключив переключатель. Нам больше не нужно было выполнять развертывание с откатом или с возвратом, чтобы исправить ошибку в процессе производства.
Еще одним большим преимуществом было то, что это сводило к минимуму конфликты окружающей среды. Поскольку наша команда все еще относительно мала, у нас только одна тестовая среда. Используя функциональные переключатели, каждый может объединить и развернуть свои изменения в промежуточной среде и просто включить «функции», которые он хочет протестировать, установив файлы cookie в своем браузере.
Мы также начали использовать переключатели функций как способ переключения функций без простоев. Поскольку мы используем микросервисную архитектуру, у нас есть несколько систем, которые все общаются друг с другом. Ранее, если бы нам нужно было развернуть новую функцию, которая требовала связи между несколькими системами, нам пришлось бы отключить все связанные системы и развернуть все соответствующие изменения кода, прежде чем восстанавливать системы. Но с помощью переключателей функций мы смогли развернуть каждое изменение системного кода, когда оно было готово, а затем просто синхронизировать, чтобы включить новые функции. По сути, это избавило от необходимости иметь сложные сине-зеленые развертывания, поскольку мы просто управляли всем этим с помощью переключателей функций.
Однако использование переключателей обходится дорого, хотя я чувствую, что цена определенно оправдана. Во-первых, не все наши разработчики были в восторге от того, что во всем коде валялись временные операторы if / else. Они чувствовали, что это добавляет дополнительную сложность в код и в модульное / интеграционное тестирование. Мы начали разрабатывать некоторые передовые практики, касающиеся переключения функций, и обновили процесс разработки, включив в него правильное удаление уже развернутых функций. В то время как модульное тестирование стало более сложным, общая сложность нашего процесса была упрощена. Нам больше не требовалось столько ненужных функций и веток слияния, а развертывание и процесс стали проще, как я упоминал ранее.
В целом, я бы сказал, что использование переключателей функций было отличным инструментом в нашем наборе инструментов и имело существенные положительные преимущества для нашего процесса разработки. Несмотря на то, что мы использовали библиотеку с открытым исходным кодом и увеличили необходимые нам инструменты, такие инструменты, как LaunchDarkly (которых не было, когда мы начинали), вполне могли бы привести нас туда, где мы должны были быть намного быстрее, предоставив нам все инструменты, которые мы должны были построить с нуля, и поддержка, которой у нас не было.