Расскажу немного о нашей компании. Мы являемся бизнес-интегратором, уже более 10 лет занимаемся разработкой различных программных продуктов для крупного бизнеса. У нас большое количество крутых специалистов в разных областях, с некоторыми из которых вы знакомы по секции Highload.
Я собираюсь рассказать про процесс перехода наших команд с использования хранилищ 1С на системы контроля версий Git:
- что было у нас до того, как мы решили поменяться, почему мы решили это сделать;
- как шел этот процесс – основные вехи;
- что у нас получилось;
- и потом будет небольшой анонс – я хочу похвастаться, что мы планируем делать дальше.
Что было в 1С разработке, почему мы решили меняться?
Итак, что у нас было в самом начале.
Как и у всех организаций, разрабатывающих решения на платформе 1С, их было некоторое количество. Числа я привел здесь для сравнения, чтобы потом просто было видно, как они меняются. Будем считать, что на старте было более 20 разнородных решений. Это были не информационные системы, а именно конфигурации.
Было большое количество разработчиков. Как опытных, так и стажеров, молодых специалистов. Почему я их здесь выделил? Потому что они, как ни странно, были одним из двигателей прогресса. С более опытными было гораздо сложнее работать, сложнее поменять мировоззрение с классического подхода на новый.
Что было еще? У нас при активной разработке начались постоянные проблемы с хранилищем, такие как:
- Постоянная обрезка больших репозиториев – у нас за полгода одно хранилище разрасталось до 10 тысяч коммитов.
- Медленная история. Все прекрасно знают, что сравнить две версии в хранилище – нелегкая задача.
- Фиксация изменений зачастую занимала продолжительное время.
- Плюс иногда возникали ситуации разрушения хранилища, когда из-за превышения его размера после очередного коммита выдавалась ошибка: «Неверный формат хранилища данных», которая означала, что хранилище больше не является базой данных.
Далее, проблемы при самой разработке, также всем прекрасно известные:
- Популярные объекты были постоянно заблокированы.
- Культуры комментирования не было. Кто-то писал комментарии к изменениям в коде, кто-то не писал. Многие использовали методику комментирования кода, указывая фамилию и номер задачи – но поскольку код ни с чем не соединялся, нельзя было понять, что это за изменения.
Код-ревью не проводился. Понять, кто и зачем это сделал, было невозможно.
Из-за того, что объекты постоянно были заблокированы, качество решений начало активно страдать. Нередко возникали просьбы: «Дай, пожалуйста, мне объект на 15 минут, я сейчас прогружу, оно точно ни на что не повлияет, обещаю». А потом это приводило к различным проблемам и разборкам, кто виноват и почему.
Но кроме 1С в нашей компании был еще и соседний параллельный мир – большое количество разработчиков, использующих прикладные веб-технологии и прочие вещи. У них было счастье – CI/CD, Git, интеграция с различными системами «из коробки». Про виртуализацию и контейнеризацию я вообще молчу. Это просто какие-то чудеса.
А мы жили в каменном веке – грустно, печально. И мы решили что-то поменять.
Основные этапы перехода.
Просто так дернуть рубильник, и перейти на Git или на Mercurial, который тоже рассматривался, мы не решились. Нужно было сначала немного подготовиться.
Мы решили, что всех сразу переводить не будем – сначала возьмем пилотную команду, пилотный проект и попробуем поэкспериментировать, посмотреть, что произойдет.
Выбрали варианты, которые будем рассматривать. Были варианты с пачкой хранилищ и переносами между ними – релизными и нерелизными. Хранилище с GIT, с Mercurial, и просто Git.
И начали пробовать эти варианты – осторожно, с болью.
Часть вариантов отметалась достаточно быстро. В частности, вариант с массой хранилищ и связка хранилища с Git, так как эти решения приводили к еще большему количеству проблем.
В итоге, после перебора всех вариантов, остановились на использовании только репозиториев Git и… никаких хранилищ. Этот вариант был последним, и по результатам работы команды некоторое время по этой схеме мы поняли, что, в принципе, это работает.
Все работает... Почти все… Почти всегда… За исключением некоторых ситуаций. В общем, все хорошо, жить можно.
Что для этого нужно? Для того, чтобы заняться этим процессом, нужно все это подготовить. Неподготовленного человека окунуть в этот процесс – это боль, отторжение, непонимание – зачем, почему, что мне делать.
Потому что инструменты, которые используются в этом процессе, чужеродны для основной массы разработчиков 1С. Они про них даже не знают. Поэтому нужно подготовить docker, рассказать, как это работает и, желательно, людей научить – предоставить им соответствующие материалы.
Так как появляется куча дополнительных действий, лучше эти действия все-таки автоматизировать. Потому что программист – существо ленивое. Если его заставлять что-то делать руками, он будет это саботировать. Поэтому нужно добиться, чтобы какие-то операции перестали требовать его сил и времени. По сути, получилось комплексно.
И после этого можно внедрять.
Таким образом, начался очередной этап подготовки – подготовка к внедрению. Я уже говорил – так как нужно автоматизировать часть операций и сохранить связь с предыдущими наработками, которые все-таки велись многие годы, то мы подняли в качестве CI-сервера Jenkins, подняли на нем задачки для переноса изменений из хранилищ 1С в соответствующие им репозитории Git.
И между делом настроили задачи по сборке из исходников конфигурации и выполнению тестов. Это как раз то преимущество, которое мы предоставили разработчикам – то, что не нужно cf-ники собирать, тестировать вручную – оно само работает. Достаточно закоммитить, отправить, и дальше оно само.
Следующий этап – это документация. Мы зафиксировали соглашения по разработке. Выбрали классическую схему gitflow. Можете почитать, в интернете вся информация есть. Если в общих чертах:
- в ветке master находятся релизы;
- в feature-ветках ведется разработка;
- после тестирования feature-ветка закрывается, попадает в develop (по сути, ночная сборка из нее собирается);
- потом запускается процесс выпуска релиза, и, если все хорошо, изменения приходят в ветку master;
- ветка master накатывается на Production, если так настроено. Если не настроено, то выпускается инсталлятор с необходимыми файлами, которые мы отдаем админам для разворачивания на Production.
Дальше мы подготовили саму документацию и курс обучения, который мы сделали Step by Step.
Наша компания распределена по стране, ее филиалы находятся в разных городах. И провести очное обучение – это долго, дорого и бессмысленно.
Поэтому был подготовлен набор задач, где любой человек, имеющий некоторую IT-подготовку, выполняет последовательность шаг за шагом и приходит к цели. Он получает навыки владения данными инструментами и понимание всей технологии разработки.
Дополнительно к курсу обучения приложили документы для расширенного понимания – как Git работает в самом низу, как работать с инструментами автоматизации сборок, какие конфиги править, что можно еще подключить и т.д. То есть, при необходимости что-то изменить, можно в эту документацию подсмотреть и настроить.
Следующим этапом было проведение семинаров и рассказ о том, как же это все будет работать.
Для большинства все это казалось «китайской грамотой» - что-то нарисовано, и мы говорим: «Оно работает». Кто-то верил, кто-то не очень.
Дальше решили, что мы на себе попробовали, теперь мы соберем пилотную команду, проведем обучение, и один их проект полностью переведем на эту схему.
Те цифры, которые здесь приведены – это по нашему курсу. Где-то от двух дней до недели у людей занимает именно процесс вхождения, обучение новым инструментам и понимание всей этой схемы.
Здесь как раз основными двигателями прогресса были именно молодые специалисты, у которых еще не засох мозг и не было «шор». Многие из них были разработчиками на других технологических стеках, поэтому для них вхождение в новый процесс было интересным.
Процесс игры на пилотной команде занял примерно месяц. После этого мы еще раз провели семинар уже для всей аудитории, еще раз рассказали свой процесс, но теперь уже с привлечением пилотной команды, которая рассказала о том, как они живут, что у них получилось.
Самые основные моменты, которыми они поделились:
- Это то, что теперь отсутствуют проблемы с захваченными объектами, никто никому не мешает, разрабатывай сколько хочешь.
- Не требуется помещать непроверенный код.
- Для редактирования конфигурации можно использовать свой любимый редактор – VSC, IDEA, vim, Notepad++ – кому что нравится. Потому что в большинстве случаев разработка связана именно с доработкой функциональности и разработкой методов в модулях.
Запускаем процесс внедрения. Берем всех разработчиков, делим на потоки, переводим все проекты на платформе 8.3 с управляемым интерфейсом в Git, переносим все изменения, указанной командой архивируем все хранилища, чтобы обратной дороги не было. И, «полетели».
Все было хорошо. Процесс перехода всех команд на новую схему разработки в общей сложности занял где-то порядка 3-х месяцев.
Что получилось в итоге?
После того, как прошло какое-то время и прошел процесс адаптации, мы подвели некоторые итоги:
- количество конфигураций у нас стало больше – безотносительно нашим изменениям;
- количество разработчиков тоже плавно увеличилось – это больше для статистики;
- теперь у нас все исходники лежат в репозиториях, которые защищены и хорошо структурированы;
- каждый коммит у нас связан с задачей в Jira – мы ее используем, как багтрекер;
- мы автоматизировали выполнение некоторых операций (в частности, накатка на тестовый стенд или выполнение тестов вручную) с помощью Jenkins и всегда видим их результат. Разработчики перестали тратить на эти операции свое время. Вместо этого они могут или спокойно кодить, или пить кофе и думать о чистой архитектуре, а работа в это время выполняется.
- Все текущие и новые сотрудники уже обучились, и сам процесс стал более близок к тому, что мы считаем правильным и красивым.
В итоге – ура, мы все сделали, все классно. Сейчас вы все, наверное, думаете, что все это – чудеса, так не бывает, что никаких проблем нет.
Действительно, не все так хорошо. Есть некоторый набор проблем. Я выбрал ключевые, и сейчас по ним пробегусь.
Первая проблема – это процесс экспорта конфигураций в исходные файлы и импорта обратно, который занимает очень много времени. Решение – использовать EDT. Есть другие пути ускорения этого процесса, но они не очень эффективны. А EDT в данном случае очень помогает, потому что с ним постоянный импорт и экспорт конфигураций в исходные файлы уже не требуется.
Следующая проблема связана с разбором конфликтов. Например, если кто помнит мерж обычных форм, когда вы сравниваете формы на уровне конфигуратора – по картинкам сложно понять, что же изменилось. В управляемом интерфейсе стало чуть полегче, но тоже были свои нюансы. А здесь мы имеем дело с файлами, причем, с XML-файлами, с большой размашистой структурой. И иногда в ситуации, когда одна и та же форма одновременно изменена разными разработчиками, чтобы разобраться, какие изменения, из какой ветки, куда ставить – нужно потратить много времени. Потому что Git при мерже в автоматическом режиме может форму «поломать», он никакую структуру не соблюдает, для него это просто текст. Причем, есть интересные моменты, когда этот XML-файл формы можно загрузить в конфигурацию, но при попытке ее открытия в рантайме система уходит в дамп – непонятно почему. Приходится долго разбираться с этой проблемой. Здесь вариант решения – тимлид должен планировать загрузку своих разработчиков и распределять задачи таким образом, чтобы сокращать ситуации, когда несколько разработчиков редактируют один и тот же объект.
Есть проблема с обычными формами. Как я уже ранее сказал, мы выбрали именно платформу 8.3 и только управляемый интерфейс. Обычные формы стандартными средствами 1С, как конфигуратора, так и EDT, не разбираются и не понимаются. Можно использовать различные сторонние инструменты, но, к сожалению, мы себе такое позволить не смогли, и поэтому просто вывели данные конфигурации за рамки этого процесса.
Версия используемой платформы должна быть не ниже 8.3.10 – там решены многие проблемы с экспортом данных в файлы. И, опять же, это минимальная версия платформы, с которой работает EDT в наиболее стабильном режиме.
Одна из самых сложных проблем для решения – это неприятие разработчиками. Как я уже говорил, некоторые разработчики с большим опытом, особенно те, кто привык работать в одиночку и даже на хранилище переходили с трудом. Для них вообще казалось непонятным, зачем это и что с этим делать. Приходилось проводить индивидуальные беседы, встречи и на пальцах показывать, какой профит человек получит. Сложная задача.
Проблемой для нас было использовать одновременно и Git, и хранилище. Хотя в некоторых инструкциях от вендора и присутствуют такие примеры, даже расписана методика, как это делать – я лично использовать их совместно не рекомендую. Проблем становится больше и работы становится больше из-за постоянного выполнения мержа из Git в хранилище и из хранилища в Git. Усложнение схемы и стоимость ее поддержки гораздо выше, чем неиспользование хранилища вообще.
При использовании новой системы контроля версий и при использовании EDT, в любом случае, вам потребуется увеличение ресурсов на инфраструктуру. Тут никуда не деться. Рабочие машины разработчиков придется апгрейдить, сервер для Git-сервера придется выделить, а то и не один, если мы хотим, чтобы все бэкапировалось и стабильно работало с распределенной нагрузкой. Тут вариантов нет. Либо мы покупаем собственное железо, либо идем в «облака» и используем облачное решение. Оно тоже очень неплохо работает.
Интересное следствие – это повышение стоимости таких разработчиков на рынке. Можете посмотреть на HeadHunter, там сейчас уже много вакансий, где для 1С-разработчиков указаны требования по владению технологиями работы с Git, с тестами и т.д. Если вы хотите, чтобы ваши разработчики об этом не узнали, единственный вариант – отбирайте паспорта, отключайте интернет и т.д. Других вариантов нет.
Что делаем сейчас, куда движемся?
Небольшое хвастовство:
- Мы продвигаем развитие CI/CD. Очень много контрибьютить в OpenSource не получается, но все-таки, немного в сообщество мы возвращаем.
- Продолжаем развивать процесс автотестирования и инструментарий разработчиков.
- У нас есть несколько вариантов, с помощью которых мы все-таки планируем «затянуть» конфигурации на обычных формах в Git.
Резюме.
- Не стоит бояться этой схемы. Надеюсь, мой рассказ помог кому-нибудь сдвинуться с места. Но вы должны понимать, что нужно развиваться.
- Быть первым в этом процессе, как и в любом другом, всегда сложно.
- Нельзя просто заставить людей что-то сделать. Это не работает. Нужно именно провести процесс внедрения. Комплексно: тестирование, обучение, опытная эксплуатация, релиз. По-другому никак.
- И, самое главное, верить в себя.
В самом конце хочу высказать благодарность компаниям, продукты которых мы активно используем в своих процессах. Здесь я перечислил основные:
- сообщество OneScript;
- команда, развивающая sonarqube;
- Visual Studio Code;
- Allure;
- GitLab;
- Atlassian;
- и коллеги из команды «Серебряная пуля», генераторы идей и некоторых инструментов.
Вопросы:
А как вы все-таки решаете вопросы с объединением форм, когда они рушатся?
Первое: если вы используете EDT, не используйте его возможности работы с Git. Второе: мы уже достаточно неплохо разобрались со структурой, знаем ключевые моменты. Поэтому – распределение задач. Если мы понимаем, что с одним объектом будет работать несколько человек, то мерж проводится с дополнительным контролем, когда человек выполняет закрытие фичи, ему прилетает изменение из dev, инструменты Git позволяют показать изменения и показать конфликты. Конфликты правятся в kDiff с включением интеллекта и использованием некоторых скриптов на OneScript. Есть интересная утилита для мержа XML от компании Oxygen, только она очень дорого стоит.
Речь идет не о типовых конфигурациях? Потому что я знаю, что в EDT нельзя снимать с поддержки и т.д.
По поводу поддержки – пример с типовыми конфигурациями. У меня есть ветка в репозитории, которая называется HRM, и там лежит поставка от вендора. А в корне проекта у меня лежит .gitattribute, в котором написано, что
parentconfiguration.bin merge=ours
То есть, я его не переношу из этой ветки. Когда мне нужно обновить типовую, я ее обновляю из соответствующей ветки, потом переношу эти изменения в основной ствол, а там у меня версия без поставки. И я продолжаю разрабатывать. Потому что я не лезу в объекты, которые на поставке. А для типовых – берите расширения, они отлично работают. С небольшими хаками они вообще хорошо работают.
Почему именно Git, а не Mercurial и не Bazaar?
У Mercurial проблемы с длинными именами и русским языком. Питонисты ничего про русский язык не знают, для них код и файлы не должны быть на русском. А по поводу Bazaar – чтобы проверить, возьмите ERP, откройте конфигуратор, выгрузите в файлы и попробуйте закоммитить 5,5 миллионов строк в Git и в Bazaar. И посмотрите, кто из них первый рухнет. Git выдерживает. Все остальное – нет.
Есть ли какие-то советы по оттачиванию этого навыка мержа, потому что вы озвучили пример форм, а там еще есть роли, общие реквизиты и прочее. Мы пользуемся Git, но мержить в голом виде какие-то сложные изменения – это что-то невероятное. А этот вопрос вообще нигде практически не затронут.
Во-первых, у вас никто не отбирал конфигуратор. Если у вас проблемы с мержем в Git, вы можете воспользоваться конфигуратором и средствами сравнения-объединения, привычными вам. Это – первый вариант. Второе – есть скриптинг. У всех XML-файлов вполне понятная структура, которая неплохо разбирается. И здесь можно использовать самописные мерж-хуки Git под формат роли, чтобы выполнять их объединение по структуре. Подобная ситуация есть у коллег из сообщества C# - они тоже мержат XML-файлы при слиянии проектов. Можно по аналогии сделать и для 1С-ных файлов. Нормальных, всеядных утилит для объединения XML, к сожалению, нет.
Когда вы вносите изменения, вы же понимаете, какие изменения вы вносите. Если вы роли не трогали, а они у вас изменились – а они изменяются, если у вас стоит автоматическое назначение прав и т.д. Соответственно, это вполне прогнозируемая ситуация. При объединении с другой ветвью, вы можете посмотреть, какие изменения были внесены другим разработчиком и просто перенести эти изменения к себе. Есть такая вещь, как cherry-pick, можно забрать коммит разработчика, связанный с этой ролью, в свою ветку.
А все-таки, вы разработку ведете именно в конфигураторе, а потом выгружаете это все в файлы и в Git, или непосредственно, в EDT?
И так, и так. Сейчас в приоритете разработка через конфигуратор, а EDT мы пока что активно тестируем. Там есть набор нюансов. У нас, допустим, на данный момент проблема в том, что часть конфигураций работает под интерфейсом 8.2, а EDT умеет работать только под «такси». Вторая глобальная проблема – EDT не умеет работать с внешними источниками данных, он их определяет, как undefined, тут без конфигуратора никак. Но в ближайшее время, как только в EDT еще некоторые баги поправят, мы планируем полностью перейти на него.
Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2018 EDUCATION.
