Я хотел бы познакомить вас с нашей концепцией Continuous Delivery (далее CD) применительно к основной CMS, на которой развивается наша компания — Sitecore. Наша концепция компакт-дисков основана на трех столпах:
- Система контроля версий — Git (в принципе, ее можно применять и к другим, но Git наиболее удобен за счет того, что ветки в нем очень простые, быстрые и дешевые)
- CI-сервер – TeamCity
- Код, который собственно осуществляет всю доставку, установку и обработку (скрипты и дополнительные исполняемые файлы)
ГИТ
Выбор этой системы контроля версий обусловлен нашей концепцией CD, в которой у нас есть три основные ветки в каждом репозитории: dev, Acceptance и Master. В соответствии с названиями каждая ветка отражает состояние кода на одном из трёх серверов:- Dev = QA, внутренний сервер, доступен только в нашей сети.
Здесь проводится основное тестирование.
- Acceptance = сервер приема, доступный как из нашей сети, так и для клиентов, но недоступный другим пользователям Интернета.
- Мастер = производственный сервер, доступный каждому.
Если были обнаружены какие-то ошибки, исправьте их в ветке, объедините и повторите тестирование.
После того, как тестировщик считает задачу выполненной, происходит слияние в приемке, сдаче и задача передается тестировщикам и заказчику на проверку.
Если обнаружены какие-либо проблемы, описанный выше процесс повторяется еще раз.
Если задача, по мнению заказчика, выполнена, возникает ветка, в которой разработка была выполнена в мастере и сдана в производство.
Таким образом, Git является очень важной частью нашего процесса разработки и доставки благодаря своим простым и быстрым веткам и простоте управления.
TeamCity и процесс доставки с задействованными скриптами/приложениями
Легко настраивается, бесплатен для небольших проектов (не более 20 конфигураций сборки), прекрасно понимает большинство распространённых систем контроля версий (включая наш любимый Git), имеет встроенные раннеры для MSBuild, nANT, Visual Studio, а также предоставляет доступ к его restAPI для получения данных и управления конфигами.На мой взгляд, это один из самых удобных серверов сборки в своем классе (как и другие продукты JetBrains).
Также одной очень удобной особенностью TeamCity является возможность настройки параметров на уровне проекта или на уровне сборки непосредственно через веб-интерфейс.
Возможна настройка параметров на уровне сервера, а также доступ к системным параметрам хоста (например, PATH).
Типичная сборка проекта, обеспечивающая автоматическую доставку и проверку работоспособности веб-приложения после доставки (страница сайта возвращает код 200), состоит из следующих аспектов конфигурации: Общие настройки : по результатам каждой сборки собираем артефакты - архив с веб-приложением, архив с пакетами (Sitecore использует созданные и заархивированные xml-файлы для доставки между средами особым способом, который мы называем пакетами) и архив с SQL-скрипты, если решение использует дополнительные базы данных.
А также автоинкрементный счетчик сборки, который используется во встроенном в TeamCity AssemblyInfo патчере, увеличивающем версию сборки.
Настройки системы контроля версий : TeamCity невероятно прост и удобен в настройке.
Единственный интересный момент здесь — это возможность ставить теги по результатам сборки, что теоретически позволяет вернуться именно к тому коду, в котором была/появилась какая-либо проблема.
Здесь по возможности используется инкрементная проверка, чтобы ускорить сборку и снизить трафик.
Собственно, сама сборка :
- Сборка и публикация решены с помощью Visual Studio (на сервере должна быть установлена VS необходимой версии).
Указываем путь к sln файлу, а в переменной указываем какую конфигурацию сборки вызывать для этого sln файла (каждый проект имеет несколько конфигураций сборки для каждого задействованного окружения).
Публикация выполняется в локальную папку на сервере, так как организовать доставку напрямую на нужный сервер с помощью MS Publish Tool не удалось.
Первая и последняя проблема, с которой я столкнулся, заключалась в том, что мы находимся в разных областях.
При возникновении ошибки MSBuild сборка останавливается и информационное сообщение отправляется следующим лицам: людям, чьи коммиты участвовали в сборке, инженеру сборки и тестировщикам.
- Подготовка опубликованных файлов и целевого приложения к установке пакетов (скрипт).
В связи с тем, что Sitecore по умолчанию запрещает создание узлов в базе данных, содержащих специальные языковые символы и зарезервированные символы, а при разработке иногда без них невозможно обойтись - на этом этапе целевому приложению доставляется специальный патч конфигурации, что позволяет использовать эти символы.
На том же этапе, после доставки исправления конфигурации, вызывающего перезапуск приложения, wget используется для получения главной страницы сайта.
Это гарантирует, что приложение запущено и готово к следующему шагу.
- Доставка узлов в базы данных Sitecore. В веб-приложении разворачивается сервис WCF, который принимает пакеты и устанавливает их (напомню, что sitecore использует для доставки между средами особым образом созданные и заархивированные xml-файлы, которые мы называем пакетами), что позволяет автоматизировать Данная процедура выглядит следующим образом: в ходе разработки разработчик добавляет пакеты, необходимые для доставки целевому приложению, в специально отведенную папку, которая также хранится в системе контроля версий.
TeamCity самостоятельно собирает данные об изменениях, внесенных в эту сборку, и предоставляет к ним доступ через restAPI. Приложение, отвечающее за доставку, считывает xml из restAPI, выбирает пакеты, участвующие в сборке, и передает их службе WCF, после чего служба WCF их устанавливает. Все необходимые данные для приложения-сборщика передаются через параметры, которые настраиваются на уровне проекта, поскольку они одинаковы для всего репозитория.
К сожалению, есть одна проблема, связанная со службой WCF и настройками целевого приложения: если размер пакета слишком велик или его установка занимает более 20 минут, служба разрывает соединение.
При возникновении ошибки сервис возвращает ошибку, сборка останавливается, уведомления отправляются тем же людям, что и на первом шаге.
Служба WCF будет вызываться только в том случае, если есть что-то для доставки в Sitecore, что также помогает ускорить сборку.
- Публикация узлов в базе данных контента.
В связи с тем, что Sitecore работает с двумя базами данных (главной — в которой создается контент и веб — из которой контент доставляется конечному пользователю), было создано еще одно приложение для выполнения встроенного в Sitecore процесса передачи данных из мастер веб-базы данных, которая называется Pablish. Это приложение работает по тому же принципу, что и приложение из шага 3. Разработчик коммитит файл, в котором построчно описаны узлы, которые необходимо опубликовать, приложение получает эти файлы через restAPI (файлы выбираются из коммита из конкретная папка в репозитории, ограничение состоит в том, что файлы должны иметь определенное расширение), считывает содержимое файлов и передает его в службу WCF, которая, в свою очередь, публикует узлы с их дочерними элементами.
В отличие от предыдущего шага, если на этом этапе возникает ошибка, сборка не останавливается.
Служба WCF будет вызываться только в том случае, если в Sitecore есть что опубликовать, что также помогает ускорить процесс.
- Подготовка кода и доставка на целевой сервер.
На этом этапе обычный cmd-скрипт упаковывает опубликованное решение и через SSH-туннель доставляет полученный архив на целевой сервер во временный каталог, распаковывая архив там.
Затем App_Offline.htm помещается в папку веб-приложения, что останавливает веб-приложение и позволяет пользователям получать уведомления о том, что приложение в настоящее время обновляется.
- Обновление сторонних баз данных (Необязательный шаг).
Если приложение использует не только стандартные базы данных Sitecore, но и дополнительные, на этом этапе эти базы обновляются с помощью скриптов, сохраненных в управлении ресурсами в специальной папке, аналогично файлам из шагов 3 и 4. На этом этапе выберите нужные скрипт и его применение осуществляется с использованием специального формата имени файла (версия.
имя).
Если версия файла выше версии базы данных (хранится в поле Расширенные свойства), база данных обновляется скриптом из файла.
Вскоре файлы для обновления базы будут получаться приложением-сборщиком, аналогично шагам 3 и 4. Также в скором времени планируется переключить этот шаг с выполнения на хосте сервера сборки на выполнение на сервисе WCF (однако в ближайшее время в этом случае вам придется отказаться от App_Oflline.htm), что должно повысить безопасность.
- Доставка кода в приложение.
Скрипт очищает папку с конфигами и бинарниками в приложении, затем из распакованной на шаге 5 папки доставляет код и сопутствующие файлы в папку веб-приложения.
Последний шаг сценария удаляет App_offline.htm.
- С помощью wget мы получаем страницу (обычно главную) сайта, чтобы убедиться в работоспособности приложения (код 200).
Если код отличается от 200, сборка считается неудачной.
Плюсы/минусы/нереализованные преимущества этого подхода
Плюсов, собственно говоря, масса, но главное, что хотелось бы выделить, это то, что мы устранили из процесса доставки человека, с его свойственной забывчивостью и просто ленью.Также за счет автоматизации значительно ускорилась доставка.
Конечно, у истоков все же стоит человек (разработчик).
Если он что-то не коммитит, то это не будет доставлено, если он неправильно коммитит, то оно будет доставлено неправильно.
Но такие чисто человеческие ошибки, как правило, выявляются при внутреннем тестировании.
Однако есть и масса недостатков, а также нереализованных вкусностей.
Я хотел бы выделить несколько:
- Интернет должен быть подключен постоянно во время сборки.
Если возникнут проблемы с подключением к Интернету, сборка завершится неудачей.
На шагах до пяти это не будет проблемой.
Однако если на 5-м шаге отвалится Интернет, приложение останется незапущенным и его можно будет починить только вручную.
- Я не вижу возможности реализовать автоматический откат к предыдущей версии в случае сбоя сборки на шагах выше второй: резервное копирование базы данных делается автоматически, но ее восстановление - довольно долгий процесс, а версионирование всех баз данных sitecore без сторонних (и довольно дорогих приложений) невозможно.
Так же, как и с базой данных, я пока не представляю возможности автоматического отката кода.
- 100% критерия того, что доставка прошла успешно, не существует: бывают ситуации, когда страница проверки возвращает код 200, а другие могут завершиться с ошибками.
- Доставка через SSH очень хороша с точки зрения стабильности и скорости, но, в отличие от MS Publish Tool, она оставляет в целевом веб-приложении файлы, исключенные из решения.
Не то, чтобы это была серьезная проблема, но это просто некрасиво.
NET #C++
-
Ноутбук Acer Trave-As5740G-372G32Mn
19 Oct, 24 -
Vogue Как Системный Монитор
19 Oct, 24 -
Linux С Материальным Дизайном
19 Oct, 24 -
Госдума Одобрила Закон Об Информации
19 Oct, 24
