Как заниматься парным программированием, если коллеги сидят поодиночке в разных квартирах? И если не подозвать коллегу со словами «смотри, как это делается», с помощью чего записать для него скринкаст? А какие инструменты для тестирования особенно актуальны при удалёнке?
Весной на TechTrain это обсудили Всеволод Брекелов (vbrekelov) и Артём Ерошенко (eroshenkoam). Им близок мир тестирования, поэтому получился уклон в эту сторону, но упомянуто и много универсального. Зрителям обсуждение понравилось — поэтому теперь мы сделали его текстовую расшифровку.
Если вы знаете, какие ещё инструменты стоило бы упомянуть, то расскажите о них в комментариях. А мы тем временем готовим следующий TechTrain: это бесплатное IT-мероприятие, которое пройдёт онлайн уже 18 сентября (в следующую субботу). Так что если этот материал вас заинтересует, то и на новые доклады стоит обратить внимание.
Как жить дальше?
Шёл 2020 год. Январь. Никто не подозревал о надвигающейся угрозе. Коалиция бактерий во главе с коронавирусом уверенно приближала апокалипсис. Софтверные компании ещё даже не начинали готовиться к войне. И это было их ошибкой.
Вирус обрушился на индустрию в апреле. Сначала мы потеряли возможность выпить имбирного смузи с печёной ватрушкой. Потом канули в Лету спортзалы и бассейны. Офисы стояли до последнего. Но и они сдались. В конце мы потеряли офлайн.
На дворе был июнь. Несколько крупных компаний во главе с Zoom объединились, чтобы спасти IT. В будущем об этой битве будут слагать легенды…
А мы эти легенды воспоём.
Артём: Я занимаюсь автоматизацией тестирования уже больше 10 лет. Работал в крупных компаниях (например, Яндекс). Сейчас занимаюсь консалтингом и являюсь сооснователем компании Qameta Software, которая делает систему управления тестированием.
Всеволод: Я уже больше 10 лет работаю в IT. Занимался автоматизацией тестирования, разработкой и менеджментом. Сейчас работаю в компании Synthesized в качестве Engineering Lead, где мы умеем синтезировать очень большие данные.
Артём: Да, это довольно популярная тема сейчас с учётом того, что данных для тестирования надо всё больше и больше. Я уверен, что когда-нибудь твой спич на Heisenbug будет очень интересен.
Сегодня я хочу поговорить с вами про удалёнку. Сева, как у тебя прошёл переход на неё? Что в твоей жизни изменилось с приходом удалёнки?
Всеволод: У меня не получилось перейти на удалёнку сразу, как у всех. Я на неё перескакивал постепенно. Поначалу у меня были ощущения, что удалёнка — это классная тема и не нужно никуда ездить. Потом на меня нахлынуло, что я работаю с утра до ночи из дома, и почему-то всё время митинги, и ты не можешь даже пойти поесть. А потом я более или менее настроил для себя весь сетап (включая свет для видеосвязи), пытаюсь сделать меньше митингов и пользуюсь инструментами, которые помогают настроить работу в команде, чтобы меньше синхронизироваться в реальном времени.
Артём: Об этих инструментах мы и поговорим.
Если говорить про меня, то мой переход на удалёнку прошёл довольно легко. Во-первых, я почти всё время и так мог работать на удалёнке. И в этот раз практически ничего не изменилось. Я и правда стал меньше ходить в офис. Я тоже стал смотреть на инструменты, которые обеспечивают коллаборацию в команде. Если говорить про нашу команду, то у нас получается примерно так: вторник, среда и четверг — те дни, когда можно прийти в офис, чтобы что-то обсудить. Обычно мы их используем, чтобы плотно поштурмить; остальные дни работаем из дома.
Мы добиваемся движения вперёд за счёт использования инструментов, о которых и пойдёт речь. Хочется рассказать, как из состояния «как жить» перейти в состояние, когда у вас настроенные процессы, для всех всё прозрачно и т. д.
Как дальше планировать?
Артём: На удалёнке, на мой взгляд, планирование — одна из основных проблем. Когда я пять лет работал в крупной компании, больше всего времени мы уделяли именно планированию, где надо всем собраться. Было примерно так. Был офис Москва — Санкт-Петербург, и люди постоянно ездили в командировку, потому что там можно было дойти до человека ногами.
Всеволод: Это обычная история. С другой стороны, когда все начинают думать, что легко планировать на созвоне или заранее подготовиться, обычно это превращается в хаос. Довольно непросто это делать, скажем честно.
Miro
Артём: Сева хочет поделиться, как на проекте использует Miro.
Всеволод: Наверняка многие слышали про Miro и его используют.
В основном мы используем Miro для брейншторминга и планирования. У него есть крутая фича — интеграция с Jira или другими системами. Мы можем брать существующие шаблоны, например, шаблон для планирования проекта, и просто вставить. Если вам хочется что-то планировать или создавать задачи, то это делается так.
Мы с Артёмом решили рассказать на следующем этапе про инструменты погружения в код:
Есть задача, и мы хотим, чтобы её кто-то сделал. Как мы заводим эту задачу, чтобы точно был человек, который это сделает? Мы можем прямо из Miro сконвертировать наш проект из Jira:
Прямо здесь вы можете выбрать тип issue, приоритет задачи, ответственного человека. Все настройки, которые вы делаете в Jira, могут быть здесь. Также вы можете прилинковать эпик.
Мы конвертируем и получаем:
Задача, которую мы просто написали руками, превратилась в Jira-задачу, которая при этом будет показывать прогресс на этой доске.
Как понять, где эта задача? Кликаете сверху, и у вас сразу открывается Jira-проект, в котором заведена задача:
Она была выложена в бэклог, где я указан как исполнитель. Тут уже могу заассайнить на Артёма и добавить описание, что нужно сделать в этой задаче.
Это очень удобно, потому что вы ставите задачу всего за пару кликов. Условно вы напланировали что-то с командой и не хотите, чтобы каждый был Jira monkey. Вы можете передать эту задачу кому-то, и он все эти задачи сконвертирует.
Артём: Допустим, я использую Miro для разных задач, в том числе описываю структуру микросервисов, процессы и т. д. Получается, Miro используется как обычная маркерная доска, но при этом нужно показать менеджерам какой-то контроль. Они должны понимать, когда у нас будет что-то сделано, кто ответственный за эту задачу и т. д. Собственно, в Miro мы командой разработчиков сидим и планируем, потому что это удобно. А потом мы переключаемся на Jira, синхронизируем с ней все тикеты (а синхронизировать мы можем любые сущности вплоть до описания подсистемы) и т. д.
Calendly
Всеволод: Мы собираемся, планируем, и вопрос обычно стоит, как собираться. Тут наступает момент, как мы вообще организовываем встречи. Т. е. мы пишем обычно в Slack или Telegram «Тёма, я хочу с тобой поговорить на полчаса. Когда тебе удобно?». Ты смотришь в календарь и говоришь, что тебе удобно с 3 до 5. А я говорю, что мне удобно с 2 до 2:30. И получается, что сегодня никак, и дискуссия длится очень долго. Так, конечно, неудобно договариваться.
Артём: Да, у меня часто бывают созвоны с клиентами, и это головная боль. Я прямо в почте пишу «Когда тебе удобно?» и т. д., поэтому тебя понимаю. Было бы удобно иметь единое место, где мы можем планировать эти встречи.
Всеволод: Многие знают, что есть инструмент Calendly, который интегрируется с вашим календарём (Google, Apple и другие). И в нём вы настраиваете свою доступность:
У вас будет своя страница, которая публично доступна любому человеку, и он может зайти на неё и запланировать, например, 15-, 30- или 60-минутный созвон. Часто используется для саппорта, когда ты можешь связаться с какой-то компанией, но в целом сотрудники это тоже могут использовать.
Всё, что вам нужно, — скопировать ссылку, передать другому человеку, он переходит по ней, видит доступность вашего календаря, выбирает удобную дату и время и подтверждает:
Далее он уже набирает имя и пишет e-mail:
При этом он может добавить несколько гостей. Так можно организовать митинг за пару кликов. При этом важно не забыть про агенду, которую я обычно рекомендую писать для митингов, потому что без агенды митинги обычно заканчиваются ничем.
После того, как я запланирую мероприятие, приглашение приходит мне и человеку:
Выбранное время становится недоступно, поскольку всё обновляется в реальном времени.
Позже мы покажем, как сильнее интегрировать эти штуки в свой workflow.
Артём: Тема реально очень удобная. Я о ней узнал от зарубежных коллег, потому что надо было с ними синхронизировать митинги, и это становится адом. Особенно, если у вас разные часовые пояса.
Сейчас мы у себя активно внедряем Calendly. Как ты правильно сказал, мы используем его в саппорте.
Как дальше онбордиться?
Артём: У нас есть несколько проектов, и они непосредственно связаны с кодом.
Octotree
Всеволод: Онбординг происходит из-за того, что обычно все погружаются либо в код тестов, либо в код приложения. Я очень часто использую расширение Octotree для Chrome, которое умеет навигироваться.
Когда ты заходишь на GitHub, то можешь прямо в нём перемещаться, как в IDE:
При этом после обновления страницы всё остается на своих местах. Это удобно, потому что ты обычно перемещаешься между папками и переходишь к коду. Понятно, что и в GitHub есть Codespaces, с которым можно это делать. Но Octotree — это простой легковесный плагин, который позволит вам пробежаться по опенсорс-проектам и посмотреть код.
Code With Me
Всеволод: Code With Me — это плагин, который разработали в компании JetBrains. Аддон позволяет вам и вашему товарищу поработать над кодом вместе.
Чтобы узнать подробнее о Code With Me, посмотрите другой доклад TechTrain Spring 2021:
Кирилл Скрыган — Code With Me Behind the Scenes
Рассмотрим простую историю. Я пришёл на проект, и мне непонятно, где что писать. Я вроде неглупый парень, но там столько кода, что не очень понятно.
Вы нажимаете Enable Access и даёте полный доступ по ссылке:
Ссылка копируется, и вы передаёте её товарищу. Он может её открыть в браузере или прямо в IDE.
Самое интересное, в процессе организовывается созвон. И не надо никакого Zoom.
Артём: Кроме того, я могу выполнять код непосредственно в IDE Севы. И даже имею доступ к терминалу. Например, могу запустить тест и посмотреть, как он будет выполняться:
Всеволод: Один из кейсов — когда какие-то тесты не проходят. Артём может отдебажить вместе со мной, что у меня не так, и проверить настройки Java, Maven и другое.
Артём: Также можно использовать брейкпоинты. Это действительно очень крутой инструмент онбординга. В своё время я упустил информацию про него. Но сейчас мы занимаемся образовательной программой, где я преподаю в школе. И когда нужно один на один объяснить или показать что-то человеку, то Code With Me здесь идеален.
Как всё выглядит с моей стороны:
В процессе также можно переключаться между хостами.
Возможности Code With Me реально безграничные. И первый раз, когда Сева мне настраивал сетап, он не дал разрешение, и я не мог запускать код на его машине. Это было исключительно хождение по коду. Поэтому по умолчанию у вас будут настройки, которые запрещают это делать.
projector-docker
Артём: Projector представляет набор контейнеров, в каждом из которых запакована IDE, доступ к которой вы можете получить по порту. Грубо говоря, вы поднимаете вашу IDE в Docker-контейнере и можете скинуть кому-нибудь URL на неё и работать вместе.
Подробнее о Projector рассказал Паша Финкельштейн.
На мой взгляд, с приходом таких решений мощные компьютеры для разработки станут не нужны. Вы сможете просто поднять на мощной машине вашу любимую IDE и после этого работать с ней через веб-интерфейс.
Давайте сделаем это. Я сделал простенький docker compose-файл и запустил его:
Теперь нам надо попасть в порт 8887. Я беру свой IP-адрес и делаю доступ к порту:
У нас появляется IDE. Дальше я могу с ней работать как со стандартной IDE — например, изменить строку Hello, Kotlin! на Hello, Java!:
Я могу также выслать URL Севе, и он откроет на своём планшете:
Я могу менять код, и Сева видит это в реальном времени. То есть, грубо говоря, это одна и та же IDE.
Всеволод: Давай я изменю строку с Hello, Java! на Hello, Артем! и запущу код:
Наверное, хоткеи и прочее не так удобно будет настраивать. Но всё запускается, и вы можете хоть с телефона посмотреть, что вам показывают.
Артём: Если я сделаю git clone, скачаю и открою новый репозиторий, то он тоже отобразится на экране. То есть можно работать один в один, как у вас на локальном компьютере.
В одном из докладов я рассказывал про разработку IDE-плагинов. Когда я рассказывал про то, как можно расставлять аннотации над кодом на основе TMS-тестов, мне нужно было физическое действие. То есть мне надо было нажать на кнопку, потом выполнить действие. И мне задали вопрос, можно ли это спрятать в CI? Сейчас у нас есть Docker-контейнеры, и ничто не запрещает вашему плагину запустить логику в бэкграунде. Вы поднимаете IDE, она сразу же открывает ваш проект и выполняет логику по работе с проектом.
Основные критерии её использования:
- удалённая работа. Вы можете на маленьком компьютере совершать действия без необходимости в мощном железе;
- работа в команде. Вы можете поднять один Docker-контейнер и поработать над ним вместе.
Но Code With Me, мне кажется, сейчас реально интереснее, потому что он встроен именно в вашу IDE.
Всеволод: Когда кто-то сейчас онбордится, то можно использовать различные способы. Теперь показывать код человеку в реальном времени не требует больших усилий.
Артём: Мы можем к слову github в адресе репозитория дописать 1s, и у вас появится IDE:
Здесь JetBrains не монополисты. Например, в VS Code есть функция Live Sharing, которая появилась раньше. Круто, что тенденция идёт в этом ключе, и коллаборация становится проще. Многие вещи теперь можно сделать из удалёнки.
Как взаимодействовать дальше?
Всеволод: после того, как мы все запланировали и проонбордили, нам нужно как-то коммуницировать.
ngrok
Артём: Я использую ngrok для решения следующей задачи.
Например, я сделал какую-то разработку у себя локально и не хочу её пока деплоить. Я могу сделать новый макет, документацию и вывести какую-то новую ручку REST. Как мне её перенести другому человеку (Севе)?
Для этого у меня есть специальный репозиторий. Запущу документацию:
У меня стартует сайт, и мы видим документацию по моему продукту:
Здесь есть список изменений, которые мне нужно расшарить Севе:
Как видите, документация доступна только на localhost. Я запоминаю порт, по которому она доступна (в данном случае 1313), и в консоль пишу ngrok http 1313:
Ngrok создаёт внешний IP-адрес, по которому будет доступна моя документация, и она появляется в Интернете. Я могу в документации изменить какой-то файл, и люди будут сразу же видеть изменения.
До этого я использовал ngrok для тестирования интеграций, потому что я разрабатываю какую-то систему локально, а после того, как я изменил данные, надо извне протестировать интеграцию с GitHub. Мне приходит запрос с GitHub, и я делаю все штуки.
Monosnap
Артём: В последнее время я очень много работаю с документацией, и мне нужно записывать ролики к ней. Мы делаем фичу, и чтобы пользователю было понятно, что произошло, мы сразу же вставляем логику работы с нашим продуктом. Для этого я использую программу Monosnap:
Я могу выбрать, какую часть экрана снимать. Также я могу указать аудиодорожки, которые хочу снимать. Также я могу вставить видео прямо из веб-камеры, чтобы была видна моя реакция. Остаётся нажать кнопку Record, а затем после записи — Stop. Полученные видео я могу сохранить как в MPEG, так и в GIF.
ImageOptim
После записи я использую ImageOptim. В неё закидываю GIF и сжимаю без потери качества:
Мы с Севой ради эксперимента взяли доку Cypress, загнали все их файлы в ImageOptim и получили сжатие 20%. По сути, репозиторий теперь выкачивается на 20% быстрее.
Loom
Всеволод: Loom — это тоже инструмент для захвата экрана:
Можно выбрать запись экрана, запись веб-камеры или всё вместе. Также она умеет делать скриншоты.
Мне нравится в ней то, что когда вы делаете запись, у вас есть таймер, по которому вы можете успеть подготовиться. Также во время того, как вы пишете, у вас есть слева меню, с помощью которого вы можете спросить, что происходит в блоке кода:
После того, как мы записали видео, оно сразу открывается в облаке. Инструмент платный, но есть бесплатные возможности. И классно, что мы можем прямо в облаке посмотреть видео с ускорением или же его обрезать. Я сделал всего пару кликов и расшарил ссылку Артёму.
Но на мой вкус, самое полезное в Loom — это возможность оставлять комментарии.
Для того, чтобы коллаборировать, сейчас не обязательно созваниваться и можно использовать разные инструменты. Можно записывать видео с экрана, скриншоты. Можно в том числе с помощью ngrok делать трансляцию экрана или же показать заказчику свёрстанный макет, если не хотите заморачиваться с деплоем.
Как дальше писать тесты?
Артём: Автоматизация тестирования набирает обороты, и хочется рассказать про интересные подходы, которые здесь появляются.
Рассмотрим возможности инструмента QA Wolf:
Давайте напишем тест для https://techtrain.ru. Слева появляется код теста, а справа — непосредственно браузер:
Закроем уведомление, перейдём к программе, отмотаем программу до какого-то состояния и выберем «Какие тулы ты бы взял на удалёнку»:
Вот такой простенький тест. После этого мы можем его запустить, и у нас явно тест запускается. То есть это инструмент Record&Play.
На мой взгляд, это крутой подход. Единственное, раньше в QA Wolf можно было всё делать с помощью консоли, и он генерировал тесты локально. Сейчас они сделали такую обёртку, что, на мой взгляд, спорное решение. Понятно, почему они делают — у них появилась вкладка Pricing. Но изначальная логика, по мне, была правильнее. Надо дать пользователям возможность писать тесты либо в их среде разработки, либо в другом месте.
Playwright
Артём: Инструмент, собственно, работает также. Но его отличительная особенность заключается в том, что он умеет отдельно генерировать Playwright-тесты.
Всеволод: Так как Playwright портируется на разные языки, он на самом деле умеет в своём окне генерировать код не только на JS, но и на Python, C# и скоро на Java.
Дополнительная информация о Playwright — в посте Севы и докладе Андрея Лушникова с Heisenbug.
Артём: Если говорить про будущее веб-тестирования, то оно точно за подобными инструментами генерации кода, поскольку экономит кучу времени. И полгода назад, когда мы тестировали QA Wolf, к нему было много вопросов. Например, если вы начинаете typed-тесты, то он делал несколько type. Сейчас же он всё схлопывает, и инструменты сильно «поумнели».
Как дальше считать тесты?
Артём: С появлением большого количества тестов всё чаще возникает вопрос: как понять, что у нас вообще тестируется, а что — нет?
Swagger-coverage
Артём: Первый инструмент, который я хочу вам показать, — Swagger-coverage. По нему мне часто пишут в личку «спасибо за этот тул».
Подробнее о Swagger — в посте Виктора Орловского на основе доклада с Heisenbug.
У нас есть petstore — default-сайт для тестирования, и в нём мы видим ручки, которые у нас есть:
Это стандартная Swagger-документация.
Мы пишем наши тесты и не понимаем, какие API-ручки и с какими данными покрыты, а какие — нет. Для того, чтобы это поднять, я написал тест, где буду дёргать ручку /pet/{id}:
Я ожидаю, что получу правильный ответ. Я сначала создаю pet, а затем проверяю, что по такому ID у меня мой pet и создан. Запускаем тест и смотрим отчёт:
По итогу мы получили, что:
- у нас нет ни одной ручки, которая покрыта на 100%;
- 10% ручек покрыто частично;
- 90% ручек не покрыто.
Если посмотреть вглубь, то увидим, что мы как раз вызывали ручку POST и проверяли это с определёнными данными:
И потом мы вызывали ручку GET, где проверяли код 200:
С помощью Swagger-coverage вы можете быстро понимать, что у вас покрыто. Работает он следующим образом.
У вас есть Swagger-документация. Во время выполнения тестов тул запоминает, какие ручки с какими значениями были вызваны. И потом Swagger report строится на основе разницы между тем, по каким ручкам мы пробегали, и Swagger-документацией. Получается красивое отображение, в котором вы сразу же видите, что у вас покрыто, и можете легко планировать ваше тестирование.
Reqover
Артём: Есть аналог Swagger-coverage — Reqover. Инструмент взаимодействует примерно так же, но его отличие в том, что это Docker-контейнер. То есть если там статический report, и этот report на файлах, то здесь вы видите Docker-контейнер, который снимает данные в режиме реального времени.
Мне кажется, оба инструмента не конкурируют, а скорее дополняют друг друга. При этом если вы зайдёте и запустите Reqover, то у него будет похожая вёрстка report, как у Swagger-coverage.
Allure TestOps
Артём: Ещё один инструмент, о котором хочется рассказать, — Allure TestOps, над которым работаю я. Основная его идея в следующем. У нас есть много тестов, которые написаны на разных языках. Они помечены аннотациями:
Да, это немного больно размечать, но современные end-to-end тестировщики научились делать тут всякие вещи. Мы видим, какой микросервис наш тест проверяет, какая issue проверяется и т. д.
Запустим наши тесты из задачи Jenkins:
И они отображаются в общей системе:
Отсюда мы можем сразу же перезапустить тесты:
При этом у нас перезапустятся именно автотесты, задача перезапустится ещё раз, а последние два теста не запустятся.
У нас есть общее представление всех тестов внутри проекта и компании. Мы можем быстро посмотреть, какие у нас есть API-тесты, UI-тесты, тесты на конкретную issue (если надо посмотреть, какие тесты запускаются):
Также там есть интеграция с Jira и т. д. То есть Allure TestOps — некая база тестов.
Кроме того, есть дашборды, где вы можете посмотреть, сколько автотестов есть у каждого сотрудника, каждой команды на каждую конкретную фичу и т. д.:
Allure TestOps позволяет собрать всю автоматизацию тестирования в одном месте, знать, какие тесты есть, кто их написал, как часто они запускаются и т. д.
Как дальше тестировать сайт?
Всеволод: Мы уже подходим к таким инструментам, которые можно встраивать как плагины или расширения в Chrome.
Web Developer Checklist
Всеволод: Одно из таких расширений разработала компания Toptal — Web Developer Checklist. Он делает примерно то же самое, что и Lighthouse. Он выполняет проверку веб-страницы вашего сайта на разного рода метрики. Например, насколько у вас accessible-сайт, нормально настроен SEO, хорошо открывается в мобильных приложениях и т. д.:
Мы можем посмотреть, что не так, и инструмент предлагает решение проблем.
Lighthouse
Всеволод: Многие слышали про Lighthouse, но тем не менее хочется о нём рассказать, чтобы у вас был джентльменский набор из разных инструментов.
Lighthouse встроен в Chrome Web Tools. Соответственно вы можете сделать некий тест вашего веб-приложения. Вы выбираете, какие категории тестов вы хотите провести:
- Performance;
- Progressive Web App;
- Best Practices;
- Accessibility;
- SEO.
Как только вы запускаете тесты, Lighthouse перезагружает ваш сайт, и вы получаете отчёт по метрикам:
Артём: Это реально прикольный инструмент, о нём знают все фронтенд-разработчики, но не все тестировщики.
Многие сейчас делают персональные блоги и сайты. И эти инструменты позволяют иметь роботизированного компаньона.
Всеволод: Тут точно так же есть подсказки. Если у вас проблемы с кодом, то Lighthouse пишет, что нужно подменить:
Slack-боты
Всеволод: Я думаю, многие используют Slack. У нас есть бот Alice:
Он нам говорит: «Ребята! У вас должен был быть стендап в 2:45, то есть через пять минут». Мы хотим синхронизироваться с Тёмой и отвечать на 4 простых вопроса:
- Что мы вчера сделали?
- Что мы собираемся делать сегодня?
- Когда мы планируем завершить задачи?
- Какие есть блокеры?
Артём: Получается, что кто-то берёт на себя роль человека, который всех пинает. И как человека, который постоянно делает стендапы, меня это немного напрягает. И этот бот решает проблему.
Всеволод: Также есть интеграция с Calendly. Я могу создать событие и предложить Артёму созвон, например, на 15 минут. В асинхронное время Артём может зайти и запланировать со мной звонок.
Точно так же сделана интеграция с Jira. Вы можете получать репорты, какие задачи вам нужно сделать, кто что уже сделал и т. д.
Также имеется интеграция с Loom, который мы показывали ранее. Понятно, что видео могут проигрываться по внешней ссылке, но вам захочется, скорее всего, смотреть прямо в Slack. Здесь он подгружает весь интерфейс видеоплеера Loom без необходимости переключаться на другие инструменты.
Поэтому вы можете посмотреть, какие инструменты используете, и, возможно, найти интеграцию со Slack. Они упростят вашу жизнь и уменьшат переключение между контекстом.
Артём: Так или иначе Slack завоёвывает рынок (хоть Teams и начинает активно отвоёвывать часть рынка) за счёт таких интересных интеграций. Ждём, когда внутри Slack можно совершать различные действия, например, перезапускать тесты, проводить код-ревью и т. д. Тогда это будет единая платформа, куда будут присылаться события.
Как жить дальше?
Артём: Если вы знаете ещё какие-то инструменты, то делитесь с нами. Мы обязательно их попробуем и расскажем в будущем.
Напоследок напомним: это расшифровка выступления с бесплатного онлайн-фестиваля TechTrain, и уже 18 сентября состоится следующий TechTrain. На сайте уже есть описания многих докладов, так что смотрите, будут ли интересные для вас.
