| Еще о миграции ПО (01.09.2023). |
|
| 2023 - Сентябрь | |
| 01.09.2023 16:47 | |
Достаточно выложить факс, отправляемый головняку, затеявшему всю эту канитель. Данный текст не одобрен к отправке, т.к. есть детали (хотя описывается далеко не всё), - но он покажет хотя бы примерно: даже две циферки в версии ОС способны привести к головной боли. И ни о какой миграции на практике еще речи не идет: несколько месяцев возни - только подготовка. И еще столько же впереди. О переходе ПО изготовления утюгов на Astra Linux v.1.7. Уважаемый Брюс Всемогущий! При выполнении работ по Вашим указаниям об оценке времени и стоимости перехода ПО на Astra Linux v.1.7, были обнаружены программно-аппаратные несовместимости, требующие уточнения версий программных продуктов, на которые требуется переход. Это напрямую влияет на оценку времени выполнения перехода и сопутствующие ему работы (переработка инструкций по установке и обслуживанию ПО, модернизация установщика ПО и т.д.). В подготовке к оценке времени и стоимости перехода использовались четырехзначные версии операционной системы, ядра операционной системы, комплекта разработки для операционной системы «Develop», среды программирования Qt, программы ГИС. Примеры части выявленных программно-аппаратных несовместимостей разных версий продуктов: - Astra Linux v.1.7.0.0 содержит аппаратную несовместимость с современными встроенными видеоядрами Intel - что повлекло к дополнительным временным и материальным затратам при сборке тестового стенда. Напротив, это оказалось исправлено в версии v.1.7.3.0; - руководства программиста программы ГИС не отражают корректно ни год изготовления, ни принадлежность к определенной версии продукта. Данное руководство требуется не искать во внешней среде, а брать непосредственно из коробки дистрибутива конкретной версии. До этого момента невозможно сравнить руководства программиста 2014 и 2023 годов на предмет различий API-функций – невозможно оценить дополнительные временные затраты переработки всех модулей ПО в контексте взаимодействия с ГИС. Также при работе со старой версией ГИС было эмпирически обнаружено, что требуется набор дополнительных пакетов, отличный от Astra Linux SE v.1.4; - малейшее изменение версии ядра операционной системы приводит к несовместимости с комплектом разработки Develop – что влечет использование другого комплекта. В свою очередь, это может привести к изменению версии среды программирования Qt или библиотек в ее составе. В итоге, программные несовместимости между версиями Qt внутри исходного кода ПО будут иного характера. На примере ядер v.5.4.0-54/v.5.4.0-110, Astra Linux v.1.7.0.0/v.1.7.3.0/v.1.7.4.0, комплектов разработчика v.11.06.2021_12.40/1.7.4-base/1.7.4.ext1.4, Qt v.5.15.2.0/v.5.15.2.0. Версии Qt выглядят одинаково в разных комплектах – но при смене версии ядра не устанавливаются: ни прямой, ни обратной совместимости между комплектами разработки нет, и это проявляется разными ошибками. По совокупности сказанного: - указанная версия Astra Linux «1.7» содержит двухзначный номер версии, недостаточный для выполнения работ; - без уточнений с Вашей стороны 4-значных версий операционной системы, ядра операционной системы, программы ГИС, комплекта разработки для операционной системы «Develop» (и автоматически среды программирования Qt в его составе) – выполнение работ по оценке времени и стоимости перехода ПО на новую версию Astra Linux не представляется возможным. То есть, до начала миграции будут впереди этапы: - проводить работы по выбору всех этих версий (сторонней организацией); - утюжить ГИС официальными письмами для предоставления нормального мануала по конкретной версии продукта; - заново переписывать инструкцию по установке и настройке Astra (как минимум, все перепроверять); - переделывать инструкцию по настройке сервера SQL при неизвестности, как должно быть правильно; - переделывать инсталлятор ПО под новую версию сервера SQL. Далее - переходить уже к исходникам. Эта часть была выполнена в лоб вне требований версий, без SQL - и показала: - все модули идут по езде (даже не требующие SQL). Ничего не компилируется, не запускается, красных ошибок десятки-сотни в каждом модуле. Компилятор матерится на собственные системные файлы - и это проблемы именно ПО: новые проекты Hello World в Qt успешно работают; - модулей всего 34, 50-350КБ исходного кода каждый; - неработающие участки кода нужно не уничтожать, а переписывать. В итоге, при самом оптимальном прогнозе, на 1 модуль будет уходить 2 недели только на доведение до состояния "скомпилировался и запустился". Потом еще 2 недели отладки, и протестировать нужно вообще все; - 34 модуля, по месяцу на каждый - 3 года на миграцию. Одним человеком, которого никто ни на что не должен отвлекать; - после 3 лет проведения миграции - неизбежно наступит второй этап миграции. Пока мигрировалась условная версия 1.0 - версия 1.0 дорабатывается и становится версией 2.0. Значит, вручную нужно из версии 2.0 на Astra 1.4 переносить изменения в версию 1.0 на Astra 1.7. И если изменений много - наступит еще один этап миграции: с переносом уже меньшего количества кода. И так - до полной синхронизации. И тестировать все перенесенные изменения, конечно же; - то есть, реальный срок миграции - 4 года. Одобрит заказчик такие сроки или нет - мне все равно. В отличие от людей, считающих себя богами и урезающих сроки разработки простым смертным: я - смертный, но посылать на хрен хорошо умею. Само понимание того, что предстоит, - это уже сквозь пламя в ад; и никакими деньгами это не изменить. |
|
| Обновлено ( 01.09.2023 17:34 ) |