Ведение истории в системе управления версиями

Разработка проекта ведется с использованием распределенной системы управления версиями Git и системы непрерывной интеграции Jenkins.

Для соблюдения версионности сборки, устанавливаемой на стороне заказчика в структуре веток проекта добавляются:

• узел installations, в котором будут храниться кастомизированные версии проекта,

• ветка (branch) release/major - для исправлений базового функционала.

Добавление ветки release/major необходимо для реализации обязательных изменений в проекте, которые применимы и для всех кастомизированных версий (например, изменение в протоколе бронирования ЖД билетов).

Общая иерархия версионности в системе контроля версий проекта:

Open

Организация стенда непрерывной интеграции

Разработка и обновление Платформы состоят из следующих этапов.

Фаза разработки:

1. Разработчик производит изменение в коде

2. Разработчик выполняет локальное тестирование

3. Разработчик предоставляет код на ревью (пулл-реквест в терминах git)

4. Ревьювер выполняет слияние пулл-реквеста

5. Jenkins выполняет сборку и тестирование проекта в тестовой среде, выполняет публикацию тестового сайта

6. Разработчик выполняет контрольную проверку на стенде и вкладывает скриншоты/скринкасты со стенда в задачу + пулл-реквест

7. Постановщик задачи на доработку/исправление проводит приемку и либо закрывает задачу, либо возвращает на доработку

Раз в сутки для базовых мастер-веток версий 3.0 и 3.1 выполняется статический анализ программного кода (continuous inspection of code quality, static analysis of code) с оповещением команды разработки о результатах сканирования. Срабатывания анализатора кода ставятся в стек отдельными задачами и разбираются командой разработки в рабочем порядке.

Open

Фаза публикации:

1. Из стабильной мастер-ветки инициируется создание ветки публикации - дальше она фиксируется, и позволяет делать хотфиксы для продуктовых публикаций, в то время как разработка продолжается в мастер-ветке

2. Jenkins выполняет сборку и тестирование проекта, выполняет отдельную публикацию на стенд предпрода, и дальше запускает отдельным независимым процессом статический анализ программного кода (continuous inspection of code quality, static analysis of code)

3. Командой поддержки выполняется оповещение о начале тестирования и выполняется проверка базовых сценариев тестирования. Заказчики доработок или обладатели уникальной бизнес-логики выполняют проверку по собственным сценариям

4. В случае нахождения неисправностей выполняется исправление в ветке публикации, и затем исправления доставляются в мастер-ветки

5. В случае срабатываний анализатора кода принимается решение об:

   1. - отправке сборки на доработку, или

   2. - публикации ее в продуктовом контуре с формированием техдолга и скорейшим исправлением обнаруженных причин срабатываний (сценарий хотфикса с доставкой приоритетного обновления)

6. Обновление доставляется на продуктовую среду

7. Jenkins выполняет тестирование продуктовой среды

Организация публикации версии заказчика

Для работы с версией заказчика формируется отдельное задание в системе Jenkins, которое отслеживает обновления в ветке заказчика и выполняет:

• публикацию отдельного сайта с версией заказчика и набором модов, необходимых заказчику

• тестирование опубликованного сайта общим набором тестов

• тестирование опубликованного сайта персонфицированным набором тестов, с учтом особенностей версии и бизнес-процессов заказчика

• клонирование ветки release со стабильной версией в отдельную датируемую ветку для поддержания версионности

• формирование .sql-файлов с актуальными на момент сборки схемами данных

Процесс публикации может быть представлен в виде следующей диаграммы:

Описание процесса тестирования

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

1. Разработка: автоматизированное тестирование заданием Jenkins в момент публикации на тестовой среде (производится тестовая выписка услуг у поставщиков)

2. Развертывание: автоматизированное тестирование в тестовом контуре заказчика (производится тестовая выписка услуг у поставщиков)

3. Обновление: автоматизированное тестирование в боевом контуре заказчика (используется боевой доступ к системам поставщиков, выписка не производится)

Тесты представляют собой наборы функциональных тестов, подготовленных в среде Selenium, и выполняемых при помощи SeleniumWebDriver.

Разработка тестов ведется в средах SeleniumIDE и VisualStudio с использованием фреймфорка тестирования xUnit, что позволяет автоматизировать запуск тестов и сделать возможным их исполнение на стороне заказчика.

Общий набор тестов включает в себя:

• поиск вариантов авиа/жд/гостиниц

• формирование заказов для услуг авиа/жд/гостиниц

• просмотр очереди актуальных командировок и обнаружение сформированной командировки и заказов в ней

• просмотр очереди актуальных заказов и обнаружение сформированных заказов

• отправка заказов на авторизацию

• авторизация заказов

• оформление заказов

• отмена заказов

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

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

Набор тестов кастомизированной версии заказчика согласовывается и разрабатывается в рабочем порядке.

Разработка тестовых сценариев заказчика

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

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

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

3. Разработка тестов. В большинстве случаев разработка тестов размечается средствами Selenium IDE, которое записывает действия пользователя в браузере. В дальнейщем эти сценарии конвертируются в язык C# и дорабатываются в среде Visual Studio, что дает намного больше возможностей по автоматизации и реализации гибкости сценариев.

