Наш путь в Git – история одного внедрения CI/CD

02.10.23

Разработка - DevOps и автоматизация разработки

Чтобы перейти от разработки в хранилище до полноценного релизного цикла CI/CD, с автотестированием кода, сборкой конфигураций из исходников и ветками разработки для каждой задачи, нужно пройти большой путь. Расскажем о том, как организовать полностью автоматическую доставку проверенного и рабочего кода в 2000 конфигураций.

Меня зовут Алексей Жучков. Я – один из самураев 1С команды банка Тинькофф. Хочу рассказать о том, какой путь мы прошли вместе с командой – с чего начинали и к чему пришли.

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

 

В начале того пути, о котором идет речь, у нас было:

  • 2000 отдельных баз 1С на «Бухгалтерии предприятия».

  • Код, который был доработан, находился сразу в основной конфигурации. Кто-нибудь из вас обновлял 2000 баз «Бухгалтерии предприятия»? Можете себе представить, каково это.

  • Мы использовали хранилище, и я не просто так назвал это попоболью. С хранилищем, как вы знаете, много проблем, поскольку оно подразумевает одну ветку разработки и необходимость захвата объектов.

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

 

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

Я сейчас не буду проводить детальное сравнение между EDT и конфигуратором, могу лишь сказать, что мы остановили свой выбор на конфигураторе.

Не только из-за его привычной теплой ламповости, но и из-за наличия большого количества прекрасных расширений. Например, Снегопат. Или Турбоконф.

 

Первый бой

 

Мы жили с одним хранилищем. Но так дальше жить было нельзя.

  • Мы взяли Jenkins, прикрутили к нему задание, и gitsync-ом начали выгружать весь исходный код из хранилища в Git. В результате мы получили Git, который выгружается из хранилища. И сделали там три ветки: ветку master, которая смотрит на прод; ветку test, ориентированную на тестовый контур; и ветку develop разработчиков, куда изначально выливается все из хранилища. Git-сервер у нас тогда был на Atlassian. И мы настроили себе триггер, чтобы после merge-request’ов из одной ветки на другую автоматически запускались задания, накатывающие конфигурацию ветки на необходимый контур. Это позволило нам разделить разработку на три части.

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

  • Но этого было недостаточно. 2000 баз – это серьезный вызов. Здесь тоже нужно было что-то сделать. Нам повезло, ведь мы не первые столкнулись с такой проблемой – в самой фирме «1С» давным-давно успешно победили ее при помощи разделителей. Мы включили разделение данных для своих баз и смогли из 2000 баз сделать 14. Нам понравилось такое количество, оно было удобно в использовании – использование 14 баз значительно снизило и нагрузку на дисковую подсистему, и нагрузку на сервер 1С.

  • Мы решили дальше развивать наш начинающийся успех на пути к Git, который был нашей целью.

 

После первой итерации мы столкнулись с тем, что у нас возникли вопросы. Как быть? Что делать? Куда идти дальше? Что смотреть?

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

 

Второй бой

 

Ко второму сражению мы подошли уже более вооруженными и защищенными.

  • Один из основных принципов, которого мы придерживались при разработке – это Feature Driven Development. Нам важно и нужно было, чтобы каждая конкретная фича могла быть доставлена на контур в любой момент времени вне зависимости от того, находится она ниже по ветке, выше, сбоку, рядом. Git все это позволял сделать, но у нас его пока еще не было в полном виде.

  • Мы познакомились с большим количеством прекрасных модулей OneScript. Мы разные модули, все это вложили в голову нашего прекрасного Никиты Иванченко и собрали комплект скриптов на OneScript. С их помощью мы могли выгружать конфигурацию в текстовые файлы и помещать ее в Git. Также мы научили наши скрипты обратному процессу – выгружать конкретную ветку из Git и заливать ее в конфигурацию, конфигуратор.

  • Чтобы унифицировать и формализовать процесс, мы познакомились с технологией SubModules Git. Прекрасная технология, которая позволяет подключать репозитории со всеми нашими скриптами непосредственно как подмодуль текущего репозитория Git.

  • И о хуках, конечно. Многим из вас знакомы хуки Git. Некоторые используют precommit1c или precommit4onec. Мы смогли пойти немного дальше – мы узнали о том, что, кроме pre-commit хука, есть еще хук post-checkout.

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

