Про обновление дистрибутива написано ближе к концу статьи. Автоматизировали только установку кусочков, которые иногда нужно выдернуть из дистрибутивных обновлений.
Полную установку дистрибутивных патчей и допов не автоматизировали. Это процесс слишком сложный, особенно с учётом установки ТЯ, и длительный по времени - в том числе требуется отдельное согласование такого огромного технологического окна.
А главное, что смысла большого нет в такой автоматизации, т.к. эти обновления ставятся на каждый тестовый контур единоразово и крайне не часто, иногда даже на все сервера и не делаем установку, а просто копируем всю базу с одного сервера на другой для экономии времени.
Если речь про правку дистрибутивного кода, то в статье указано, что ключа у нас нет. Править мы ничего в дистрибутиве не должны, но конечно изредка приходится это делать по срочным ошибкам, одновременно с их регистрацией, чтобы не ждать несколько месяцев исправление от ЦФТ. Такие изменения могут быть включены в автоустановку в виде sql-скрипта на обновление исходников и перекомпиляцию. Сам дистрибутивный объект в основной проект IDE при этом не включаем, т.к. он в этом случае не сможет устанавливаться средствами IDE без ключа, да и дальше будет меняться в дистрибутиве независимо от нашего git. Однако, такие объекты мы себе сохраняем в отдельный проект, который вообще не предназначен для установки, просто, по нему можно сверить наличие исправлений ошибок, когда будет развёрнута очередная версия дистрибутива.
Получается, что на данный момент A2 — уже помесь A1, Pick и UAdmin, так ведь будет правильно сказать.
В статье сказано, что «Большинство недочетов, которые мы фиксируем, ЦФТ устраняет в пределах месяца». Это достаточно точная фраза — большинство регистрируемых ошибок устаняют быстро, но часть исправлений несколько затягивается, что, на мой взгляд, представляет нормальный рабочий процесс.
Например, по функционалу с группами доступа несколько ошибок было исправлено, пока статья находилась на модерации. Сейчас вижу, что осталась только одна проблема — доступ на операции в ссылочных ТБП. Здесь нет смысла останавливаться на таких подробностях, т.к. есть уверенность, что и эту ошибку поправят в ближайших версиях. В статье лишь хотел подчеркнуть, что система всё ещё очень активно развивается, в неё вводятся большие куски нового функционала, где неизбежны «детские болезни», которые, однако, вполне эффективно лечатся разработчиками.
Ещё раз соглашусь, докапаться до содержимого и поменять mdb тоже можно после соответствующих усилий. Но я говорю о легком способе интуитивно понятном любом разработчику или сопровожденцу. В случае с mdb такого способа нет, это имелось ввиду в статье.
Только такой трюк не удастся с подписанным хранилищем (pckx)
Что касается подписанных zip, там тоже только просмотром есть смысл пользоваться, т.к. при изменении подпись, разумеется, станет невалидной.
Единственное, что такое pckx? Есть xpck — подписанный список элементов для удаления (всё в одном файле), либо хранилище mdb и отдельно его подпись в файле sgn.
Отмечу, что для zip информация о подписи содержится внутри самого этого архива в отдельном файле.
Спасибо за обратную связь!
С переходом мы раньше постарались, т.к. были важны преимущества новой платформы. Но сейчас ЦФТ всех туда гонит, предупреждая, что старые АРМы разработчика со следующего года обновляться перестанут и они вскоре могут перестать работать.
Теоритически, возможно менять и в mdb, но есть существенные ограничения, которые многих останавливают.
Во-первых, должен быть установлен MS Access, причём версии 2010 и ранее, т.к. современный Access даже не открывает mdb, сохранённый Администратором проектов ЦФТ (формат файла MS Access 2.0 является устаревшим).
Во-вторых, и самое главное, mdb — это база данных, структура которой не прозрачна и не описана в документации.
При этом структура хранения файлов в zip идентична структуре хранения файлов в проекте, как и сами эти файлы. Т.е. всё совершенно прозрачно и не требует в обязательном порядке вообще никаких дополнительных инструментов для просмотра и редактирования.
Про обновление дистрибутива написано ближе к концу статьи. Автоматизировали только установку кусочков, которые иногда нужно выдернуть из дистрибутивных обновлений.
Полную установку дистрибутивных патчей и допов не автоматизировали. Это процесс слишком сложный, особенно с учётом установки ТЯ, и длительный по времени - в том числе требуется отдельное согласование такого огромного технологического окна.
А главное, что смысла большого нет в такой автоматизации, т.к. эти обновления ставятся на каждый тестовый контур единоразово и крайне не часто, иногда даже на все сервера и не делаем установку, а просто копируем всю базу с одного сервера на другой для экономии времени.
Если речь про правку дистрибутивного кода, то в статье указано, что ключа у нас нет. Править мы ничего в дистрибутиве не должны, но конечно изредка приходится это делать по срочным ошибкам, одновременно с их регистрацией, чтобы не ждать несколько месяцев исправление от ЦФТ. Такие изменения могут быть включены в автоустановку в виде sql-скрипта на обновление исходников и перекомпиляцию. Сам дистрибутивный объект в основной проект IDE при этом не включаем, т.к. он в этом случае не сможет устанавливаться средствами IDE без ключа, да и дальше будет меняться в дистрибутиве независимо от нашего git. Однако, такие объекты мы себе сохраняем в отдельный проект, который вообще не предназначен для установки, просто, по нему можно сверить наличие исправлений ошибок, когда будет развёрнута очередная версия дистрибутива.
В статье сказано, что «Большинство недочетов, которые мы фиксируем, ЦФТ устраняет в пределах месяца». Это достаточно точная фраза — большинство регистрируемых ошибок устаняют быстро, но часть исправлений несколько затягивается, что, на мой взгляд, представляет нормальный рабочий процесс.
Например, по функционалу с группами доступа несколько ошибок было исправлено, пока статья находилась на модерации. Сейчас вижу, что осталась только одна проблема — доступ на операции в ссылочных ТБП. Здесь нет смысла останавливаться на таких подробностях, т.к. есть уверенность, что и эту ошибку поправят в ближайших версиях. В статье лишь хотел подчеркнуть, что система всё ещё очень активно развивается, в неё вводятся большие куски нового функционала, где неизбежны «детские болезни», которые, однако, вполне эффективно лечатся разработчиками.
Что касается подписанных zip, там тоже только просмотром есть смысл пользоваться, т.к. при изменении подпись, разумеется, станет невалидной.
Единственное, что такое pckx? Есть xpck — подписанный список элементов для удаления (всё в одном файле), либо хранилище mdb и отдельно его подпись в файле sgn.
Отмечу, что для zip информация о подписи содержится внутри самого этого архива в отдельном файле.
С переходом мы раньше постарались, т.к. были важны преимущества новой платформы. Но сейчас ЦФТ всех туда гонит, предупреждая, что старые АРМы разработчика со следующего года обновляться перестанут и они вскоре могут перестать работать.
Во-первых, должен быть установлен MS Access, причём версии 2010 и ранее, т.к. современный Access даже не открывает mdb, сохранённый Администратором проектов ЦФТ (формат файла MS Access 2.0 является устаревшим).
Во-вторых, и самое главное, mdb — это база данных, структура которой не прозрачна и не описана в документации.
При этом структура хранения файлов в zip идентична структуре хранения файлов в проекте, как и сами эти файлы. Т.е. всё совершенно прозрачно и не требует в обязательном порядке вообще никаких дополнительных инструментов для просмотра и редактирования.
Не совсем так: НРД перешёл с одного инструментария разработки ЦФТ на другой — так будет вернее
Без помощи не обошлось, но внедрение у них мы не заказывали, обошлись своими силами, именно поэтому есть о чём рассказать
Тема не настолько широкая, а в первую очередь, материал может быть полезен именно специалистам по ЦФТ-Банк и ЦФТ-Ритейл банк.