Біля стійки

Костин контакт мені дала Наталя — наступного понеділка, коротко: «Якщо хочеш про git і CI у 1С — це він. Костя, наш DevOps. Передзвоню йому, скажу, що ти прийдеш».

Костя написав мені сам через годину: «Вівторок, девʼятнадцята, паб „Хата на тата" на Спаській. Я там зустрічаюся з друзями о двадцять першій, але до того часу можемо поговорити».

У вівторок о сьомій я зайшов у «Хату на тата». Це невеликий крафтовий паб на Подолі, з цегляними стінами, чорними металевими світильниками, телевізором без звуку, на якому показували архівний матч ЛЧ. Кілька столиків, шість стільців біля довгої барної стійки, бармен з рудою бородою у фартуху. На стенді — двадцять кранів з пивом, поряд табличка з днем тижня і назвами.

Костя сидів на третьому стільці від кінця стійки. Я впізнав його за описом Наталі — худорлявий, у чорній футболці з логотипом якоїсь конференції про Kubernetes, окуляри з тонкою металевою оправою, на руці — простий шкіряний браслет. Перед ним — третина склянки темного пива і відкритий ноутбук.

— Костя?
— Денис? Сідай, я тобі замовлю. Що питимеш?

— Чай.
— Чай у пабі — це смішно. Але тут у них непогана ромашка з лимоном. Беремо.

Він покликав бармена, замовив, повернувся до мене.

— Так, що тобі треба з мого монологу?

— Розкажи, як ти прийшов у 1С-світ. Бо ти не виглядаєш як 1С-розробник.
— Я і не 1С-розробник. Я DevOps, який обслуговує 1С-команду. Це інша професія, в одному будинку з ними.

Він зробив ковток.

— До цього три роки був DevOps у Java-проекті, в одному відомому інтернет-магазині. У нас були Jenkins, Kubernetes, Terraform, GitLab CI, Helm. Усе за канонами. Потім фірма закрилася — я знайшов це місце. Прийшов сюди, у понеділок зайшов до 1С-команди — і впав у дев'яності. Жодного git. Жодного CI. Жодного автотесту. Жодного код-ревʼю. Усе у форматі «один прийшов, інший пішов, файл у мене на десктопі, я тобі зараз кину».

— У сімнадцятому?
— Так. До приходу Наталі — місяців за вісім. Вона прийшла, побачила той самий хаос — і ми вдвох сіли його розбирати. Я займався інфраструктурою, вона — кодом. У нас вийшло.

— Як виглядав той хаос?
— Я тобі змалюю. Шість 1С-розробників. Один центральний сервер з конфігурацією. Класичне сховище 1С — це їхній git, тільки на двадцять років слабший за справжній. Зміни робилися так: розробник захоплював об'єкт, працював над ним, повертав. У цей час інші не могли торкатися цього об'єкта. Якщо хтось забув повернути об'єкт — у понеділок зранку це блокувало половину команди.

— Це і є сховище?
— Це сховище. Вбудований у платформу механізм командної роботи з версії 8.0. Pessimistic locking — захопив, відпустив. На той час, у двадцятому році, у Java-світі це вже виглядало як кам'яний вік.

— Чому платформа так зробила?
— Бо платформа — з епохи, коли git не існувало. Сховище 1С — це CVS, перенесений у нульові. У двотисячному це було нормально. У двадцятому — це болить. Але платформа не вміє інакше з коробки.

Костя відкрив ноутбук, повернув до мене. На екрані була схема архітектури їхнього CI/CD.

— Ось як виглядає у нас зараз. Уся розробка йде через EDT — це окрема IDE на базі Eclipse, яку 1С випустила приблизно у шістнадцятому. EDT принципово відрізняється від класичного Конфігуратора однією деталлю: вона зберігає конфігурацію не у бінарному .cf-файлі, а у наборі текстових XML-файлів. Дерево директорій, кожен об'єкт — окрема директорія з купою XML.

