Описание процессов, обеспечивающих поддержание жизненного цикла «Апостол CSMS»

1. Общая модель жизненного цикла

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

Развёртывания заказчиков обновляются не автоматически: решение об установке новой версии и момент установки принимает владелец развёртывания. Правообладатель публикует версию и сопроводительные сведения к ней, а не рассылает её принудительно.

Такое разделение обязательно: оно позволяет заказчику планировать окно обновления и означает, что программа не изменяется на его инфраструктуре без его ведома.

2. Персонал

Для поддержания жизненного цикла требуются следующие роли.

Разработчик серверной части — владение языком C++ стандарта C++20, языком PL/pgSQL, СУБД PostgreSQL, сетевым программированием и промышленными протоколами предметной области.

Разработчик пользовательских приложений — владение языками TypeScript и JavaScript, современными веб-фреймворками, вёрсткой адаптивных интерфейсов.

Инженер по эксплуатации — владение контейнеризацией, средствами непрерывной интеграции, администрированием Linux и PostgreSQL, средствами наблюдения за работой систем.

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

В настоящее время все перечисленные роли исполняет правообладатель лично: он же является единственным автором программы. Для работ, выходящих за рамки его компетенции или объёма, привлекаются подрядчики по договору. Такая схема выбрана намеренно: она исключает разрыв знания о продукте между людьми и не требует передачи прав на результаты работ третьим лицам.

Обязательного требования к численности штата процессы не предъявляют. При росте числа развёртываний расширяются роли инженера по эксплуатации и специалиста поддержки — они масштабируются независимо от разработки.

3. Среда разработки и хранение исходного текста

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

Исходный текст хранится в системе управления версиями Git, размещённой на технических средствах в Российской Федерации. Там же размещён реестр собранных образов.

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

4. Управление версиями

Нумерация версий трёхчастная. Увеличение третьей части означает исправление неисправностей без изменения состава и параметров развёртывания. Увеличение второй — новые возможности, возможно появление новых параметров или сервисов; к такому выпуску прилагается описание перехода. Увеличение первой — изменения, требующие внимания при переходе, в том числе несовместимые изменения схемы данных.

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

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

5. Контроль качества

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

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

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

Для проверок протокола зарядных станций в состав входит эмулятор оборудования: сценарии воспроизводятся без физических станций.

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

6. Порядок выпуска версии

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

Простановка метки запускает конвейеры сборки. Каждый конвейер прогоняет проверки, собирает образ и публикует его. Сборка образа при неуспешных проверках не выполняется.

После успешной сборки инструмент выпуска сверяет состояние всех конвейеров и формирует файл фиксации версии с контрольными суммами всех образов. Этот файл — то, что получает развёртывание.

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

7. Обкатка и порядок раскатки

Новая версия проходит среды последовательно: среда разработки, затем предварительная среда, затем промышленная эксплуатация. Минимальный срок наблюдения в среде разработки — сутки, в предварительной среде — неделя. Сроки сокращаются только для исправлений, устраняющих неисправность, уже проявившуюся в эксплуатации.

Порядок обновления развёртываний определяется радиусом поражения: сначала обновляются развёртывания с наименьшими последствиями отказа, промышленное — последним.

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

8. Доставка версии в развёртывание

Обновление выполняется на стороне развёртывания скриптом обновления. Порядок описан в руководстве администратора; здесь важны два свойства процесса.

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

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

9. Управление изменениями схемы данных

Изменения схемы оформляются пронумерованными сценариями миграции, применяемыми строго по порядку и однократно. Журнал применённых миграций хранится в самой базе данных.

Миграции проектируются совместимыми с предыдущей версией прикладного кода: это позволяет откатить образы без отката данных.

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

10. Устранение неисправностей, выявленных в ходе эксплуатации

Сведения о неисправности поступают тремя путями: обращение владельца развёртывания или пользователя, сообщение системы наблюдения, самостоятельное обнаружение при сопровождении.

Порядок обработки: регистрация обращения, воспроизведение неисправности на демонстрационном или предварительном развёртывании, установление причины, разработка исправления, проверка, выпуск версии, доставка.

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

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

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

11. Совершенствование программы

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

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

Отклонённые предложения фиксируются вместе с причиной отклонения наравне с принятыми: решение не делать — тоже решение, и оно должно быть прослеживаемым.

Отдельная линия совершенствования — поддержка новых версий отраслевых протоколов и требований законодательства. Она планируется заранее, поскольку сроки в этой линии задаются не правообладателем.

12. Сторонние компоненты и безопасность

Состав сторонних компонентов с открытым исходным текстом контролируется: ведётся их перечень с указанием лицензий. Компоненты с лицензиями, налагающими обязательства по раскрытию исходного текста производного произведения, в поставку не включаются.

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

Сведения об уязвимостях в использованных компонентах отслеживаются; устранение выполняется в порядке, установленном для неисправностей, с приоритетом по степени опасности.

13. Управление ключами и секретами

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

Смена ключей — отдельная процедура, выполняемая по письменному регламенту и только при подозрении на компрометацию. Она влечёт перевыпуск лицензий всех действующих развёртываний.

Секреты развёртываний правообладателю не принадлежат и им не хранятся, за исключением развёртываний, которые он сам эксплуатирует по договору.

14. Документация

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

Расхождение документации с фактическим поведением программы рассматривается как неисправность документации и устраняется тем же порядком, что и неисправность программы.

15. Прекращение поддержки версии

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

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

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

16. Связанные документы

• Описание функциональных характеристик
• Руководство администратора
• Регламент технической поддержки