В современном IT мире вокруг различных практик, объединенных общим названием DevOps, возникло достаточно много хайпа. Стоит отметить, что достаточно обоснованного, т.к. применение данных подходов во многих случаях позволяет не то что увеличить производительность команды или скорость выпуска продукта, а просто сделать это возможным в принципе. Для некоторых компаний и команд DevOps трансформация стала просто спасением.
Отдельные практики DevOps дошли сейчас даже для 1С. В частности – много внимания мы уделяем сейчас CI/CD. Но давайте разберёмся – что реально может дать CI/CD команде разработки 1С. С точки зрения «Best Practice», конечно, этим заниматься надо, но откуда берётся эффективность?
Откуда взялось CI/CD? Какие задачи при помощи них решали?
Для начала несколько лирическое отступление на тему «откуда пошло CI/CD». Очевидно, что CI/CD пришли к нам из других направлений разработки, в частности из Web команд, как и множество других инноваций. Как работают Web команды? Примерно вот так:
Суть в том, что одну фичу может делать 2-3 человека. Как минимум принято разделять Frontedn и Backend разработчиков. В нормальной команде существует ещё DBA или разработчик БД, отдельный дизайнер и отдельный верстальщик, не говоря уже о наличии QA как такового. И где тут проблемы?
Дело в том, что при подобной разработке часто одну и ту же фичу разрабатывают разные люди. Представьте себе, что один разработчик делает форму документа, а второй пишет проведение, третий ещё отдельно создаёт регистры для проведения документа и определяет состав и порядок его реквизитов. Весело? Теперь вы понимаете все проблемы Web разработчиков. Но это ещё не всё. Когда вы ведёте коллективную разработку в 1С, вы уже привыкли, что работаете с объектами по принципу «Это моё»: захватили и «пусть весь мир подождёт». Web разработчики не привыкли в чём то себя ограничивать – представьте, что вы редактируете конфигурацию как набор XML файлов и модулей где нибудь в блокноте. Можете править любой файл, никто вам не запретит. А как же система хранения версий? Да нормально – вы работаете в своей ветке, пишите спокойно «git commit» потом «git push»… Самое интересное начинается после – начинается что-то похожее на это:
Это называется «Merge» и чем то напоминает процесс «Сравнения и объединения конфигурации». Ну не оно ли:
Вспоминаем, как мы очень жутко не любим сравнение и объединение конфигураций и пытаемся его всячески избегать. А вот Web разработчики не избегают, таким образом их «история хранилища» выглядит как то так:
Как и у нас они на эту тему тома пишут https://habr.com/post/195674/
К слову, стоит сказать, что большинство из этих merge-ей проходят автоматически, но, я думаю, уже очевиден масштаб проблемы и к чему это всё может привести? Правильно – к тому, что большую часть своего времени команда разработки будет мёрджить код, а оставшуюся половину будут исправлять ошибки возникшие в ходе неверного мёрджа, эта команда со временем начинает выглядеть вот так:
Сколько при таком подходе будет выпускаться готовый продукт? Да сколько угодно! Притом, без преувеличений, даже просто получить рабочую версию системы в большинстве случаев бывает проблемой. А если система состоит из микросервисов, то вообще вскоре «заблудитесь» что где работает а что нет? В случае микросервисной архитектуры традиционные и привычные подходы вообще скорее всего являются невозможными? В этом случае концепция CI/CD кажется просто спасением – после каждого коммита нужно собирать систему целиком, и проводить полное или хотя бы базовое тестирование всего функционала. Таким образом, практически исключаются большие «мерджи», которые ломают всю систему, и она всегда находится в некотором стабильном состоянии. Соответственно – главным назначением практики CI/CD – является решение проблемы больших мёрджей и их последствий, а также упрощение выпуска релиза системы.
А что в 1С?
А в 1С всё просто: в базовом варианте в команде разработки 1С нет возможности изменять один и тот же кусок кода. «Захватить в хранилище» и до свидания. Хранилище 1С не поддерживает ветвлений, это делает процесс разработки предельно линейным, что в целом эффективно для небольших команд. Но при этом мы теряем все преимущества процесса параллельной разработки. Соответственно в большой команде разработки 1С иногда можно наблюдать примерно такой процесс:
Процесс работы с разными объектами конфигурации строго последователен, зато нет никаких коллизий, мерджей, веток, их слияния… Для небольших команд это, пожалуй, наиболее правильный вариант, для больших жутко неэффективно. По аналогии можно сравнить как табличные и построчные блокировки. Если в базе работает 2-3 человека – нет смысл поддерживать всю инфраструктуру для построчных блокировок – табличные будут эффективнее, но если в базе человек 50 и более, то с табличными блокировками вы просто всё время будете «в режиме ожидания».
Конечно, «опытные 1С-ники» меня сейчас поправят. Как так, а у нас – параллельная разработка на 1С реализована:
https://its.1c.ru/db/v8std/content/-2145782938/hdoc
Конечно, такой вариант возможен, как и альтернативные с использованием выгрузки конфигурации в XML или файлы, v8Unpack и прочих извращений. Но в данном случае в разы увеличиваются трудозатраты на поддержание инфраструктуры. Едва ли можно отыскать команды, для которых параллельность разработки в 1С настолько важна, что затраты на такие манипуляции будут окупаемы. Тем не менее, такие команды встречаются. Чаще всего такая потребность в параллельности возникает в случае, когда на платформе 1С решают «не 1С-ные задачи». Что я понимаю под «Не 1С-ными задачами»? Ну это когда у вас 99% функционала системы сосредоточено в 2-3 документах, у каждого из которых по 50 реквизитов, при этом команда разработки насчитывает более 10 человек. Почему «не 1С-ная задача?». Платформа даёт нам кучу преимуществ для решения учетных задач, а также схожих. Если требуется много объектов, много разнообразной функциональности, она приближена к учетным задачам, то использование платформы 1С даёт кучу преимуществ как при использовании так и при разработке. Но в случае, когда вам нужно 2-3 формы, в которых будут работать конечные пользователи, на них выстроены определенные процессы, то мы сразу сталкиваемся с ограничениями, как пользовательскими (а мы тут хотим произвольный интерфейс), так и техническими (разрабатывать одну форму может без проблем только один программист).
Что же получается, тупик? Автоматизация учетных задач – это предел, что нас ожидает с текущей платформой? Параллельная разработка и gitflow для нас – непозволительная роскошь? К счастью, есть определенные предпосылки, позволяющие сказать, что всё не совсем так.
Что нам приносит EDT?
Enterprise Development Tools – пожалуй, самое обсуждаемое среди разработчиков нововведение в платформе 1С. Одним из основных назначений его появления должна быть нормальная параллельная работа. В случае с EDT система контроля версий – это GIT. С конфигурацией вы работаете как с набором файлов, ничего нигде не лочите. Можете создать себе ветку, можете провести слияние веток. При этом слияние учитывает, естественно, специфику 1С. У вас появляется возможность сделать нормальный precommit, написать своё расширение и многое другое. Но на данный момент его использование в реальной разработке весьма сомнительно. EDT несёт в себе очень много недостатков:
1) Очень прожорливо, ну просто очень. Вот такие показатели у меня отображаются в диспетчере задач при нормальной работе:
Даже при современном уровне мощностей далеко не каждый может себе позволить такую расточительность
2) Не поддерживает и никогда не будет поддерживать обычные формы. А сейчас это очень большой пласт прикладных решений, особенно тех в которых ещё ведётся разработка
3) Нет нормальной автоподстановки. В Eclipse её и для Java то нормальной нет, а для 1С не понятно появится ли. До возможностей конфигуратора со встроенным Снегопат-ом, соответственно, ещё очень далеко
4) Написано это всё на Java, соответственно будет медленно, прожорливо и иметь убогий внешний вид. Java – не тот язык разработки, на котором следует разрабатывать нативные приложения с пользовательским интерфейсом. Сам отклик интерфейса будет дольше, не говоря уже о прожорливости JVM.
5) Всё очень долго – импорт проекта, запуск проекта, открытие формы и т.п. теряется драгоценное время. А именно оно ценно для среды разработки. Eclipse традиционно был самой тугой средой разработки, а с появлением в ней кучей «плюшек» для разработки 1С стал просто невыносим.
6) В основу взят Eclipse, в то время как наши соотечественники из JetBrains разработали куда лучшую IDE даже для того же Java (IntelliJ IDEA). В настоящий момент времени Eclipse уже безнадежно проигрывает по всем параметрам ведущим современным IDE, так что даже после завершения разработки EDT, уровень наш инструментов будет далёк от того, которым пользуются наши коллеги из других языков разработки.
Таким образом, если говорить о процессе CI – когда постоянно происходит сборка кода, его проверка, автоматическое слияние - для 1С в настоящее время едва ли актуален.
Хотелось бы сказать что-нибудь хорошее про процесс CD – на Production надо выкатывать как можно быстрее, но тут тоже есть ограничения платформы. За многие годы развития мы так и не ушли до конца от монопольного режима при обновлении. Какое уж тут CD. Опытные 1С-ники, конечно, скажут, что всё решаемо. Делается РИБ и переключение, или обновляется вручную структура СУБД и текущая конфигурация… Но это очень далеко от принципов CD, а наоборот, требует тщательного планирования и ручного контроля.
Кроме того, базовые практики CI подразумевают покрытие тестами всего кода. Но на проектах 1С большинство кода никак не относится к вашей команде разработки. А автоматизированное развертывание и покрытие его тестами займёт чаще всего больше времени, чем сам проект.
Теперь давайте посмотрим, как построен стандартный процесс CI где-нибудь в Web разработке:
Происходит примерно следующее:
1) Вы делаете commit
2) По Webhook запускается CI процесс
3) Разворачивается docker контейнер тестовой среды (она же небольшая – некий объём кода и начальная БД)
4) Выполняются unit тесты (помним что весь код в вашем приложении написала ваша команда и она же покрыла его тестами)
5) Выполняется проверка кода
6) Вы получаете красный или зелёный свет.
Где будут проблемы у 1С? Правильно – везде. Если (1) и (2) как то удастся преодолеть, то на этапе (3) у вас явно возникнут проблемы, но с ними ещё можно справиться, а вот покрыть юнит тестами весь код УПП…
В общем, поразмыслив над всем этим, я по традиции обратился «к старшим братьям», или к SAP. Потому что что-то подсказывает, что у них точно такие же проблемы.
И как же дела c CI/CD у SAP?
И первое, на что наткнулся на просторах интернета:
Потом на статью, в которой человек жалуется, как в SAP всё плохо с DevOps https://blogs.sap.com/2015/11/09/continuous-integration-for-sap/ и в конце концов на статью другого человека, который придумал несколько «кустарных методов»: https://blogs.sap.com/2017/11/11/continuous-integration-in-abap-using-jenkins/
К слову, с DevOps у SAP плохо только на ABAP – там где пишутся внутренние транзакции. У SAP есть куча Web и Java разработки, тот же UI5, где CI/CD успешно применяются.
Так и в 1С – в отдельных проектах (к примеру, разрабатываете вы сложный «внешний модуль») применение практик CI/CD вполне оправдано.
Но в общем и целом, при разработке ERP систем CI/CD практики конечно должны как минимум проходить переосмысление. Контекст несколько другой, относительно типовых сценариев.
Так что же теперь, забить на весь этот DevOps?
Нет, конечно же нет. DevOps – это правильный и трендовый подход. Неприменимость отдельных элементов не означает что он сам по себе не нужен. Когда пишете код, нужно задумываться, как он встанет на сервер, какие внешние ресурсы потребуются, как нужно обновить рабочую базу, что делать, если будут проблемы после обновления. Нужно по максимуму автоматизироваться:
• Автоматизируйте обновление Production баз, к примеру так: //infostart.ru/public/661836/
• Автоматизируйте тестирование релизов, к примеру так: //infostart.ru/public/723210
• Автоматизируйте развертывание тестового окружения, к примеру вот так: //infostart.ru/public/542836/
• Автоматизируйте проверку кода, к примеру вот так: http://v8.1c.ru/acc/
• Запускайте автоматизированные тесты на отдельной машине
• Проверяйте код на копипасту, к примеру вот так: //infostart.ru/public/294285/
• Проверяйте код на излишнюю сложность, к примеру так: //infostart.ru/public/166182/
Список открыт. В целом, большинство подходов к разработке ПО применимы и в «мире 1С» конечно, но есть определенные нюансы. Не надо их бояться и избегать, просто перед тем как что-то позаимствовать «у старших братьев» - проанализируйте внимательно, что вам это даст и какие трудозатраты повлечёт.
Вступайте в нашу телеграмм-группу Инфостарт