4. Отладка и приемка тестов. Разработанные тесты отлаживаются на различных наборах данных и предоставляются заказчику для проверки и приемки. При необходимости в наборы данных или исходный код тестов вносятся исправления.

Разработанный тестовый сценарий представляет собой проект VisualStudio и исполняемых пакетных файлов или скриптов PowerShell:

Возможности по запуску тестовых сценариев

Тестовые сценарии выполняются запуском консольной команды .NET Core

dotnet test

Запуск вручную пользователем

Команду запуска тестов можно запустить в командной строке Windows или в среде PowerShell. Результат выполнения теста в этом случае будет выглядеть следующим образом:

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

Запуск средствами CI

При выполнении автоматизированного тестирования не сервере непрерывной интеграции средствами Jenkins, в соответствующее задание добавляется шаг выполнения консольной команды:

Результат выполнения тестов будет доступен в журнале выполнения заданий и будет корректно обрабатываться Jenkins.

Пример успешного выполнения:

Пример неуспешного выполнения:

Возможности инструментов автоматизированного тестирования

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

Частичные обновления

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

Подготовка файлов с отчетами запусков

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

Выборочное выполнение тестов

Использование атрибутов позволяет присваивать тестовым методам метки и по ним фильтровать выполняемые при запуске методы:

Передача внешних параметров

Благодаря передаче внешних параметров возможно выполнять одинаковые тестовые сценарии для разных доменов или пользователей не меняя ничего в исходном коде тестов:

Описание процесса обновления

Подготовка исходных данных для обновления

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

Подготовка очередной версии включает в себя следующие шаги:

1. Выполняется публикация проекта

2. Выполняется экспорт схемы БД

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

4. Формируется архив из исходников и схемы БД и доставляется в контур клиента

Выполнение обновления на стороне заказчика

Обновление Платформы на стороне заказчика выполняется в два этапа:

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

2. В боевой среде с выполнением тестирования под боевыми доступами к поставщикам, без выпики билетов.

Общий алгоритм обновления

1. Остановить IIS (или пулы приложений сайтов)

2. Выполнить полный бэкап БД

3. Для каждого сайта Платформы, входящего в обновление:

   1. Если рядом с директорией сайта находится директория вида [ггггммдд]_[название_сайта], упаковать в архив и переместить к остальным резервным копиям сайтов (см. Веб-сервер : Резервные копии)

   2. Переименовать текущую директории с сайтом в [ггггммдд]_[название_сайта] (оперативная резервная копия)

   3. Распаковать архив с обновлением и скопировать туда файл конфига из текущей версии (более подробно про файлы конфига описано в разделе 1. Архитектура и первичные настройки платформы : Файлы конфигурации сайтов)

4. Применить схемы БД (выполнить поставляемые скрипты)

5. Переименовать директорию с лог-файлами в [ггггммдд]_[logs], чтобы облегчить сбор логов тестов

6. Запустить IIS (или пулы приложений сайтов)

7. Запустить автотесты тестовой/боевой среды

8. Если все тесты завершились успешно директории с устаревшими версиями сайтов и лог-файлы из переименованной директории переместить в долговременное хранилище (см. Веб-вервер : Резервные копии, Веб-сервер : Лог-файлы)

В случае сбоя тестов:

1. Остановить IIS

2. Удалить базы данных и восстановить из бэкапов прошлые версии

3. Удалить сайты и восстановить их переименованных директорий

4. Запустить IIS

5. Собрать и предоставить на анализ лог-файлы - целиком директорию logs, так как там будут только свежие лог-файлы тестов.

Обновление в боевой среде

Для сокращения времени, необходимого для обновления боевой среды, для каждого сайта необходимо создать предварительную копию (например, prd.corteos.ru - preprd.corteos.ru), и выполнить настройку этих сайтов для образования общего препродуктового контура, так чтобы обращения шли на предварительную версию движков, и лог-файлы собирались в отдельной директории, например c:\corteo\logs-prepublish (см. 1. Архитектура и первичные настройки платформы : Файлы конфигурации сайтов).

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

Регламент резервного копирования и обслуживания

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

Сервер БД

Организовывается автоматизированное выполнение полного резервного копирования всех баз данных Платформы с использованием заданий Агента MS SQL Server.

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

Рекомендуемый срок хранения резервных копий БД: 30 суток и более. Хранение копий более 60 суток в целом нецелесообразно, так как схемы данных и хранимая информация могут за это время сильно устареть.

Веб-сервер

Резервные копии

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

Рекомендуемое число резервных копий для хранения: 3 последние версии и более. Хранение копий с давностью публикации более 60 суток при наличии более свежих публикаций в целом нецелесообразно, так как за это время архитектура проекта может сильно устареть.

Лог-файлы

В ходе своей работы основной сайт Платформы и сайты сервисов непрерывно сохраняют множество лог-файлов, необходимых для расследования и исправления возникающих инцидентов.

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

По умолчанию лог-файлы размещаются по физическому расположению “c:\corteos\logs“, более подробно узнать про настройки расположения лог-файлов можно в разделе 1. Архитектура и первичные настройки платформы : Файлы конфигурации сайтов.

В зависимости от количества свободного дискового пространства рекомендуется хранить лог-файлы за последние 60 дней и более.