Среды разработки в Slack
В этой статье под средами разработки понимаются "песочницы", в которых можно протестировать изменения кода перед развертыванием, и их не следует путать с интегрированными средами разработки (IDE), такими как Eclipse или Microsoft Visual Studio.
Среда разработки всегда была для меня загадкой. Несмотря на то, что я узнал о них в первый день работы в Slack и использовал их почти каждый день в течение последних трех лет, я никогда не понимал, как они действительно работают.
Полгода назад я поставил цель понять среду разработки изнутри и снаружи. Я взял интервью у некоторых из самых старших инженеров Slack, изучил бесчисленное количество страниц документации и просмотрел многолетние разговоры о Slack. Я обнаружил увлекательное путешествие о том, как наша среда разработки развивалась с течением времени.
Зачем нам нужны среды разработки?
Среды разработки - это копии нашего приложения, которые мы можем свободно изменять. Их основная ценность заключается в том, что они позволяют нам тестировать изменения в нашем приложении, не затрагивая реальных пользователей и не подвергая опасности реальные данные.
Они позволяют нам быстро выполнять итерации, потому что на них можно быстро и легко протестировать изменения. Они также позволяют нам легко делиться нашими изменениями с другими для проверки.
В целом среды разработки резко увеличивают скорость разработки и безопасность.
Что лежит под капотом?
Среды разработки Slack - это копии нашего приложения, которые находятся на удаленных серверах, а точнее, экземплярах Amazon EC2. Эти экземпляры настроены для запуска приложения Slack и многих служб, от которых оно зависит.
Каждая среда разработки содержит свой собственный поддомен Slack, к которому мы можем перейти в нашем браузере, чтобы увидеть вносимые нами изменения.
Никакие изменения в среде разработки не могут повлиять на реальных пользователей, поскольку они используют собственный набор инфраструктуры (например, базы данных), изолированную от производства.
Разработка удаленно или локально
В Slack мы разрабатываем удаленно, то есть наши среды разработки находятся на серверах. Другой вариант - локальная разработка на наших персональных компьютерах. Местная разработка отлично подходит для небольших проектов, потому что она быстра и не требует подключения к Интернету. Однако для более крупных проектов среды удаленной разработки предлагают значительные преимущества.
Во-первых, нам не нужно настраивать приложение Slack локально. Учитывая, что Slack имеет очень сложную архитектуру, которая зависит от множества различных сервисов, отсутствие необходимости настраивать их локально очень ценно.
Во-вторых, если изменение работает в разработке, оно, скорее всего, сработает в производственной среде, потому что наши среды разработки настроены для зеркалирования производственной среды. Некоторый уровень дрейфа все еще может происходить с особенно долгоживущими средами разработки, но вероятность и величина намного меньше, чем при локальной разработке с использованием уникальных машин, которые часто заканчиваются несовместимыми конфигурациями.
В-третьих, удаленные среды разработки не полагаются на персональный компьютер, который может давать сбой или отставать. Облачное оборудование намного доступнее, устойчивее и масштабируемо. Кроме того, они позволяют нам легко разрабатывать на нескольких машинах и делиться своей работой с товарищами по команде для просмотра.
По мере того, как Интернет становится все быстрее и надежнее, имеет смысл разрабатывать удаленно.
Как мы используем среды разработки в Slack
Лучший способ проиллюстрировать рабочий процесс среды разработки Slack - это пример.
Допустим, по какой-то причине мы хотели протестировать версию домашней страницы Slack с заглавными буквами фиолетового цвета и текстом Comic Sans.
Сначала мы создаем ветку функций, а затем присоединяем ее к среде разработки с помощью инструмента командной строки под названием slack sync-dev. Он резервирует случайную среду разработки, а затем синхронизирует с ней наши локальные изменения, поэтому любые локальные изменения, которые мы сохраняем, автоматически переносятся в среду разработки.
По своей сути slack sync-dev - это просто оболочка для двух хорошо известных утилит - fswatch (обнаруживает изменения) и rsync (передает изменения).
Если мы вносим какие-либо изменения в интерфейс, мы должны собирать их локально, используя webpack, инструмент с открытым исходным кодом, который мы приняли в качестве нашей системы сборки. Команда slack run buildy:watch создает наши ресурсы внешнего интерфейса и передает их нашей среде разработки через localhost.
Когда мы закончим, мы можем перейти к субдомену dev575 и вуаля! Взгляните на наш фиолетовый шедевр.
Теперь мы можем искать на странице ошибки, настраивать наши изменения и делиться ими с другими для проверки.
Помните, что изменения в нашем интерфейсе создаются и обслуживаются с нашего персонального компьютера? Если мы хотим, чтобы другие могли видеть их после того, как мы закроем наш компьютер, мы должны сгенерировать статическую сборку, которая строит наши ресурсы внешнего интерфейса в нашей среде разработки, а не локально.
Почему мы вносим изменения в интерфейс локально?
Когда мы впервые представили webpack в 2017 году, мы удаленно вносили изменения в интерфейс в наших средах разработки. Каждый раз, когда кто-то вносил изменения в интерфейс во время синхронизации, среда разработки автоматически перестраивала их ресурсы.
Однако по мере роста нашей кодовой базы webpack становился более ресурсоемким. Одна сборка потребляла бы память всего экземпляра. В то время несколько разработчиков работали над одним и тем же экземпляром, и их работа постоянно прерывалась. Итак, мы переместили webpack на наши локальные машины.
Имея сегодня только одну среду разработки на каждый экземпляр и с более продвинутыми экземплярами, было бы вполне возможно перенести веб-пакет обратно в наши среды разработки, что сделало бы опыт разработчика немного более плавным. Но текущая система быстрая и масштабируемая, поэтому мы не чувствуем необходимости исправлять то, что не сломалось.
Улучшение наших инструментов командной строки
Давайте поговорим об инструментах командной строки на секунду. Мы уже рассмотрели некоторые из них, например slack sync-dev. В Slack мы не можем жить без них, потому что они делают разработку намного быстрее и проще.
Вначале, когда у нас не было slack sync-dev, нам приходилось вручную копировать наши изменения в среду разработки, которая была медленной и подверженной ошибкам. Теперь у нас есть более 60 инструментов командной строки, которые упрощают много обыденных задач, подобных этой.
Другие примеры включают slack bot-me, который создает пользователя-бота в текущей среде разработки, и slack tail-dev, который отслеживает удаленные журналы из нашей текущей среды разработки. Если вы хотите узнать больше о наших инструментах для разработчиков, ознакомьтесь с нашим сообщением в блоге за 2016 год.
Масштабирование среды разработки
Еще в 2014 году у нас была только одна среда разработки, которую использовали все. Если один человек сломает его, никто другой не сможет проверить его изменения. Тогда это не было большой проблемой, но по мере роста Slack нам пришлось добавить больше. К концу 2019 года мы поддерживали 550 сред разработки, этого достаточно, чтобы каждый инженер Slack мог подключиться к другому.
Однако эта растущая тенденция не продолжилась и фактически полностью изменилась в 2020 году. Прежде чем мы поговорим о том, почему, давайте сначала взглянем на еще одну интересную метрику, которая изменилась со временем: количество сред разработки на экземпляр EC2.
Это число со временем упало, потому что мы хотели изолировать среды разработки друг от друга. Когда несколько сред совместно используют один и тот же экземпляр, один разработчик, запускающий процесс с большим объемом памяти в одной среде, замедлит работу всех остальных.
Однако есть компромисс - меньшее количество сред разработки на инстанс означает, что мы должны платить за большее количество инстансов EC2. Кроме того, управление этими экземплярами осуществлялось статически, поэтому требовалось много часов инженеров для подготовки новых и деинициализации поврежденных. Что еще хуже, долгоживущие экземпляры со временем поглощались и перестали вести себя надежно.
Чтобы решить эти проблемы, мы создали новую систему для предоставления экземпляров разработчика по запросу. Это вызвало резкий разворот восходящего тренда, показанного на первом графике. Вместо того, чтобы поддерживать одновременную работу сотен экземпляров, мы предоставляем новые экземпляры, когда это необходимо. Когда разработчики завершают тестирование, их экземпляры автоматически деинициализируются. Благодаря этой системе мы можем более эффективно использовать среду разработки. Мы расскажем об эволюции масштабирования в одном из следующих постов, так что следите за обновлениями!
Хорошо спроектированная среда разработки имеет решающее значение для успеха любой технологической компании. Здесь, в Slack, наши среды разработки и наша инструментальная инфраструктура в целом вступают в захватывающий этап масштабирования и автоматизации - присоединяйтесь к нам, чтобы построить это будущее.
Огромное спасибо Россу Хармсу, Феликсу Ризебергу, Тито Сандовалю, Харрисону Пейджу, Мелиссе Хуат, Кефану Се, Шеннон Бернс, Нолану Кодиллу, Мэтту Хоги и многим другим за помощь в исследованиях и редактировании.
Автор
Майкл - инженер-программист в команде платформы Slack. Он проработал в Slack почти 3 года, и за это время он работал над широким спектром проектов, включая пользовательские функции, инфраструктуру API и эксперименты по развитию.
