Что мы делаем, чтобы наши продукты (расширения) не ломались после обновлений 1С

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

Мы сделали более 500 разработок для 1С:ФРЕШ (это к частому вопросу о том, что облако нельзя дорабатывать), а для локальных версий — ещё больше. Иногда одна и та же доработка бывает полезна для многих пользователей. В таких случаях мы стараемся превратить её в продукт.

Продукт — это доработка, за которую мы несём ответственность. Она должна:

• решать задачу пользователя
• быть удобной и понятной
• работать у многих пользователей
• быть правильно и аккуратно написана программистами
• работать после обновлений
• иметь понятные инструкции

А мы должны поддерживать пользователей доработок — бесплатно или платно в зависимости от вопроса.

Стоимость подобной готовой разработки обычно кратно ниже стоимости индивидуальной. Пользователи приобретают у нас расширение за фиксированную понятную цену, а потом по фиксированной цене приобретают поддержку: адаптацию к новым версиям 1С, развитие функционала. Такой подход выгоден и нам (разработчикам), и покупателям (пользователям).

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

Мы для себя приняли несколько решений:

• мы должны правильно организовать учёт версий разработки: в какой версии какие изменения были сделаны, какой минимальный релиз конфигурации поддерживается
• мы должны тестировать наши разработки (проверять программную совместимость и функционал разработки)
• тесты должны выполняться автоматически, без участия тестировщика, чтобы мы могли быть уверены, что всегда проверяем то, что нужно проверить
• мы должны адаптировать и исправлять разработки до того, как выйдет обновление 1С (на предварительных релизах 1С)
• мы должны вовремя публиковать новые версии, чтобы пользователи могли их вовремя получить

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

Процесс адаптации расширений к новому релизу

Мы расскажем об этом процессе на примере разработки для 1С:ФРЕШ, в котором есть магазин готовых расширений.

Этап подготовки

Для каждой разработки нужно настроить специальный конвейер, который будет работать каждый день и будет проверять, всё ли хорошо. Для этого нам нужно подготовить:

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

Этап 1. Обновление тестовой базы

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

Этап 2. Установка последней версии расширения в тестовую базу

Перед тем как запустить автоматический тест, мы должны быть уверены, что проверяем самую последнюю (актуальную) версию нашей разработки. Поэтому мы автоматически устанавливаем её из каталога и проверяем, не было ли ошибок на этом этапе.

Часто на этом этапе возникает ошибка, конвейер прерывает свою работу и сигнализирует ответственному о проблеме. Обычно ошибка связана с тем, что для нового релиза нужна адаптация разработки (некоторая работа программиста). После адаптации разработки конвейер продолжает свою работу.

Этап 3. Запуск автоматического тестирования

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

На этом этапе также часто возникают ошибки. Об этом мы получаем автоматический сигнал. Ошибки могут возникать по двум причинам:

• разработчики доработали какую-то функциональность, и нам надо в этом разобраться и поправить программный код, чтобы всё работало как ожидалось
• мог сломаться автотест — тот сценарий, с помощью которого мы проверяем конкретные действия нашего расширения. То есть могла сломаться не сама разработка, а тест, который её проверяет. В этом случае мы адаптируем тест.

После всех исправлений мы прогоняем конвейер ещё раз, чтобы убедиться, что ошибок нет.

Успешный конвейер выглядит так:

А вот так выглядит успешно пройденный автотест. Согласитесь, красиво!

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

Этап 4. Публикация обновления расширения

После того как мы всё поправили для новой версии 1С, мы должны правильно опубликовать обновление:

• подготовить описание изменений, поправить его на нашем сайте
• отправить разработку на аудит во Фреш (обычно это занимает 2–3 дня).

Мы устанавливаем новую версию так, чтобы она работала только в тех базах, в которых обновится типовой релиз. Ведь, если просто выложить новую версию, она обновится и в необновлённых базах пользователей. Это может привести к ошибкам.

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

Ещё не пробовали наши продукты? Посмотрите наш каталог — в нём много интересного.

Если вы столкнулись с тем, что в вашей программе постоянно ломаются доработки, это стопорит рабочий процесс и вы теряете деньги, обращайтесь к нам. Мы обсудим, как можно внедрить подобный процесс для вашей 1С, чтобы вы были уверены в том, что 1С работает, а доработки не ломаются.