— І це можна у git?
— Це можна у git. Це — головне відкриття десятих років для 1С-світу. До EDT git не мав сенсу — бінарний .cf не диффувся. З EDT — нарешті можна побачити, що саме змінив колега у твоєму об'єкті, без злиття конфігурацій кліком «прийняти з нової / з поточної».

— А типова?
— Типова постачається у бінарному .cf. Перший крок — конвертувати її в EDT-формат. У нас це робиться один раз, на старті проекту, через утиліту в EDT. Далі — все живе у git. Кожне оновлення типової — теж конвертуємо у EDT, заливаємо у feature branch, мерджимо. Працює.

— Це у вас зараз так. А починалося як?

Костя поморщився.

— Перші два роки EDT була сирою. Файли губилися при конвертації, проект відкривався по двадцять хвилин, на ERP вона взагалі не тягла. У вісімнадцятому я був готовий усе кинути і повернутися до Конфігуратора. Витримав. У дев'ятнадцятому вона почала стабілізуватися. У двадцятому стало можливо жити.

— І ви через все це пройшли?

— Пройшли. Більшість команд тоді EDT відкладали — чекали, поки 1С її допише. Ми вирішили йти раніше. Три роки муки. Але вже до пандемії мали повноцінний git, а більшість 1С-світу — досі сидить у Конфігураторі.

— Тобто у вас зараз git як у нормальних людях?

Костя усміхнувся.

— Десь так. У нас GitLab self-hosted, репозиторій з конфігурацією і кількома розширеннями. Розробники працюють у feature branches. Pull request — обов'язковий, з двома апрувами. CI пайплайн — на GitLab Runner.

— Що робить пайплайн?
— Чотири стадії. Перша — лінт. У нас свій набір правил у EDT — він робить статичний аналіз: знаходить запити у циклі, точкову навігацію у звітах, незакриті транзакції, недокументовані експортні методи. Це покриває десь сімдесят відсотків Юриних антипатернів.

— Друга — збірка. Конфігурація з XML конвертується у .cf файл, перевіряється платформою на синтаксис. Якщо .cf не збирається — пайплайн падає, MR не злити.

— Третя — автотести. Це окрема історія, я тобі про неї ще розкажу. У нас Vanessa Automation, BDD-сценарії на Gherkin, виконуються у спеціальній тестовій базі. Перевіряють критичні бізнес-процеси: проводимо документ — рухи створились правильно. Розпроводимо документ — рухи зникли. Тощо.

— Четверта — деплой на стейджинг. Якщо все попереднє зелене — .cf автоматично завантажується у тестову базу. Тестувальники бачать зміни через п'ять хвилин після мерджу.

Я записав це у блокнот.

— Скільки часу зайняло побудувати цей пайплайн?
— Шість місяців основної роботи, потім ще рік доопрацювання деталей. Я починав у дев'ятнадцятому, до двадцятого ми ввели три стадії — лінт, збірку, деплой. Четверта, автотести, — це вже з Юлією у двадцять другому. Тепер усе разом — два роки стабільної роботи.

— А проблеми?

Костя ковтнув пива.

— О, проблем багато. Я тобі по списку.

Перша — розмір репозиторію. Типова BAS КУП у EDT-форматі — близько сорока тисяч файлів. Git працює, але клон з нуля — десять хвилин. git status на повному репо — кілька секунд. Це не SAP, але це і не нормальний веб-репо.

Друга — гранулярність комітів. Розробник додає реквізит у документ — а у git це коміт, який змінює п'ять XML-файлів: метадані документа, дві форми, модуль об'єкта, модуль форми. Концептуально — одна зміна. Технічно — пʼять. Розробники часом плутаються, що з цього коміт, а що — ні.

Третя — конфлікти у XML. Коли два розробники змінюють одну форму одночасно — git показує конфлікт у XML. Розв'язати вручну — пекло. XML 1С — не призначений для людського читання. Ми використовуємо EDT merge tool, який знає структуру цих XML і робить злиття семантично. Працює у вісімдесяти відсотках випадків. Двадцять — все одно вручну.

