DevContentOps

Эта статья подробно описывает процессы DevContentOps для платформы DC CMS. Они разработаны таким образом, чтобы обеспечить эффективное взаимодействие между разработчиками программного обеспечения, авторами контента и системными администраторами в рамках одного проекта.

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

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

Системные администраторы и специалисты по DevOps занимаются перемещением кода и распространении контента из окружения разработки в production-окружение. Благодаря такому подходу обеспечивается плавный и непрерывный процесс разработки, обновления и delivery контента.

Общая информация 

Этот раздел знакомит с основными концепциями и предоставляет обзор процессов DevContentOps, которым следует придерживаться. Система авторинга контента DC CMS, CMS Studio, построена на встроенном репозитории контента на основе Git. Эта конфигурация способствует реализации процессов DevContentOps, что при правильном применении приводит к значительному повышению производительности.

Продвижение кода (Code Forward)

Разработчики обычно работают над кодом на своих локальных рабочих станциях, тестируя его там перед тем, как отправить в окружение разработки для совместной работы с другими разработчиками. После того, как код считается готовым для дальнейшего тестирования, он отправляется в окружение QA, где проходит тщательное тестирование QA-специалистами.

После валидации в окружении QA код продвигается к production-окружению. В зависимости от политик разработки проекта, код может пройти через несколько окружений, таких как нагрузочное тестирование, промежуточное окружение и/или UAT тестирование, прежде чем достичь production-окружение.

Возврат контента

Разработчикам часто полезно использовать актуальный prouction-контент в своем окружении разработки, чтобы обеспечить тестирование кода в реалистичном контексте. Когда это разрешено, перенос контента из production-окружения в нижестоящие окружения помогает избежать проблем, возникающих из-за различий между production-контентом и контентом, созданным разработчиками.

Напротив, перемещение контента из нижестоящих окружений в высшие нежелательно. Контент находится в собственности авторов контента, которые работают почти исключительно в production-окружении. Поэтому поток контента из нижестоящих окружений в высшие должен быть предотвращен.

Движение кода и контента

Код и контент проходят через четыре окружения. Код перемещается с рабочей станции разработчика через окружение разработки (Dev), QA и, наконец, в производственное окружение (Production). И наоборот, контент перемещается из Production обратно в QA, Dev и, в конечном итоге, на рабочую станцию разработчика.

Внедрение процессов

Процесс переноса кода

Для небольших установок или несложной разработки функционала обновления кода могут проводиться непосредственно в production-окружении. Это включает в себя редактирование кода в CMS Studio, проверку изменений с использованием In-Context Preview в CMS Studio, тестирование в staging-окружении и, в конечном итоге, публикацию в production-окружение.

Для более сложных функций ниже приведено руководство, описывающее процесс управления кодом в трех окружениях, а также в локальном временном окружении, используемой разработчиком, работающим над функционалом.

Окружения

Под окружением понимается развертывание DC CMS, обслуживающее идентичные проекты, но используемое разными пользователями. Типичные окружения включают:

1. Local: Персональный компьютер разработчика.
2. Dev: Общий для всех разработчиков.
3. QA: Тестирование качества.
4. Prod: Production/live-окружение.

Как правило, код перемещается последовательно от окружения 1 к 4. В следующих разделах мы опишем процесс ветвления, который поддерживает это последовательное продвижение и также позволяет переносить контент обратно из окружения 4 в 1.

Репозитории

Есть две основные стратегии управления проектным репозиторием Git в разных окружениях:

1. Использование единственного репозитория с несколькими ветками:

• Этот метод прост и в большинстве случаев эффективен.
• Он предполагает поддержку одного центрального репозитория Git, в котором различные окружения(например, dev, QA, production) представлены отдельными ветками.
• Этот подход упрощает управление, так как весь код и конфигурации хранятся в одном репозитории.

2. Использование отдельного репозитория для каждого окружения:

• Этот подход более сложен, но может быть выгодным в определенных ситуациях.
• Он включает создание отдельного репозитория Git для каждого окружения.
• Этот метод может быть предпочтителен, если между окружениями существуют значительные различия, особенно по размеру или содержанию репозитория.
• Например, если QA-окружение содержит большой объем тестовых данных, что значительно увеличивает размер репозитория, их разделение в отдельный репозиторий может быть выгодным.
• Такое разделение помогает избежать хранения больших, специфических для окружения данных вместе с production-кодом, даже если они разделены на ветки в одном репозитории.

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

