1. Введение: трансформация SAP-разработки под давлением DevOps

Темп цифровых изменений стал важнее объёма инвестиций. Бизнес перестал ждать, когда ИТ-подразделения завершат очередной релиз: результат требуется здесь и сейчас, а паузы между идеей и реализацией измеряются днями, не кварталами. По данным State of DevOps Russia 2024 (CNews.ru), DevOps-подход перестал быть атрибутом продуктовых компаний и укореняется в промышленности, госсекторе и корпоративных бизнес-системах.

«Тройка лидирующих отраслей сохраняется с 2020 года: информационные технологии, финансы и торговля. Наблюдаем значимое сокращение доли ИТ — с 45,5% респондентов до 36,2%. Доля финансового сектора сократилась на 2,4% и составляет 12,4%. Доля остальных секторов в совокупности выросла» (Исследование состояния DevOps в России 2024 / «Экспресс 42», devopsrussia.ru).

Для SAP-ландшафтов это означает: время «редких поставок» прошло — архитектура процессов должна измениться, иначе скорость превратится в узкое место конкурентоспособности.

Тот, кто работал с SAP-транспортами, знает, как легко устойчивость системы оборачивается инерцией. Между первым заявлением о требовании и его внедрением проходит месяц — и бизнес уже ждёт другого. В этом смысле DevOps для SAP — не новый инструментарий, а новая форма дисциплины: способ сократить разрыв между осознанием необходимости изменения и его поставкой. Там, где этот разрыв сохраняется, растёт технологическая задолженность и риск сбоев при релизах.

В инженерных терминах DevOps — это управляемая петля обратной связи между кодом, инфраструктурой и пользователем. Для SAP-систем она должна включать все этапы — от фиксации изменения в Git до доставки через производственную цепочку. Когда эта петля замкнута и автоматизирована, скорость перестаёт быть риском и становится средством контроля качества.

1.1 Как создавалась транспортная модель SAP и почему она больше не справляется

Когда в SAP создавалась транспортная система CTS, парадигма разработки была линейной. Изменение проходило предсказуемый маршрут: разработка → тест → продуктив, а главной задачей считалась консистентность данных и защита от хаотичных правок. В 90-е это было инженерным достижением: централизованная цепочка, строгие окна релизов, гарантии целостности объектов. Система прекрасно справлялась с редкими изменениями, когда продукт обновлялся раз в несколько месяцев и команды работали в одном часовом поясе.

Но там, где ландшафт стал распределённым, транспортная модель превратилась в узкое горлышко. В больших компаниях десятки разработчиков создают параллельные ветки решений — и любое ручное согласование задерживает интеграцию. Один неудачный импорт транспортов может заблокировать весь поток. Многие команды сталкиваются с одной и той же картиной: изменения накапливаются неделями, QAS отстаёт от DEV, а первые тесты на продуктивной среде превращаются в лотерею. Эти симптомы не ошибки администраторов, а свойства архитектуры, где контроль встроен в последний этап, а не в каждый.

Современная практика программной инженерии изменила саму логику поставки. Репозитории Git, pull request-процессы и автоматические проверки кода стали де-факто стандартом. В такой среде качество контролируется не на выходе, а в момент создания изменения. Для SAP-проектов это не просто технологическая адаптация — это смена причинно-следственного порядка: не «мы доставляем, чтобы проверить», а «мы проверяем, чтобы доставить». Когда транспорт перестаёт быть единственным «контейнером доверия» и становится элементом управляемого конвейера, система возвращает себе гибкость, а разработчики — возможность двигаться с рыночной скоростью.

Чтобы увидеть, насколько различаются две модели не на схеме, а по сути, сравним их по ключевым признакам. Табл. 1 показывает, где именно возникает инерция в классической модели и как DevOps-подход перераспределяет контроль и ответственность.

Табл. 1. Сравнение транспортной и DevOps-модели поставки изменений в SAP

2. Портрет рынка DevOps в России в целом и в SAP-среде

Российская индустрия DevOps вышла из фазы энтузиазма и перешла к состоянию неравномерной зрелости. По данным State of DevOps Russia 2024, распределение компаний по профилям эффективности выглядит следующим образом: Elite — 19 %, High — 39 %, Medium — 33 %, Low — 9 % (см. Рис. 1). Эти категории формируются не по самооценке, а по четырём метрикам эффективности — частоте развёртываний, сроку поставки, времени восстановления и доле неуспешных изменений. Именно сочетание этих показателей позволяет судить о реальной устойчивости процессов, а не об уровне заявленных практик.