Четверта — типова конфігурація як зовнішня залежність. Постачальник оновлює BAS Бухгалтерію — нам треба прийняти його зміни. Ми робимо це через окрему гілку vendor-update. Конвертуємо новий .cf у EDT, мерджимо у нашу основну гілку. Конфлікти — згадай порівняння-обʼєднання, про яке тобі казав Артем. Тільки у git вигляді. Дещо краще, дещо гірше.

П'ята — версії платформи. EDT прив'язана до конкретної версії платформи. Якщо платформа оновилася — треба оновити EDT. Інколи це ламає сумісність зі старими розширеннями. У нас на CI стоїть матриця: збираємо одну й ту саму конфігурацію для двох версій платформи (стара і нова), щоб не зламати продакшен.

— А тести? Це найбільш цікаво для мене.

Костя повернувся.

— Тести у 1С — окрема індустрія. Розповідь коротка. До двадцятого року тестів майже ніхто не писав. Ні в Україні, ні у Росії. Культура була: «у нас бухгалтер у понеділок усе перевірить». Це не жарт, це норма. Підприємство як полігон для тестування продакшен-коду.

— Хто це зламав?
— Декілька open-source проектів. Головний — Vanessa Automation. Це BDD-фреймворк для 1С, написаний українцем і кількома російськими розробниками у нульових-десятих роках. Він дозволяє писати тести на Gherkin: Given - When - Then. Тести виконуються у спеціальній тестовій базі, через спеціальний клієнт-робот, який клацає по формах і перевіряє результат.

— Це повільно?
— Дуже. Один сценарій — від десяти секунд до хвилини. Повний прогон у нас — півтори години. Тому у пайплайні запускаємо тільки smoke — критичні сценарії, які мають бути зелені завжди. Повний регрес — раз на ніч, через cron.

— Яке покриття?
— Не відсоткове, я не міряв. Концептуальне. У нас покриті головні бізнес-процеси: проведення основних типів документів, формування основних звітів, інтеграція з банком, ПДВ-логіка. Це, можливо, двадцять відсотків коду — але дев'яносто відсотків ризику. Якщо ці тести зелені — продакшен встоїть.

— А unit-тести?
— Окрема історія. Платформа 1С довго не давала способу запустити окрему процедуру з модуля. Зараз з'явилися інструменти — xUnitFor1C, ще кілька. Але це не основна культура у нашому світі. Ми пишемо переважно інтеграційні тести.

— Інструменти. Окрім Vanessa і EDT — що ще?

Костя завагався, наче згадуючи.

— OneScript — це інтерпретатор мови 1С поза платформою. Тобто ти можеш писати скрипти на 1С-діалекті без самої 1С. Корисно для DevOps — пишеш утиліту, яка читає XML конфігурації, перевіряє щось, повертає звіт. Open source.

— Precommit-хуки — у нас є набір невеликих скриптів на OneScript, які працюють при коміті. Перевіряють базові правила: чи не залишилось Сообщить("debug") у коді, чи всі експортні процедури мають коментарі, чи немає TODO без номера задачі.

— GitConverter — окрема утиліта для конвертації між .cf і git-friendly форматом. У нас вона запущена як cron, тримає у репозиторії копію типової у читабельному форматі для тих розробників, які ще не на EDT.

— Як ти всі ці інструменти знайшов?
— Telegram. У нас є невеликий, але живий канал «1С DevOps України» — десь триста підписників, переважно люди з in-house компаній і кілька великих франчайзі. Усі тамтешні знають усіх. Якщо у когось проблема — кидаєш у канал — за пів години відповідь.

— Це community.
— Це маленьке community. У 1С-світі community у звичному сенсі немає — нема Stack Overflow, нема GitHub-екосистеми у тих масштабах, як у JavaScript. Але у вузьких нішах — як DevOps — є мікроспільноти, які тримають індустрію. Нас триста чоловік. Ми знаємо одне одного за ніками.

— А культурні бар'єри?

Костя зробив паузу.

— Це головна проблема. Технологічно git у 1С — це розв'язана задача. EDT існує, інструменти є, пайплайни побудовані. Що залишається — це переконати команду перейти.

