Студия/Развертывание проектов

From SunFlurry wiki
Jump to: navigation, search

Для передачи обновлений файлов и конфигурации проекта на рабочие сервера, система использует особый способ соединения -- развертывание обновлений на удаленных серверах. Соединения происходит по протоколы TCP/IP, на удаленном сервере должен быть выделенный IP-адрес и открытый порт обновления. Удаленный сервер также может находиться в локальной сети или на локальной машине разработчика, так как часто разработчик устанавливает на своей машине локальный сервер базы данных, чтобы иметь возможность проверять изменения, сделанные в конфигурации проекта.

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

После принятия изменений, диалог развертывания закрывается и выбранные изменения загружаются на удаленный сервер, после чего, если изменения связаны с перезапуском серверной программы (обновления бинарных файлов сервера, изменения в метаданных проекта), сервер будет остановлен (при этом, все текущие пользователи потеряют связь), будут приняты изменения, после чего сервер будет запущен снова; если же изменения не подразумевают перезапуска, они будут приняты сразу же, без необходимости выхода работающих пользователей из системы. После принятия изменений, в общем диалоге со списком сервером будет доступен лог обновления сервера и конечный результат обновления -- успех или неудача.

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

Редактор серверов развертывания проекта

Чтобы задать и изменять свойства серверов, для которых будет производиться обновление файлов проекта, существует редактор серверов развертывания проекта, который доступен в Студии в главном меню (Проект - Серверы развертывания проекта...). На рис. 1 представлен общий вид редактора с открытой записью сервера. Общий диалог редактора позволяет добавлять удалять или редактировать серверы. Диалог редактора одного сервера содержит следующие свойства:

  • Наименование -- идентифицирует сервер в таблице диалога редактора и диалога развертывания.
  • Адреса -- IP адреса или DNS имена сервера для соединения. Для данный момент доступны в формате IPv4 (IPv6 планируется). Адреса задаются через запятые, номер порта можно не указывать, в этом случае, будет использован порт по умолчанию (13251). Если задано более адреса, второй (и последующие) адрес будет использован, если соединение с первым (или предыдущим) адресом невозможно установить, таким образом увеличивается надежность соединения, если сервер доступен по нескольким локальным или адресам Интернета.
  • Пароль -- задает пароль для TCP соединения с сервером (это не пароль на вход в систему пользователя). Пароль задается в свойствах инициализации сервера (см. Установки сервера).
  • Сервер является репозиторием исходных текстов -- особый режим сервера (на данный момент не используется), позволяет передавать только исходные тексты (не из папки скомпилированных текстов), при этом, в момент передачи, возможен просмотр и принятие отдельных изменений в файлах сервера или изменение локальных файлов на основе файлов сервера.
  • Развертывать обновление на данном сервере после любой компиляции -- режим позволяет автоматически открывать диалог развертывания и безусловно принимать все изменения для данном сервера после любой успешной компиляции. Безусловно будут приняты даже изменения, которые требуют перезагрузки сервера, поэтому, такой режим нельзя использовать для рабочих серверов. Однако, для локального сервера разработчика, который используется для тестирования изменений, до обновления рабочих серверов, такой режим очень удобен.

Развертывание проекта на удаленных серверах