Сейчас с каждой новой фичей разработчики работают в своих отдельных ветках. Чтобы забрать необходимую ветку из Git в базу, разработчику достаточно в любом комфортном ему Git-клиенте или командной строке просто выполнить команду checkout. При этом post-checkout запускает ряд скриптов, которые завершают сеансы, собирают конфигурацию и заливают ее в нужную целевую базу. В результате разработчик получает у себя в базе разработки конфигурацию из Git.

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

Мы связали весь процесс и подключили в него Jira, Sonar и систему тестирования.

 

Один против 1С не воин

 

 

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

  • Иванченко Никита – наш ведущий разработчик, он готов сейчас вместе со мной ответить на ваши вопросы.

  • Кириллова Анастасия отвечает за наше тестирование.

  • Фатыхов Рашид – прекрасный профессиональный разработчик и тестировщик.

  • И Котов Андрей – наш самый юный разработчик.

  • Я добавил сюда и Олега, потому что в процессе развития этой истории я действительно прошел большой путь. От человека, который был готов разрезать свою карту Tinkoff и выкинуть ее, до человека, гордого тем, что он работает именно в Tinkoff.

 

Мы не остановимся на этом пути и будем идти дальше. У нас есть очень много интересных вызовов.

  • Мы любим ClickHouse – нам нравится загружать в него данные и работать с ними быстро и качественно. Мы хотим научиться прозрачно переносить данные из 1С в ClickHouse и обращаться к ним из 1С таким образом, чтобы они хранились только в ClickHouse.

  • Также у нас есть планы по автоматизированному тестированию. Мы уже придумали, как сделать так, чтобы написание тестовых сценариев не требовало привлечения разработчика – чтобы их делали сами пользователи.

  • Ну, и про чудеса пространств 1С – это история про то, как мы уже сейчас научились выгружать отдельные справочники из 1С в Git и вести их там.

 

Вопросы

 

Вы рассказали, что, когда делаете checkout в Git-клиенте, исходный код скриптами загружается в конфигуратор. А что происходит при коммите?

Сейчас, когда нам нужно сделать для себя ветку под разработку конкретной фичи, мы делаем checkout. И скрипт post-checkout загружает текстовые файлы конфигурации в информационную базу разработчика – сведения о настройках этой базы хранятся в отдельном файле, который находится в .gitignore.

Причем скрипт post-checkout’а заканчивается тем, что в репозиторий вносится небольшое изменение – мы специально кладем в него временный файлик, чтобы Git видел, что там есть какие-то изменения.

И когда разработчик готов сделать коммит, он делает его средствами Git на этих изменениях – pre-commit-скрипт удаляет этот временный файлик, выгружает конфигурацию из базы 1С в текстовые файлы, и делает из нее коммит.

Когда это происходит? В конце? Например, разработчик много раз обновлялся, протестировал это у себя и решает сделать коммит. Когда он переходит в Git-клиент, у него уже будет все готово?

Если у него в 1С есть сохраненная конфигурация, которую он хочет выгрузить в Git, то у него все готово. Он просто делает коммит, конфигурация выгружается в текстовые файлы и отправляется в Git.

Когда ребята помещают коммиты, у вас бывают конфликты при мержах? Как вы потом сливаете ветки и эти конфликты разруливаете?

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

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

У нас получился очень негативный опыт работы с подмодулями. Причем нас предупреждали, мы не послушались и потом получили серьезные проблемы. У вас нет проблем с подмодулями?

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

А как вы распространяете хуки, чтобы их положить в репозиторий?

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

Пока хуки прописываем руками – там два файлика скопировать.

Вы говорите, что загружаете изменения в конфигурацию при post-checkout. А в pre-commit вы выгружаете изменения обратно. Вы выгружаете всю конфигурацию?

Да, мы работаем в расширениях, они не такие большие.

А как вы боретесь с мусорными файлами? Или разработчик должен вручную проверить каждый файл на соответствие изменениям?

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

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