— Як це у вас було?
— Нелегко. У нас було двоє старших розробників — обидва з вісімнадцятирічним стажем у 1С. Для них сховище — це і є git. Вони не розуміли, навіщо щось міняти. «У нас же все працює». Я їм демонстрував переваги півроку. Показував diff. Показував blame. Показував повернення до старої версії. Один погодився — за два роки став ентузіастом, зараз вчить молодших. Другий — пішов. Сказав: «Я цьому не вчитимуся за п'ять років до пенсії».

— Це нормально?
— Це нормально. Я не вимагаю від людини, у якої двадцять років інструмент був git-аналогом, переучуватися на справжній git. Я зробив поступово, з паралельною роботою в обох системах. Десь з 2020-го всі нові проекти — тільки git. Старі сховища — паралельно для тих, хто на них застряг. Це називається «strangler fig pattern». Заміна по дереву, не одним днем.

— А у франчайзі?
— У франчайзі — переважно нема git. Звичайне сховище 1С. Це структурна проблема, як казала Наталя. Франчайзі не платять за DevOps. Клієнт не платить за DevOps. У франчайзі немає такого бюджету, як у in-house компанії з ритейлом. Тому це залишається лакшері — для тих, хто може собі дозволити шість місяців інвестицій у процеси.

— Що ти би сказав молодому 1С-розробнику, який хоче розвиватися?

Костя зробив ковток, замислився.

— Сказав би: навчись git першим. Не як вибір, а як фундамент. Без git у 1С-світі ти залишишся у тих вісімдесяти відсотках ринку, де немає шансу зрости. В ін-хаусі — git. У великих франчайзі — git. У дрібних — нема, але такі франчайзі не дадуть кар'єру. Git — це маркер дорослого 1С-розробника.

— А EDT?
— EDT — другий крок. Перший — git. Другий — EDT. Третій — як мінімум базове знайомство з CI/CD. Це профіль зрілого 1С-розробника на 2026 рік. Без цього — ти Юрі-кандидат. З цим — Наталя-кандидат.

Він допив пиво, подивився на годинник. За чверть девʼята.

— Слухай, мої друзі скоро прийдуть. Ти що з цим робитимеш?
— Запишу. Опублікую десь через пів року.
— Ну добре. Якщо потрібна сторінка з нашим пайплайном — у нас є внутрішня документація, я тобі скину анонімізовану версію.

— Дякую.

Він закрив ноутбук. Я підвівся, пожав йому руку.

Я вийшов з пабу на Спаську. Темно, прохолодно, біля Контрактової площі грала вулична музика — троє студентів з консерваторії, фортепіано-цифрове на колесах і скрипка.

Я думав про одну річ.

Костя — антипод старого 1С-розробника. Він прийшов з Java-світу, він не любить 1С як таку, він ставиться до неї як до клієнта. Інфраструктура, яку він побудував — git, EDT, CI/CD, Vanessa, OneScript, precommit-хуки — це не пристрасть до платформи. Це дисципліна професіонала, який знає, як має виглядати дозрілий девелопмент. Він приніс цю дисципліну з іншого світу і застосував.

Можливо, це і є шлях, яким 1С-екосистема повільно дозріває. Не зсередини — бо зсередини культура двадцяти років не змінюється. Ззовні — через DevOps, які приходять із сусідніх стеків, бачать, чого тут немає, і будують це. Наталя — приклад зсередини. Костя — приклад ззовні. Разом вони змінюють компанію.

Але це знов у великих in-house. У середньому 1С-світі — у франчайзі, у малих компаніях — нічого з цього не існує. Там, як казав Костя, «сховище — це git». І так буде ще довго, бо економіка не дозволить інакше.

У наступному розділі — про останній з культурних розривів Частини III. Про тести. Точніше, про їхню майже повну відсутність як галузевої норми. Чому 1С-індустрія двадцять років жила без автотестів. Чому Vanessa Automation і xUnitFor1C — це маленькі острівці, які майже ніхто не використовує. І що з цим робити.

Розділ чотирнадцятий, останній у Частині III. Про тестування у світі, у якому ніхто не тестує.