При использовании подхода с единым репозиторием ветви будут выглядеть следующим образом:

Учитывая перечисленные выше окружения, для подхода, основанного на использовании одного вышестоящего репозитория для каждого окружения, мы выделяем следующие вышестоящие репозитории:

Как видите, ветви поддерживают согласованность по сравнению с методом использования единственного основного репозитория.

Репозитории настроены как "вилки" (forks) друг друга. Процесс создания этих "вилок" может отличаться в зависимости от вашего внешнего Git-сервиса. Нет необходимости в том, чтобы ветви studio-* в одном репозитории отражали те же самые ветви в другом.

Этапы процесса переноса кода

1. Разработчик делает "вилку" (fork) dev-ветки из репозитория Dev для создания ветки dev-a-fork. Это действие выполняется только один раз.

2. Разработчик переносит эту ветку на свою рабочую станцию

3. Если для функционала требуется работа в CMS Studio, разработчик создает orphan-проект в CMS Studio. Этот проект основан либо на studio-dev, либо на dev-a-fork ветви:

• Если выбран dev-a-fork, тогда разработчик получит самый свежий контент из production-окружения.
• Если выбран studio-dev, разработчик получит последнюю версию контента из dev-окружения
• Выбор между этими ветками зависит от конкретных требований разрабатываемого функционала.

4. Затем разработчик создает новую ветку в своем локальном репозитории и называет ее feature-x.

5. С использованием своего интегрированного окружения разработки (IDE), разработчик работает над реализацией функционала.

6. По мере необходимости разработчик передает патчи из локального репозитория CMS Studio в ветку feature-x.

7. После завершения реализации функционала разработчик отправляет изменения в свою ветку и инициирует запрос на вытягивание (pull request) для слияния этих изменений в ветку dev. Этот шаг требует одобрения от других членов команды.

8. Для продолжения развертывания и тестирования в dev-окружении:

• Код переходит из dev в studio-dev.
• Затем он импортируется в CMS Studio.
• Аналогичный процесс происходит с кодом, переходящим из dev в qa, а затем в production.

Правила перемещения кода между окружениями

Некоторые пути, вероятно, будут одинаковыми во всех окружениях. Другие же пути могут отличаться в зависимости от конкретного окружения.

Обычно администраторы и разработчики работают с файлами, которые остаются неизменными во всех окружениях. Пути, которые могут меняться от одного окружения к другому контролируются автором и издателем контента.

DC CMS советует придерживаться следующих рекомендаций:

Управление конфликтами при слиянии и их предотвращение

Описываемая модель обладает гибкостью, что позволяет авторам контента и разработчикам настраивать компоненты, важные для них. Следование рекомендованным практикам и соглашениям обеспечивает плавный опыт при перемещении контента и кода между различными окружениями ежедневно. Этот подход также поддерживает эффективную модель ветвления Git с минимальными конфликтами слияния.

Однако в редких случаях авторы контента или разработчики могут временно отклоняться от этих руководств, что потенциально может привести к конфликтам при возвращении к стандартным процедурам. Важно оперативно и эффективно устранять эти конфликты.

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

Локальное разрешение конфликта слияния

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

Простым решением является загрузка веток разработки и тестирования в локальный Git-репозиторий на рабочей станции разработчика. Здесь слияние может быть выполнено локально, что позволяет ручным способом разрешить конфликты с использованием предпочитаемых инструментов. После разрешения конфликтов объединённая ветка тестирования может быть отправлена обратно в центральный Git-репозиторий.

Если в вашем Git-репозитории установлены настройки защиты веток, разрешение конфликта слияния может потребовать использования специальной ветки. Тем не менее, общий процесс и результат остаются неизменными.

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

Возврат контента

Контент создаётся в prod authoring-окружении, где он затем публикуется в prod delivery-окружение. Однако контент может также перемещаться в обратном направлении, из prod-окружения в более низкие окружения, такие как QA, затем из QA в Dev, и в конечном итоге из Dev на рабочие станции разработчиков. Этот процесс возврата контента является важным аспектом DevContentOps.

Предотвращение попадания контента из более низких окружений в более высокие

