Ключевое понятие

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

Для типичного трёхсистемного ландшафта SAP существует несколько вариантов переноса изменений из среды разработки в тестовую среду и затем в продуктив. Со временем, и особенно после появления SAP Solution Manager и управления запросами на изменения (ChaRM), процесс стал гораздо более стабильным и организованным, но также и более сложным. Кроме того, SAP предложил концепцию параллельных (dual-track) ландшафтов, которая стала широко использоваться как более удобная альтернатива обновлению или переключению систем.

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

Примечание

Настоящая статья посвящена оптимизации релизного процесса и не рассматривает вопросы настройки и использования управления запросами на изменения. Автор предполагает, что читатель знаком с управлением релизами с использованием ChaRM.

Спустя 18 месяцев после продуктивного старта и приобретения некоторого опыта как в небольших, так и в крупных релизах во втором проекте, команда пришла к выводу, что существуют и другие способы управления проектами, помимо простого и лёгкого с технической точки зрения ChaRM. С некоторой помощью со стороны SAP, изучив множество литературы, проектная команда обнаружила альтернативу. Она чуть более сложна технически, однако имеет значительные преимущества с точки зрения процесса управления релизами. Команда начала изучать этот вариант и внесла в него некоторые усовершенствования, приспособив к имеющейся в организации модели управления релизами.

Эти два варианта следующие:

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

Первый вариант — самый простой для понимания и использования: единый цикл и переключение его фаз в зависимости от различных активностей. Например, после перевода всех фаз к выходу в продуктив («Go Live») и завершению релиза («Finish of a Release») возможно переключить фазу обратно к подготовке к продуктивному старту («Go Live Preparation»), к тестированию («Test») и к разработке с последующим релизом («In Development with Release»). С технической точки зрения это позволяет продолжить нормальную разработку и тестирование следующей порции функциональности.

Второй вариант не подразумевает переключение цикла обратно. Фаза переключается только вперёд, до завершения проекта («Being Completed» и «Completed»). Для нового проекта внедрения или основного релиза (major release) создаётся новый проект и единый план задач, а для разработок в рамках сопровождения используется тот же проект, но с несколькими планами задач.

Предположения и предпосылки

Рассматриваемые выше варианты применимы для проектов внедрения SAP, в которых настроена функциональность ChaRM в Solution Manager, которая используется для всех переносов и релизов в стандартном параллельном (dual-track) ландшафте.

Другие предположения:

• Читатель знаком с концепцией основных и второстепенных релизов (major vs minor) в стандартном параллельном (dual-track) ландшафте с ретрофитом
• В организации используется календарь выпуска релизов (будь то в Solution Manager или без него), и в течение года на регулярной основе (раз в неделю, раз в две недели, раз в месяц) выходит несколько второстепенных релизов (в рамках сопровождения) и два-три основных релиза

Ландшафт

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

Рис. 1. Параллельный ландшафт с ретрофитом

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

После выполнения ретрофита в целевой системе (DEV2 на рис. 1) проводится дополнительное модульное тестирование. Регрессионное тестирование обычно проводится в среде контроля качества (QA) в рамках нормального процесса тестирования. Синхронизированные изменения, импортированные в рамках процесса ретрофита, также включаются в объём регрессионного тестирования, выполняемого в QA2 на рис. 1.

Функциональность ChaRM

Релизы выпускаются в рамках проекта в системе Solution Manager, для которого активировано управление запросами на изменение (ChaRM). При этом управляемые системы должны быть подключены и объединены в логический компонент, присвоенный проекту. Логический компонент содержит системы, необходимые для обеспечения изменения для продуктивной системы (PROD). Он задаёт определённые пути переноса с указанием идентификатора системы, номера манданта и назначенной роли для системы.

У каждой системы есть своя назначенная ей роль в соответствии с диаграммой ландшафта (DEV, QA, PROD). Эта конфигурация выполняется в транзакции SOLAR_PROJECT_ADMIN (рис. 2).

Рис. 2. Проект в SOLAR_PROJECT_ADMIN с логическими компонентами

Проекты в Solution Manager могут быть нескольких видов, в зависимости от стандартных активностей, которые могут вестись в системах. Виды проектов следующие:

• проект внедрения;
• шаблонный проект;
• проект оптимизации;
• проект снижения технических рисков;
• проект апгрейда;
• проект сопровождения.

Рассмотрение различий этих видов не входит в цели данной статьи. Все они поддерживают управление изменениями (при условии активированного ChaRM), и описанная здесь концепция применима к ним всем.

Когда в проекте Solution Manager активируется ChaRM, формируются две особые транзакции: план задач проекта и цикл проекта. В транзакции SOLAR_PROJECT_ADMIN их можно увидеть на вкладке управления изменениями («Change Management») (рис. 3).

Рис. 3. Активация ChaRM и формирование плана задач проекта (Task) и цикла проекта (Cycle)