У нас были идеи, как реализовать загрузку большой конфигурации побыстрее. Когда у тебя в Git лежит большая конфигурация, можно посчитать diff между коммитами – какие файлы нужно загрузить. Мы пытались это дело автоматизировать – генерили небольшой текстовый файл, который содержит в себе список того, что было изменено от коммита A до коммита B. И пытались подсовывать этот файл как дополнительный параметр.

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

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

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

Вы сказали, что выгружаете в Git справочники – это некий аналог MDM или для чего это делается?

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

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

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

Я так понимаю, у вас достаточно серьезные требования к людям, которые работают. Вы сразу нанимаете со знанием Git? Или у вас какое-то обучение есть? И как у вас люди вообще соглашаются изучать Git?

Изначально вся эта каша была заварена, в том числе, для того, чтобы облегчить вход в Git для тех, кто с ним никогда не работал.

Мы изо всех сил старались максимально убрать необходимость знания Git, понимания команд, принципов его структуры, чтобы максимально автоматизировать процесс.

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

Это принудительное обучение? Он без этого не сможет работать?

Большинство основных вещей, которые нужны будут для текучки, можно освоить по роликам на YouTube за полтора-два часа. А потом ты возьмешь Git Pro и будешь ее два года читать, а через два года все равно не будешь всего знать.

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

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

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

Раньше мы были на Jenkins с выгрузкой в Bitbucket. Потом перешли на GitLab, но остались на раннерах Jenkins. Сейчас у нас GitLab стреляет на Jenkins через curl с определенными параметрами на каждом репозитории, и запускает с ними джобы в Jenkins – там есть специальные JSON-файлы, которые знают, что, куда и в какой последовательности загружать.

Как готовятся тестовые данные? Вы берете базу с продуктива или какую-то изначально подготовленную? Как и кем тестируются эти данные? Вы разработали расширение, выгрузили его в XML, и кто потом тестирует все эти изменения? И какую систему учета задач вы используете?

Мы используем Jira.

Тестовые данные частично продовые, частично сгенерированные.

Продовые данные – это, скорее, какие-то частные случаи, которые вдруг случились на проде и что-то сломали. И мы их себе как эталон перенесли, чтобы это учитывать и 1С нам каким-нибудь обновлением это не сломало.

Плюс мы сейчас разрабатываем отдельный фреймворк на Python, который позволяет тестовые данные генерить автоматически. Он, во-первых, генерирует данные для тестирования в 1С, в потом запускает 1С и дергает ее там за определенные рычаги, используя Vanessa, и все тестирует. И прям в онлайн режиме, пока это тестируется, результаты уже падают в Allure.

Что входит в вашу инфраструктуру? И как вы накатываете обновления? Файлом поставки?

У нас типовые конфигурации «Бухгалтерия предприятия» и «Зарплата и управление персоналом». Есть одна самописная нетленка, которая помогает всем этим рулить, и свой менеджер 1cfresh.

Мы не делаем поставку – сразу из файлов собираем конфигурацию и накатываем в базу. Конфигурации поставщика мы обновляем cf-никами, а наши изменения в расширениях собираем из исходников.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.

 

Приглашаем на конференции Инфостарта 2025 года

INFOSTART TEAMLEAD EVENT

Не только для разработчиков, но и для руководителей отделов разработки, тимлидов и ИТ-директоров.
Место: Москва
Даты: 24-25 февраля 2025 г.

Подробнее

INFOSTART A&PM EVENT (Анализ & Управление проектами)

Практическая конференция для аналитиков и руководителей проектов 1С.
Место: Санкт-Петербург
Даты: 29-31 мая 2025 г.

Подробнее


См. также

DevOps для 1С DevOps и автоматизация разработки Программист Стажер Платные (руб)

Данный онлайн-курс (интенсив) предусматривает изучение процессов, инструментов и методик DevOps, их применение при разработке на платформе 1С. 

48000 руб.

20.06.2023    20962    20    4    

305

1С-программирование DevOps и автоматизация разработки Групповая разработка (Git, хранилище) DevOps для 1С Программист Стажер Платформа 1С v8.3 Платные (руб)

Использования систем контроля версий — стандарт современной разработки. На курсе научимся использованию Хранилища 1С и GIT при разработке на 1С:Предприятие 8. Разберем подходы и приемы коллективной разработки, научимся самостоятельно настраивать системы и ориентироваться в них.

