Подводим итоги митапа по опыту применения DevOps-практик

Сезон митапов Инфостарта в 2022 году открыт! В пятницу 18 февраля прошел первый митап года – он был посвящен опыту применения DevOps-практик в командах разработки на 1С. Рассказываем о ходе мероприятия, итогах опроса, и о том, какие вопросы круглого стола вызвали самое живое обсуждение участников.

Актуальная тематика

Мероприятие проходило бесплатно – любой желающий мог зарегистрироваться на вебинар и подключиться к трансляции в Zoom.

Всего на мероприятие зарегистрировалось 1355 человек – участники активно дискутировали в чате, и за время митапа модераторы зафиксировали более 130 вопросов от слушателей к докладчикам (не считая вопросов, которые задавались вслух на круглом столе).

Дискуссия по проблемам внедрения DevOps-практик вышла очень конструктивная и интересная – участники не хотели расходиться, поэтому вместо планируемых 15:20 круглый стол завершился на час позже, в 16:30.

Результаты опроса по использованию DevOps-инструментов

Перед началом митапа модераторы провели опрос по использованию DevOps-инструментов, в который вошло 8 вопросов. Своим мнением поделился каждый шестой из тех, кто зарегистрировался на митап – всего удалось собрать ответы с 236 респондентов.

Делимся с вами результатами опроса.

До сих пор подавляющее большинство традиционно использует конфигуратор в качестве основной среды разработки – так ответили 89,4% всех опрошенных. EDT – на втором месте. Некоторые используют два инструмента сразу.

Командную разработку большая часть респондентов (45,9%) ведет в классическом хранилище.

Если сравнивать результаты этого вопроса с аналогичным опросом, проведенным в мае на конференции Infostart Event 2021 Post-Apocalypse, то ситуация почти не изменилась – классическое хранилище все еще пользуется популярностью

По поводу инструментов CI/CD большинство респондентов ответили, что пока еще не используют ничего. Среди остальных опрошенных в явные лидеры выбились Jenkins и GitLab CI – эти три пункта вырвались вперед с большим отрывом.

Еще более абсолютной оказалась ситуация с использованием инструментов контейнеризации. Пока еще их использует меньшинство – в частности, только один человек ответил, что использует 1С в Docker на проде

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

Что касается автоматизации развертывания, то большинство выполняет развертывание все еще вручную – в этом аспекте доверять полной автоматизации, наверное, еще рано.

И на вопрос «Как часто приходится откатываться» большинство ответили, что откатываются крайне редко, и всегда идут вперед. В крайнем случае, делают хотфиксы.

Итоги обсуждения на круглом столе

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

1. Какие организационные/технические подходы/лайфхаки коллективной разработки применяются при интенсивном производстве большого количества изменений в день от разных разработчиков.

Начать надо с организационных изменений – не выдавать разным исполнителям задачи по одному макету, форме и т.д. Если есть возможность, делить эти задачи, чтобы не было пересечений.

Далее – нужно использовать правильные инструменты мержа. Если есть возможность – мержите в EDT. Если нет возможности – работайте через Git, его сила как раз в том, что он хорошо разруливает конфликты. А конфликты есть всегда, и это не очень страшно, просто нужно помнить, что могут быть проблемы с XML-файлами форм – поэтому, если вы видите, что конфликты могут поломать форму, используйте конфигуратор.

Еще один технический лайфхак для тех, кто дорабатывает типовые – писать код в расширениях, чтобы иметь возможность разрабатывать согласно стандартам, используя правильное разбиение модулей и т.д. Только не нужно делать мега-расширения, которые опять же станут узким местом.

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

Все это можно разрулить за счет тегов. Когда разработчик что-то меняет, он не работает над всей конфигурацией сразу – он дорабатывает один кусочек теста. Он пишет тесты на задачу, ставит на нее вручную какой-то тег и, когда он запускает этот полноценный пайплайн, но не все тесты, а для проверки только своего, ограничивая тегами отбора. И пайплайн, запускаемый при пуше изменений этим разработчиком нужно настроить так, чтобы он запускал только тесты конкретно с этим тегом.

А когда будет сделан мерж-реквест, тогда уже надо прогонять все тесты. Но именно на этапе разработки, чтобы получить быструю обратную связь, нужно пользоваться отбором по тегам – это хорошая практика.

При использовании EDT нужно использовать ветки и какой-либо популярный процесс разработки, например, Github Flow, который четко регламентирует, как что в какой последовательности нужно делать. В случае, пока тестируется только что закоммиченный функционал, в Git делаешь по процессу отдельную ветку и пишешь в ней код по другой задаче. С другой ветки прилетела ошибка – сохранил, переключился на старую ветку, исправил код. А если у тебя есть еще и строгая типизация и подсказка 1С:EDT, то ты в большинстве случаев можешь пофиксить даже без запуска рантайма

3. Какие подходы и инструменты применяются для реализации «долгоиграющих» фич?

В первую очередь, надо стараться декомпозировать. Если не получается, то разработчик должен часто обновляться, интегрировать изменения, которые уже приняли в мастер, к себе – ежедневно начинать свою работу с того, что обновляться из мастера.

4. Автоматический деплой на продуктовом сервере – зло или все-таки необходимость?

Автоматизированный – нужен, а автоматический – нет. Правильнее реализовать деплой «по кнопке». Единственное, что возникают нештатные ситуации с зависшими соединениями, когда приходится делать перезапуск кластера и дальше уже дообновлять руками. А сам процесс при удачном стечении проходит полностью автоматизированно.

Оценки докладов

Модераторы митапа Артур Аюханов и Александр Кунташов отобрали для выступлений на митапе пять докладчиков, в число которых вошли как признанные лидеры DevOps-движения, так и «новые лица». Все выступления оказались очень интересными – доклады вызвали активное общение в чате и конструктивные вопросы к спикерам.

Выступления Сергея Голованова и Дмитрия Шерстобитова слушатели оценили практически одинаково высоко – их доклады оказались самыми доходчивыми и яркими впечатлениями встречи. Еще одним из самых полезных выступлений митапа стал доклад «новичка» наших мероприятий Андрея Истомина. Все спикеры по итогам оценок зрителей получили поощрительное денежное вознаграждение.

Средние оценки по итогам голосования мы собрали в единую таблицу рейтинга.

Лучшие вопросы докладчикам

По итогам встречи модераторы определили лучшие вопросы от участников – их авторы получили доступ к курсу DevOps для 1С. Причем, в этот раз победителями розыгрыша стало сразу два вопроса, которые набрали одинаковое количество голосов от спикеров:

Артур Аюханов отметил вопрос Максима Гончарова, который прозвучал в рамках выступления Максима Савельева: «Сколько времени ушло до того момента, когда всё наладилось, все шишки набили?»

А Дмитрий Шерстобитов посчитал самым лучшим вопрос Счетчикова Алексея, адресованный ему после выступления: «У вас нет команды? Т.е. разработчики и QA инженер отдельно живущие сущности? Если в команде, то о каком недоверии можно говорить?»

По мнению Дмитрия, когда команда – одна большая семья, это, по факту, плохо, потому что люди начинают прощать другим участникам команды ошибки и страдают из-за этого сами. В реальности же QA-инженер не должен верить программисту, потому что у них разные задачи – у программиста задача, чтобы его фича попала в прод, а у QA-инженера задача, чтобы прод из-за этой фичи не сломался. На стыке их «войны» и рождается релиз.

Просим Счетчикова Алексея отписаться в комментариях к новости, мы подключим его к курсу.

Материалы мероприятия доступны владельцам абонемента на странице вебинара

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

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