После того, как произошла успешная компиляция проекта и изменения необходимо перенести на удаленные рабочие сервера, разработчик вызывает диалог развертывания проекта, доступный в Студии в главном меню (Развертывание - Развернуть проект...). В диалоге будут показаны все серверы, заданные ранее в редакторе серверов развертывания проекта. Разработчику необходимо поставить флажки рядом с теми серверами, на которых необходимо загрузить обновление (либо воспользоваться кнопкой "Выделить" для установки всех флажков), после чего нажать на кнопку "Выполнить", которая инициирует процедуру обновления. Студия создаст нужное количество потоков, каждый из которых будет соединяться со своим сервером. На рис. 2 показан общий вид диалога а в процессе развертывания обновления. Процедура обновления сервера проходит примерно по следующему алгоритму:

  • Студия соединяется с удаленным сервером и проходит на нем авторизацию. Если соединиться невозможно, либо пароль соединения неверен, в столбце "прогресс / сообщения сервера" будет показан текст ошибки.
  • Студия получает от удаленного сервера пакет с внутренними данными по состоянию сервера и сверяет это состояние с текущими данными в папке компилированных текстов проекта, в процессе сверки определяется, требуется ли осуществлять обновления на данном сервере или нет.
  • Если на удаленным сервере найдены устаревшие файлы или свойства метаданных проекта, обновление приостанавливается и ожидает действий разработчика. При этом в столбце "прогресс / сообщения сервера" будет показан текст приглашения "Кликните для работы с диалогом обновления!". При клике мышью по этому приглашению, открывается диалог "деталей и свойств обновления" текущего сервера.
    • Процесс обновления, находящийся в ожидании действия разработчика, можно остановить, выделив соответствующий сервер и нажав на кнопку "Остановить" (рис. 2), которая становится доступна для серверов, для которых происходит обновление.
  • Измененные файлы делятся на несколько типов и располагаются на разных закладках диалога. Кроме того, в диалоге присутствуют дополнительные закладки для работы с пользователями, работающими с сервером в данное время. Некоторые закладки могут отсутствовать, если они не содержат никаких изменений. Разные типы закладок диалога показаны на рис 3, 4, 5, 6 и 7. Ниже дается описание доступных закладок.
    • Файловая структура -- закладка показывает изменения в файлах проекта в виде дерева. Разработчик может выбрать, какие обновленные файлы переносить на удаленный сервер с помощью флажков, расположенных только рядом с измененными элементами дерева. См. рис. 3. для примера работы с диалогом.
    • Изменения в метаданных -- закладка содержит все изменения в метаданных проекта. Изменения выполнены в виде дерева, повторяющем по структуре дерево редактора конфигурации проекта, однако, ветки, не содержащие изменений, выведены не будут. Изменения также содержит флажки, позволяющие не передавать их на удаленный сервер. Некоторые изменения на этой закладке могут быть связаны с изменения на закладке с файлами (к примеру. если добавляется новый справочник, его папка будет также присутствовать, как новая в файловом обновлении структуры), поэтому, при снятии галки в этом диалоге, подобная галка в диалоге файловой структуры также может быть снята. Разные изменения отмечены разными цветами -- синий цвет означает измененный объект, зеленый -- добавленный объект, красный -- удаленный объект. При выделении изменения на уровне объекта, строчной части или реквизита становится доступной кнопка "Подробности", позволяющая показать подробности изменений в объекте, строчной части или реквизите. Рис 4 и 5. показывают простой пример диалога изменений метаданных при изменении типа данных реквизита строчной части.
      • Рис. 4. Закладка изменения метаданных показывает измененный реквизит в структуре справочника
      • Рис. 5. Подробности изменений для реквизита, его тип изменился с неограниченной строки на строку с длинной 100 символов
      • Обновление метаданных (а также исполняемых файлов сервера, см. ниже) связано с перезагрузкой серверной программы (но не самой машины). Сообщение о предстоящей перезагрузке показано крупным красным шрифтом на нижней панели диалога, для того, чтобы разработчик не смог пропустить его. Перезагрузка будет выполнена автоматически, после перезагрузки сервер сам перейдет в рабочее состояние и передаст информацию по обновлению в виде лога обновления (см. ниже). Однако, при перезагрузке сервера соединения текущих пользователей с сервером будут утеряны и изменения в данных, которые не были сохранены, также будут утеряны, поэтому, если на сервере в данный момент работает по крайней мере одни пользователь, Студия выдаст предупреждение, прежде чем осуществлять перезагрузку. Администратору рекомендуется использовать закладку "Текущие сеансы" для того, чтобы сообщить пользователям о необходимости сохранить данные и выйти из системы. На период ожидания выхода пользователей, новые пользователи не смогут зарегистрироваться в на сервере.
    • Исполняемые файлы -- закладка показывает изменения в исполняемых файлах клиентов или сервера в виде дерева. Разработчик может выбрать, какие обновленные файлы переносить на удаленный сервер с помощью флажков, расположенных только рядом с измененными элементами дерева. См. рис. 6. для примера работы с диалогом. В данную закладку включены следующие измененные файлы:
      • Файлы из папки обновлений визуального клиента. Эти обновления будут переданы на локальные компьютеры пользователей в момент, когда они попытаются зарегистрироваться на сервере. Обновления такого рода не вызывают перезагрузку сервера.
      • Файлы из папки обновлений консольного клиента. Эти обновления будут переданы на локальные компьютеры консольных клиентов в момент, когда клиент попытается зарегистрироваться на сервере. Обновления такого рода не вызывают перезагрузку сервера.
      • Файлы из папки обновлений файлов сервера. Эти обновления будут заменят оригинальные файлы в каталоге сервера, которые могут быть как обновлениями исполняемого файла сервера, его библиотек, так и обновления сопутствующих файлов. Обновления такого рода всегда вызывают перезагрузку сервера.
      • Текущие сеансы и Сообщения пользователей -- закладка "текущие сеансы " показывает список всех пользователей, работающих с сервером в данный момент. Разработчик может отослать сообщение одному или нескольким пользователям, при ответах пользователей, их сообщения помещаются на закладку "сообщения пользователей". Кроме того, у разработчика есть возможность завершить сеанс пользователя (иногда это необходимо, если пользователь не находится за компьютером). Кнопка "запрет входа" включает режим, когда новые пользователи не могут зарегистрироваться на сервере. При выходе или регистрации новых пользователей список обновляется автоматически, период обновления -- несколько секунд. Обновление также можно форсировать с помощью клавиши F5. См. рис. 7. для примера работы с диалогом.
    • После принятия обновления, новые файлы загружаются на сервере (в столбце "Прогресс / сообщения сервера" будет показан прогресс загрузки файлов). По окончании загрузки, в зависимости от сложности обновления, сервер либо заменяет старые файлы новыми, либо завершает работу и внешняя программа для обновления (обычно SFCDepl.exe) заменяет файлы сервера и запускает его снова. При успешном обновлении будет показано сообщение "Обновление завершено успешно!", если же обновление изменяло метаданные проекта, клик по сообщению, выведет на экран диалог логов обновления (см. рис. 8), в котором будет подробно описаны действия, произведенные с базой данных при обновлении.

    Заметки по передаче изменения метаданных проекта на удаленный сервер

    При изменениях метаданных проекта кроме добавления или удаления объектов или реквизитов объектов, иногда необходимо изменить тип метаданных реквизита. В этом случае, сервер попытается привести в соответствие существующие в данные момент данные к новому типу. Иногда это происходит без изменения самих данных, однако, иногда данные могут измениться, либо вообще быть утеряны. Ниже дается примерная картина того, какие изменения может пытаться осуществить сервер при изменении типов:

    • При преобразовании между типами "дата и время" и "число", любой тип и "объект базы данных" старые данные преобразуемого реквизита будут утеряны.
    • При преобразовании из чисел в числа другой длины или точности, строк одной длины в строки другой длины либо строк в числа, сервер будет пытаться максимально близко сохранить предыдущие значения, пока это возможно. При переполнении, к примеру, могут быть записаны максимально возможные числа в новом типе данных.
    • При преобразовании чисел или дат в строки, будет произведено превращение текущих данных в строки и использование их для заполнения новых данных, если данные не вмещаются в строку результат, они будут усечены.
    • При преобразовании строки в дату, строка должна быть в следующем формате DD.MM.YYYY HH:NN:SS, строки с другими форматами будут преобразованы в пустые даты.
    • Особый смысл приобретает преобразование типов данных реквизитов, являющихся нумераторами. Для текстовых нумераторов, сервер будет пытаться сохранить их префиксы или добавить или удалить некоторое число нулей из середины номера, если это возможно. После преобразования в базе данных может случиться ситуация, когда два реквизита имеют одинаковый номер внутри одной структуры подчинения (к примеру, при уменьшении размера номера), т.е. ситуация нарушения уникальности номера. Такие ситуации, разработчик должен исправлять после обновления, к примеру, с помощью исполнения прямого кода в клиенте.
    • Преобразования из обычного реквизита в периодический помещают текущее значение реквизита в таблицу периодических реквизитов на дату 01.01.1900 (пустая дата).
    • Преобразования из периодического реквизита в обычный используют значение реквизита таблицы периодических реквизитов на текущую дату как новое значение реквизита.
    • Преобразования из периодического реквизита в периодический реквизит с другим периодом, будет пытаться корректно сохранить всю таблицу периодичности и устранить дублирующиеся значения, если они возникают.

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

    Заметки по возможным ошибкам обновления и методам их устранения

    Иногда обновление файлов не может быть выполнено по разным внешним причинам: база данных занята, так как в ней зарегистрирована внешняя программа-клиент, поэтому система не может получить эксклюзивный доступ к ней (он необходим при изменении структуры данных), приложение, обновляющее серверные бинарные файлы не смогло за нужный период остановить сервер, произошла системная ошибка при копировании и пр. Такие внешние ошибки останавливают обновление, и сервер при запуске будет находиться в нерабочем режиме, ожидая действий администратора, который получит сообщение о такой ситуации в логе обновления Студии. В логах сервера может присутствовать запись, типа FATAL: Update folder contains some updates besides DBMETA/LEV1/LEV4 updates! или подобная. Чтобы восстановить работоспособность сервера в этом случае, необходимо остановить его работу, очистить содержимое папки UpdateQueue, находящейся в корне папки с данными проекта, запустить сервер снова, и выполнить обновление еще раз из Студии. Такая ошибка может появиться только при обновлениях, связанных с остановкой сервера (обновлениях структуры данных или бинарных обновлениях файлов сервера), обновления форм или модулей не требуют перезапуска сервера, поэтому, происходят более стабильно.