4900 руб.

29.06.2022    11448    94    4    

125

Тестирование QA DevOps и автоматизация разработки Программист Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х Россия Бухгалтерский учет Налоговый учет Платные (руб)

Готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарии возможно использовать как для vanessa-automation, так и для СППР. Поддерживаемые версии конфигураций ERP2 и КА2: 2.5.17.113.

2400 руб.

04.07.2022    8178    38    1    

28

DevOps и автоматизация разработки Тестирование QA Программист Пользователь Платформа 1С v8.3 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет Платные (руб)

Автотесты 1С - готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Зарплата и Управление Персоналом 3 и версии КОРП: 3.1.27.271.

2160 руб.

05.08.2024    902    9    1    

6

DevOps и автоматизация разработки Системный администратор Программист Руководитель проекта Платформа 1С v8.3 Конфигурации 1cv8 1С:Франчайзи, автоматизация бизнеса Платные (руб)

Подсистема «Управление сборкой GLI» предназначена для динамического формирования сборочных линий Gitlab и отслеживания процесса доработок систем на базе1С:Предприятия Позволяет упростить выпуск новых релизов системы, подготовить описание доработок системы. Интегрируется с GitLab API по событиям Push, Merge-request, Pipeline. Уведомляет пользователей о результатах сборки/тестирования сборочных конвейеров через СВ, либо при её недоступности или отсутствию по E-Mail. Поможет при отправке исправлений ошибок в общую базу тестирования, сформирует запросы на слияние в ветку версии только по протестированному и подтверждённому функционалу. Подсистема рассчитана исключительно на клиент - серверную архитектуру тестовых ИБ. Поддерживаемая версии СППР 2.0.4.15, платформа не ниже 8.3.17.1549, 2.0.7.3 / не ниже 8.3.21.1664, начиная с релиза 1.0.4.30 требуется платформа не ниже 8.3.23 рекомендуемый релиз 8.3.23.1997

7000 руб.

26.08.2022    12145    10    5    

34

Тестирование QA DevOps и автоматизация разработки Программист Пользователь Платформа 1С v8.3 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Налоговый учет Платные (руб)

Автотесты 1С - готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Бухгалтерия предприятие 3.0 и версии КОРП: 3.0.156.30.

1800 руб.

20.01.2022    7561    18    0    

12

Групповая разработка (Git, хранилище) Программист Руководитель проекта Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Когда в хранилище одновременно разрабатывают несколько команд, сортировка сделанного и несделанного при формировании релиза и проведение code review по задачам превращаются в непроходимый квест. В таких случаях нужен бранчинг. Расскажем об опыте перехода на новую схему хранения кода для ИТ-департамента.

23.09.2024    2016    kraynev-navi    2    

23

DevOps и автоматизация разработки Программист Платформа 1С v8.3 Бесплатно (free)

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

18.09.2024    1199    antonov_av    6    

14
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Torin 816 02.10.23 13:10 Сейчас в теме
(0)
У нас типовые конфигурации «Бухгалтерия предприятия» и «Зарплата и управление персоналом».
и в тоже время
Код, который был доработан, находился сразу в основной конфигурации.
- не совсем понятно, если типовые, то откуда доработанный код? А если не типовые , то почему не применить технологию расширений , тем более 2000 баз?
2. BomjBandit 6 03.10.23 19:48 Сейчас в теме
3. anosin 29 03.10.23 22:08 Сейчас в теме
Не развернуто, чем принципиально эти 2000 конфигураций друг от друга отличаются если все на 99% типовое.
4. TerveRus 16.10.23 16:07 Сейчас в теме
Откуда 2000 баз БП, у вас же офисов нет?)

Научились, молодцы, конечно, рады за вас.

Думаете кто-то сможет пройти весь этот пусть с нуля и написать те же скрипты?
Без подробностей и примеров скриптов все это воспринимается как хвастовство)

Ну, хорошо, узнали что и так бывает)
А какие-то единицы вдруг попадут к вам на работу и увидят все своими глазами, и за них мы тоже рады)
Оставьте свое сообщение