Рис. 1. Распределение профилей эффективности DevOps-практик (по данным State of DevOps Russia 2024, стр. 46). Для сравнения приведены значения 2023 года и глобального отчёта Accelerate 2023

Если сопоставить российские показатели с результатами Accelerate 2023, различия становятся заметнее. По частоте развёртываний и скорости поставки российские команды уступают зарубежным почти во всех профилях, но при этом демонстрируют сопоставимую, а в сегменте Low — даже лучшую, долю неуспешных изменений. Такая разница объясняется методикой: в Accelerate измеряется время восстановления только после неуспешных релизов, тогда как в российском исследовании учитываются все инциденты. Это делает сравнение направлений тенденций корректным, но не позволяет прямо сопоставлять абсолютные значения метрик.

Для SAP-ландшафтов все эти закономерности проявляются особенно отчётливо. Автоматизация здесь сталкивается не столько с техническими, сколько с организационными и нормативными барьерами: цепочки транспортов CTS, обязательные согласования, разделение ответственности между разработкой и эксплуатацией. Многие команды внедряют CI/CD только в пилотных проектах, не решаясь затронуть основные контуры производственной среды. Поэтому картина в SAP-сегменте воспроизводит общую структуру российского DevOps-рынка: несколько зрелых центров компетенций, окружённых широким полем осторожных и фрагментарных внедрений.

DevOps в SAP стал неотъемлемой частью профессионального языка, но пока не стал нормой повседневной практики. Между тем именно в таких переходных состояниях рождаются зрелые подходы — не из деклараций, а из множества мелких инженерных решений, накапливающихся в коллективный опыт.

2.1 Динамика и метрики зрелости

Рост числа вакансий с пометкой DevOps выглядит как признак зрелости рынка, но на деле отражает скорее тренд, чем устойчивое развитие. На hh.ru и в профильных каналах количество таких позиций растёт из года в год, однако путь от появления вакансии до внедрённой практики занимает месяцы, а порой и годы. Многие организации объявляют о «внедрении DevOps», создают роли, выбирают инструменты, но останавливаются на пилотной фазе. Автоматизация остаётся локальной, компетенции — персональными, а изменения не переходят границу проекта. Так формируется характерная черта российского рынка — локальная зрелость: отдельные команды демонстрируют высокий уровень практик, не влияя на общую культуру поставки.

Данные State of DevOps Russia 2024 подтверждают этот контраст. Доля профиля Medium выросла с 28 % до 33 %, но метрики почти не изменились. Частота развёртываний у большинства компаний снизилась, время восстановления выросло. Это не спад — скорее признак насыщения: рынок достиг фазы, когда скорость распространения практик ограничена внутренними процессами. Новые специалисты появляются быстрее, чем инфраструктура готова их принять.

Для SAP-ландшафтов эта ситуация имеет собственные формы. Системы связаны множеством зависимостей: аудит, безопасность, поддержка вендорских обновлений, требования к версии ядра, изолированные контуры и middleware-уровни. Даже при наличии инструментов (gCTS, abapGit, Jenkins) и процедур (Quality Gates, lint-проверки, ATC) препятствием остаётся согласованность между командами. DevOps здесь натыкается не на технологический потолок, а на управленческий.

Чтобы увидеть, как это отражается на данных, полезно взглянуть на медианные значения ключевых метрик (см. Табл. 2).

Табл. 2. Медианные значения основных метрик DevOps-профилей (по данным State of DevOps Russia 2024, стр. 45)

Сравнение профилей показывает: зрелость практик неравномерна даже внутри верхних уровней. Разница между Elite и High почти не затрагивает надёжность релизов, но заметно отражается на темпах поставки. Средний профиль (Medium) оказывается устойчивым, но медленным — он обеспечивает предсказуемость ценой скорости. Low-команды, напротив, страдают от длительных циклов и высокого процента откатов, что замыкает их в порочном круге: редкие релизы → рост накопленных изменений → увеличение рисков при внедрении.

Для SAP-организаций аналогичные закономерности видны на уровне транспортов и релизных окон. Большинство компаний сохраняют ручное согласование между системами DEV, QAS и PRD, из-за чего частота поставки ограничена внутренним календарём. При этом метрики качества кода (ATC, abaplint, SonarQube) внедряются быстрее, чем сквозные пайплайны — показатель зрелости сдвигается в сторону анализа, а не поставки.

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

2.2 Особенности SAP-ландшафтов: архитектурные ограничения и контуры контроля качества