Важно понимать, что контент должен двигаться вперед — от веток studio-prod к dev/qa/prod, и никогда наоборот (от studio-qa к qa или от studio-dev к dev). Это обеспечивает то, что нижние окружения случайно не включают контент, предназначенный для высших окружений, что соответствует модели "Продвижение кода (Code Forward)".

Git-контроли могут наложить правила, чтобы предотвращать запросы на объединение или слияния, которые пытаются перемещать контент назад между этими ветками. Наиболее важно применять эти проверки при слияниях в ветку dev, так как именно здесь обычно происходят непреднамеренные перемещения контента от отдельных разработчиков. В зависимости от конфигурации, могут быть случаи, когда намеренные операции "Возврат контента" требуют отмены этих защит.

Контент, который был возвращен из prod в нижние окружения, в конечном итоге будет интегрирован в окружения studio-dev и studio-qa во время последующих развертываний, либо как часть процесса "Возвращение контента", либо отложен до следующего развертывания кода.

Конфликты слияния при возврате контента

Если разработчики или QA специалисты создали элементы контента в окружениях разработки или тестирования, используя тот же путь, что и элементы контента в production-окружении, или если они непосредственно изменяли элементы контента production-окружения в окружениях, не относящихся к production, это может привести к конфликтам слияния при возврате контента при переносе контента из разработки в studio-dev или из тестирования в studio-QA.

Эти конфликты могут быть разрешены аналогично конфликтам в коде. Самым простым способом их разрешения является принятие контента либо из разработки, либо из тестирования. В альтернативном подходе репозиторий может управлять выбором версии, существующей в ветках studio-*. Важно отметить, что если конфликты разрешаются путем принятия контента из разработки или тестирования, изменения, внесенные в production, не будут отражены в окружении DC CMS.

BLOB-хранилище и возврат контента

Не вся информация находится только в репозитории Git. DC CMS также позволяет использовать BLOB-хранилище для хранения больших бинарных файлов (обычно находящихся в папке /static-assets/content, упомянутой ранее). При выполнении резервного копирования контента важно синхронизировать контент в BLOB-хранилище с высокоуровнего окружения в низкоуровневое.

Простой способ достичь этого - скопировать весь контент из production-окружения сначала в blob-хранилище staging-окружения, а затем в dev-окружение.

Если хранилищем данных является AWS S3, то используется следующая команда:

Чтобы выполнить эту операцию на компьютере разработчика, можно сделать что-то вроде этого:

Очистка хранилища (опционально)

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

Однако для проектов со значительным объемом контента периодическая очистка репозитория может быть необходима для поддержания оптимальной производительности. Факторы, такие как общий размер объектов и частота коммитов, могут значительно влиять на эффективность репозитория.

В таких случаях рекомендуется применение модели многопоточного (multi-upstream) репозитория, описанной выше. Техники настройки репозитория Git могут быть реализованы по мере необходимости, чтобы обеспечить плавную работу каждого окружения. В определенных сценариях, особенно в dev-окружении, начать заново может оказаться наиболее эффективной стратегией. Учитывая, что репозиторий Dev происходит от QA, сброс как Dev репозитория, так и dev-окружения может выровнять их производительные характеристики с QA. Разработчики затем должны будут воссоздать свои "вилки" (forks)  и локальные настройки, чтобы сохранить согласованность с историей Git.

Этот подход также может быть применен QA-окружению, что, возможно, потребует сброса downstream в Dev и среди отдельных разработчиков для поддержания целостности истории Git.

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

Создание dev-окружения

DevContentOps модель DC CMS предлагает структурированный подход к настройке всех окружений экосистемы CMS, от production до dev. Надежное и последовательно воспроизводимое окружение критически важно, особенно для продвинутой разработки. Описанные методы позволяют разработчикам быстро воссоздавать свои окружения всего за несколько минут по мере необходимости. Эта возможность значительно выделяется на фоне длительного процесса настройки, часто требуемого корпоративными платформами, зависящими от баз данных, что отличает DC CMS в этом отношении.

Работа с DevOps

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

Инновационная структура репозитория на основе Git в DC CMS обеспечивает гладкость операций продвижения кода и возврата контента. Кроме того, поддержка DevContentOps в DC CMS позволяет разработчикам использовать предпочитаемые инструменты и платформы. Эта встроенная интеграция гармонично соответствует их установленным процессам и лучшим практикам.

Связанные статьи

Документация для разработчиков