Боты используются по всему Интернету, а также внутри компании. Существует множество специализированных ботов, которые ориентированы на одну задачу по управлению. То же самое происходит и в SoftwareMill: мы запускаем несколько ботов, для поддержки наших внутренних процессов, таких как найм, управление каналами Slack или даже совладание с настроением членов команды в определенный день.

Тем не менее, каждый бот достигает своей даты окончания и должен быть удален.

Разработка ботов

Существует множество инструментов для разработки ботов, каждая коммуникационная платформа предоставляет кучу подходящих API, примеров и готовых к использованию артефактов. Это также означает, что не существует единой стратегии замены бота более новой, блестящей версией.

Поскольку SoftwareMill это 100% удаленная компания, мы используем Slack в качестве основы для всех наших внутренних и внешних коммуникаций. Кроме того, все наши боты используют Slack в качестве основного средства связи. Давным-давно, в 2014 году, я запустил нашего первого бота с помощью проекта Hubot под названием Janusz The Bot (у Януша есть отсылки к шуткам в Польше ;-). Вскоре после этого мы решили поддержать наш процесс найма, используя другого бота, того же Hubot в качестве базы, под названием Halinka The Bot (еще одна отсылка к шутке).

Оба бота были тщательно разработаны в те дни и нагружены множеством функций. С ростом нашей компании процесс найма также развивался, но использование выделенного экземпляра бота для управления процессом позволяет нам поддерживать поэтапные изменения. Другой экземпляр бота также был загружен бесценными забавными функциями, такими как приготовься или напоминания в стиле CRON. Были и другие полезные вещи, такие как возможность добавить кому-то престижность или поддержать 4-й вопрос, заданный на собраниях нашей компании.

Новое идет

С ростом компании также увеличивалось количество каналов в нашем Slack, мы решили ввести политику в отношении того, как каналы должны называться, какое описание необходимо и как долго канал может быть неактивным. Чтобы контролировать все эти требования, мы разработали еще одного бота — Woźny. Бот использует новый фреймворк BoltJS Slack. Мы уже знали, что Hubot когда-нибудь будет выведен из эксплуатации, и нет смысла вкладывать в него время.

Был введен еще один бот, чтобы частично покрыть область настроения сотрудников, а также взять на себя некоторые функции от других ботов, поскольку мы уже знаем, что некоторые функции больше не будут использоваться, а некоторые все еще нуждаются в поддержке на определенном уровне.

Так появился Aniela The Bot, использующий фреймворк BoltJS с поддержкой Typescript.

Подготовка к изменению

Как только мы начали разрабатывать новых ботов с использованием нового фреймворка, мы также должны были подготовить пользователей. Они должны знать, как плавно начать использовать нового бота и его команды вместо старого. Это добавляет дополнительную работу, так как в то же время вы все равно должны поддерживать оба экземпляра.

Чтобы быть еще безопаснее и лучше подготовиться к внедрению новых или переписанных функций, мы начали использовать выделенный экземпляр тестового бота, который позволяет нам запускать код локально и взаимодействовать с ним напрямую через Slack. Все это стало возможным, потому что новая платформа Slack предпочитает режим WebSocket вместо устаревшего API обмена сообщениями в реальном времени.

Так или иначе, после разработки небольшой части функционала — скажем, добавления нового 4-го вопроса в стопку, которая ранее поддерживалась командой в Janusz The Bot, в этот раз мы использовали команды Slack Slash для взаимодействия с новым ботом. Протестировав новую слэш-команду с тестовым ботом, мы смогли начать использовать ее в продакшене, но о самой команде никто не знал :D

Нам пришлось сообщить пользователям, что вместо использования старого синтаксиса @Janusz 4th add ... они должны использовать новую команду косой черты /4th_add, и очевидным выбором было сообщить им об этом непосредственно Янушу. Поэтому мы изменили код в Janusz, чтобы сообщать о новой команде косой черты каждый раз, когда кто-то попытается использовать старую команду — не высшая математика, но позволяет пользователям легко переходить от использования одного инструмента к другому.

Используя этот подход, мы можем информировать пользователей о новых функциях, заменяющих старые, и выполнять пошаговую миграцию, не отвлекая пользователей. Пользователи ненавидят изменения, поэтому вы должны быть осторожны при их введении.

Заключительное слово

Не стоит бояться возможных миграций, это непростая задача, поэтому подготовка плана имеет смысл (даже если вы не будете ему следовать). Ориентация на пользователей — самая важная часть всего процесса. Спутав их с новыми функциями, не давая намека на то, что происходит, или избегая дополнительной работы только для того, чтобы сэкономить деньги, вы вдвойне ударите по себе в будущем. Системы и программы постоянно меняются, и переход от старой версии к новой является естественным делом в цифровом мире.

Просто держите своих пользователей в центре внимания.

Первоначально опубликовано на https://softwaremill.com 4 ноября 2022 г.