В классическом ИТ-контуре внедрение DevOps упирается в организационные барьеры, но в SAP-среде препятствия встроены в саму структуру платформы. Архитектура SAP изначально создавалась как монолит с жёстким разделением зон ответственности: ядро, словарь данных, модульные компоненты, транспортная модель CTS. Каждый из этих уровней связан с остальными множеством зависимостей, которые нельзя разорвать без потери целостности системы. ABAP-код жёстко привязан к версиям ядра, типам баз данных, объектам DDIC и перекрёстным интерфейсам модулей. Попытка изолировать компонент и вести его развитие в отдельном потоке требует сохранения идентичности зависимостей и контекста исполнения, что в реальных проектах почти недостижимо. Параллельное развитие модулей быстро сталкивается с конфликтами версий, перекрытиями структур и нарушением консистентности данных между системами DEV, QAS и PRD.

Эта связанность не является изъяном. Она отражает философию SAP как корпоративной системы, где приоритетом остаётся устойчивость системы, а не скорость разработки. Классическая DevOps-модель с короткими спринтами и частыми релизами нуждается здесь в адаптации: нужно учитывать ритм обновлений ядра, совместимость пакетов, порядок транспортов и график системных окон. Попытка игнорировать эти ограничения не ускоряет процесс и провоцирует увеличение технических рисков. Поэтому зрелый DevOps в SAP начинается не с внедрения CI/CD-инструментов, а с признания архитектурной физики самой платформы.

Не меньшее значение имеет культура контроля качества. Инструменты ATC, Code Inspector и abaplint образуют систему «приемки», призванную останавливать код до включения в транспорт. В теории это главный барьер против деградации, но на практике именно их настройка часто становится слабым звеном. SAP-сообщество всё активнее обсуждает, как адаптировать проверки к концепции clean core: какие правила включать в ATC, как различать ошибки совместимости и архитектурные дефекты, каким образом встроить проверки в Jenkins-пайплайн.

Проект abaplint, создававшийся как открытый анализатор ABAP-кода, за несколько лет превратился в полноценный инструмент, интегрирующийся с ATC и Code Inspector и позволяющий выявлять ошибки ещё до загрузки кода в систему. Однако большинство команд по-прежнему ограничиваются ручным запуском инспекции и не включают результаты в метрики сборки, что делает «приемку» скорее формальностью, чем реальным фильтром.

Так возникает типичная особенность зрелости SAP-проектов: чем совершеннее инструменты контроля, тем выше риск, что ими будут пользоваться выборочно. DevOps в SAP, в отличие от opensource-проектов, строится не на доверии, а на регламенте, и именно поэтому подлинная зрелость начинается там, где автоматизация проверок становится не требованием, а частью профессиональной привычки. Специфика SAP не в том, что DevOps здесь сложнее, а в том, что он начинается с архитектуры — а не с инструментов.

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

3. Переход к CI/CD в SAP: преодоление препятствий

Главная трудность перехода к CI/CD в SAP не в инструментах и не в автоматизации, а в ментальном сдвиге. Любой пайплайн — даже выстроенный по всем правилам — не работает, если команда по-прежнему мыслит категориями «релизного окна», а не непрерывной поставки. Чтобы процесс стал живым, нужно научиться принимать собственные ошибки как часть итерации, не искать виновных и оценивать качество не постфактум, а на входе. Это требует доверия между разработкой, поддержкой и эксплуатацией — того, чего в SAP-среде исторически не было: здесь каждая роль формировалась на разделении ответственности.

Конфликт «старой гвардии» и новых практик ощущается в деталях. Администраторы, привыкшие к ручным проверкам, видят в автоматизации угрозу стабильности. Разработчики, наоборот, воспринимают контроль как избыточный. Руководители проектов балансируют между страхом «сломать систему» и требованием ускорения. В SAP-ландшафтах этот страх особенно оправдан: ошибка в продуктовом контуре способна остановить бизнес-процессы на сутки. Поэтому сопротивление новому не является консерватизмом — это форма профессиональной ответственности.

CI/CD в SAP — не реформа, а изменение основания. Здесь мало просто соединить abapGit с Jenkins и ввести проверки ATC: нужно выстроить общий контур доверия, где каждая итерация безопасна, потому что обратная связь коротка и понятна. Именно это отличает зрелую DevOps-культуру от механического копирования инструментов.

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

3.1 Организационные и культурные препятствия при переходе к CI/CD

