Описание компонента Deployment (сборка и публикация пакетов обновления, мониторинг)
Компонент Deployment разработан с целью упростить публикацию Ваших проектов, процесс мониторинга исходного кода и баз данных на production-серверах, а также сборку пакетов обновления.
Одна из возможных схем использования
Шаг 1 – Вы загружаете платформу на локальную машину разработчика, устанавливаете проект, заводите (по желанию) репозиторий в Вашей системе контроля версий исходного кода (это может быть как SVN, GIt, Mercurial и др.), коммитите в него файлы. Начинаете разработку своего продукта в команде или самостоятельно.
Шаг 2 – Первая публикация проекта - простое копирование кода и базы данных проекта на production-сервер. После того как система успешно скопирована в панели администратора (на production) активируете API (просто публикуете страницу API), заводите ключ API в разделе API Keys.
Шаг 3 – теперь на локальной машине разработчика Вы можете подключиться к API production-системы, для этого необходимо завести учетную запись сервера. Заходим в раздел Deploy, добавляем сервер и вводим запрашиваемые данные. По умолчанию url к API-контроллеру production-системы будет yoursite.com/api.
Вот и все, теперь можно отслеживать состояние исходного кода на возможные изменения со стороны, при необходимости собирать пакеты обновления для конкретного production-сервера, проверять состояние базы данных production. Нет никакой необходимости настраивать клиент svn на production-системе, обновление будет происходить исключительно по Вашей команде, обновляться будут только те файлы, которые Вы посчитаете нужным обновить (никакой головной боли с экспортом из системы контроля версий).
Как это работает
Модуль Deploy формирует фоновое задание, которое отправляет запрос карты файловой системы к выбранному серверу. Сервер, получив запрос, пробегает файловую систему проекта, составляя ее карту из списка существующих файлов и их контрольных сумм. Сформированная карта отправляется запрашивающему клиенту.
Локальная система, получив карту удаленного сервера, может ее сопоставить с картой своей файловой системы как эталонной. В интерфейс выводятся все различия карт, для удобства они выводятся в двух панелях: в первой те файлы, которые необходимо обновить, во второй – которые, возможно, стоит удалить.
После того как прошло сопоставление разработчик может выбрать файлы для текущего обновления, проставив галочки и нажав кнопку create package, собрать zip-архив файлов для обновления, далее остается загрузить файлы на сервер. Архив формируется с сохранением файловой структуры проекта, так что файлы обновляются путем простой замены на новые.
Описание интерфейса
Список production-серверов (панель 1):
После добавления сервера, будет доступна панель синхронизации (панель 2).
Окно добавления нового production-сервера:
Поля Server ID и Server name используются для идентификации сервера в проекте, вводите удобные для Вас идентификаторы.
Поле Server API url – адрес API-контроллера production-системы, по умолчанию он выглядит так: http://yoursite.com/api/
Поле Server API Key – ключ доступа к серверу. Ключи заводятся на сервере, который предоставляет API доступ в разделе API Keys.
Прежде чем приступить к синхронизации необходимо обновить эталонный слепок файловой системы (кнопка 4). В панели 2 есть кнопка запроса информации с удаленного сервера, при нажатии на нее будет запущено фоновое задание, которое запросит у удаленного сервера слепок файловой системы или статистику базы данных (в зависимости от открытой вкладки).
После выполнения фоновой задачи в Server panel на вкладке Files будут доступны два дерева со списками файлов. Новые или измененные файлы локального сервера стоит отправить на production, а файлы production-сервера, которые не нашли сопоставления на локальной машине, скорее всего нужно удалить.
Кнопка Create package создает фоновую задачу сборки архива обновления, после завершения задачи на локальной машине в папке deploy, находящейся выше на уровень от docment root, появится архив с файлами, который можно загрузить на удаленный сервер и провести обновление системы. На данном этапе шаг отправки архива на удаленную систему подразумевает ручной upload, позже будет реализована автоматизация этого процесса. Кроме файлов для обновления в архиве будет находиться текстовый документ с именами файлов, которые необходимо удалить.
Вкладка Database на данный момент только отображает информацию о состоянии ORM удаленного сервера, позже планируется расширение возможностей:
Публикация
Приступая к публикации, убедитесь, что все code packages актуальны, при необходимости пересоберите их (интерфейс Code Compiler).
Пример организации инфраструктуры проекта
Пример организации инфраструктуры проекта:
- создание локального проекта, разработка продукта;
- публикация проекта на production-сервер;
- начало командной разработки, подключение SVN;
- расширение проекта / публикация приложения на второй production-сервер;
- увеличение производительности приложения на втором сервере, введение дополнительного веб-сервера, разделение кэша на системный (общий для всех серверов) и кэш данных (отдельный для каждого сервера), кластеризация MySQL.