Главное недопонимание при переходе к DevOps в SAP — это восприятие «транспорта» как линейного коридора, а не как состояния кода. Исторически транспортные запросы CTS/STMS рассматривались как последовательные этапы движения изменений: разработка, тест, продуктив. В CI/CD-парадигме код существует одновременно в нескольких версиях, а ветвление и слияние — не исключение, а способ управления рисками. Но для многих SAP-команд сама идея параллельных веток кажется угрозой стабильности: конфликты объектов, DDIC-структур, зависимостей. Поэтому Git воспринимается не как инструмент контроля версий, а как источник хаоса, а pull request — как избыточный ритуал, а не точку коммуникации. Отсюда — инерция: code review остаётся на бумаге, а поставка по-прежнему делается пакетами, собранными вручную.

Когда команды распределены по регионам и филиалам, сопротивление усиливается. Разработчики из разных зон ответственности вносят правки в одни и те же объекты, и конфликт становится не только техническим, но и организационным. В централизованных системах SAP это означает задержки, перекрёстные тесты, дублирование усилий и рост транзакционных издержек. Каждый релиз превращается в сверку, где главное — не качество кода, а совпадение версий. Коммуникационные разрывы в таких проектах стоят дороже, чем ошибки сборки: они парализуют движение изменений на недели.

CI/CD требует иной логики совместной работы. Если раньше ответственность заканчивалась на границе системы, то теперь она распределена по всей цепочке поставки. Успешные команды не борются с ветвлением — они учатся делать его безопасным. Не избегают pull request, а используют его как пространство для обсуждения архитектуры. Это не изменение инструмента, а переход культуры — от передачи артефактов к совместному владению кодом.

3.2 Технические и инструментальные барьеры интеграции SAP с CI/CD

Даже при готовности команд и поддержке руководства переход к DevOps в SAP упирается в технологические ограничения самой среды. Интеграция транспортной модели SAP с внешними системами контроля версий и сборки выглядит на схеме просто, но на практике сталкивается с множеством несовпадений. Транспорт — это не файл и не репозиторий, а цепочка зависимостей, в которой изменение одного объекта может потребовать пересборки целого набора артефактов. SAP изначально не проектировался для двусторонней синхронизации с Git: система не различает понятия ветки, а её внутренние ID-зависимости не всегда сопоставимы с коммитами. Поэтому каждая интеграция с Jenkins, GitLab или Azure DevOps требует ручной настройки и учёта сценариев, где транспорт и коммит расходятся по смыслу.

Даже инструменты, созданные специально для анализа кода в SAP-среде, требуют аккуратной калибровки. ATC и abaplint по сути выполняют одну задачу — предотвращают деградацию качества, — но на практике легко перегружают отчёты ложными срабатываниями. Избыточные проверки демотивируют разработчиков и превращают автоматизацию в источник шума. Баланс между строгими и допустимыми предупреждениями устанавливается опытным путём: каждое правило должно иметь владельца, иначе механизм контроля теряет доверие.

Особая сложность — работа с ветвлением и слиянием. ABAP-объекты, связанные с DDIC, CDS-вьюхами и интерфейсами, не поддаются простой стратегии merge или rebase. Даже небольшое изменение структуры может затронуть зависимые артефакты, и система не предложит автоматического решения. Конфликты часто проявляются уже после импорта транспорта в QAS, когда исправления одного разработчика перекрывают работу другого. Повторные выгрузки и ручные корректировки не только замедляют релизы, но и подрывают доверие к самой идее параллельной разработки. Git в таких сценариях становится не помощником, а посредником между двумя несовместимыми логиками — линейной SAP-цепочкой и ветвящейся моделью CI/CD.

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

Организационные, культурные и технические барьеры образуют единую цепочку сопротивления. Ошибки настройки пайплайна — лишь следствие глубинных разрывов между архитектурой SAP и философией DevOps. Для преодоления этих разрывов нужны не только инструменты, но и методика, которая позволяет выстраивать последовательную архитектуру поставки изменений. Именно этому будет посвящён следующий раздел — о практических шаблонах CI/CD для SAP-проектов и способах интеграции контроля качества в полный жизненный цикл кода.

Продолжение следует.

Автор

Никита Калуцкий

Эксперт по программированию на ABAP.
Разработчик на АВАР с 2008 года.
Участник разработки стандартного кода SAP. Эксперт по качеству продуктов SAP в компании САП СНГ.
Ведущий программист компании Северсталь до 2019 года.
Главный программист корпорации «Транснефть».
Более 5 лет опыта преподавания в Учебном центре Эксперт РП.
Создатель авторских курсов по языку программирования АВАР.