Управление версионностью отраслевых программных продуктов

Системы контроля версиями записывают и сохраняют несколько изменений в файлах. Благодаря этому можно вернуться к определенной точке истории изменения файла или проекта. Некоторые системы, такие как Subversion, отслеживают историю отдельных файлов. Другие, такие как Git и Mercurial, отслеживают историю целых репозиториев.

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

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

В любом приложении реализован как минимум базовый уровень локального управления версиями, состоящий из функций «отменить» и «повторить». Некоторые программы, такие как Microsoft Office и документы Google, содержат более сложные функции, такие как сравнение версий и комментирование.

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

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

Управление версиями составных конфигурационных объектов. Понятие "ветки" проекта. Одновременно может существовать несколько версий системы – и в смысле для разных заказчиков и пр. (так сказать, в большом, настоящем смысле), и в смысле одного проекта, одного заказчика, но как разный набор исходных текстов. И в том и в другом случае в средстве управления версиями образуются разные ветки. Остановимся чуть подробнее на втором случае.

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

- V1.0 – ветвь, соответствующая выпущенному релизу. Внесение изменений в такие ветви запрещены и они хранят образ кода системы на момент выпуска релиза.

- Fix V1.0.1 – ветвь, соответствующая выпущенному пакету исправлений к определенной версии. Подобные ветви ответвляются от исходной версии, а не от основной ветви и замораживаются сразу после выхода пакета исправлений.

- Upcoming (V1.1) – ветвь, соответствующая релизу, готовящемуся к выпуску и находящемуся в стадии стабилизации. Для таких ветвей, как правило, действуют более строгие правила и работа в них ведется более формально.

- Mainline – ветвь, соответствующая основному направлению развития проекта. По мере созревания именно от этой ветви отходят ветви готовящихся релизов.

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

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

В итоге в программном проекте начинают происходить мистические и загадочные события.

- Тщательно оттестированная программа на показательных испытаниях не работает

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

- На компьютере разработчика программа работает, а у заказчика – нет….

Разгадка проста – все дело в версиях файлов. Там, где все хорошо, присутствуют файлы одной версии, а там, где все плохо – другой. Но беда в том, что "версия всего продукта" – это абстрактное понятие. На деле есть версии отдельных файлов. Один или несколько файлов в поставке продукта имеют не ту версию – все, дело плохо. Необходимо управлять версиями файлов, а то подобная мистика может стать огромной проблемой.

Она серьезно тормозит внутреннюю работу. То разработчики и тестеры работают с разными версиями системы, то итоговая сборка системы требует специальных усилий всего коллектива. Более того, возможны неприятности на уровне управления. Различные курьезные ситуации, когда заявленная функциональность отсутствует или не работает (опять не те файлы послали!), могут сильно портиmь отношения с заказчиком. Недовольный заказчик может потребовать даже денежной компенсации за то, что возникающие ошибки слишком по долгу исправляются. А будет тут не долго, когда разработчики не могут воспроизвести и исправить ошибку, так как не могут точно определить, из каких же исходных текстов была собрана данная версия!

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

Выделим две основные задачи в конфигурационном управлении – управление версиями и управление сборками. Первое отвечает за управление версиями файлов и выполняется в проекте на основе специальных программных пакетов – средств версионного контроля. Существует большое количество таких средств – Microsoft Visual Source Safe, IBM Clear Case, CVN, Subversion и др. Управление сборками – это автоматизированный процесс трансформации исходных текстов ПО в пакет исполняемых модулей, учитывающий многочисленные настройки проекта, настройки компиляции, и интегрируемый с процессом автоматического тестирования. Эта процедура является мощным средством интеграции проекта, основой итеративной разработки.

За основу изучения взяты операционная система Windows 7.0 и 8.1 и «1С:Предприятие». 1С:Предприятие — программный продукт компании «1С», предназначенный для автоматизации деятельности на предприятии.

«1С:Предприятие» предназначено для автоматизации бухгалтерского и управленческого учётов (включая начисление зарплаты и управление кадрами), экономической и организационной деятельности предприятия.

Так например, технологическая платформа «1С:Предприятие» представляет собой программную оболочку над базой данных. Используются базы на основе DBF-файлов в 7.7, собственный формат 1CD с версии 8.0 или СУБД Microsoft SQL Server на любой из этих версий^[1]. Кроме того, с версии 8.1 хранение данных возможно в PostgreSQL и IBM DB2, а с версии 8.2 добавилась и Oracle. Платформа имеет свой внутренний язык программирования, обеспечивающий, помимо доступа к данным, возможность взаимодействия с другими программами посредством OLE и DDE, в версиях 7.7, 8.0 и 8.1 — с помощью COM-соединения.

Клиентская часть платформы функционирует в среде Microsoft Windows, а начиная с версии 8.3, также в среде Linux и Mac OS X. Начиная с версии 8.1, серверная часть платформы в клиент-серверном варианте работы «1С:Предприятия» может функционировать на ОС Microsoft Windows и Linux.

Существуют специальные версии среды исполнения 1С для ноутбуков и PDA, ПО создания веб-приложений, взаимодействующих с базой данных «1С:Предприятие».

Начиная с версии 7.7 «1С:Предприятие» состоит из программной оболочки, или движка, который работает с одной или несколькими базами данных, определяемыми конфигурацией. К программной оболочке подключаются компоненты (в терминологии 1С — «компонента»), реализующие различные механизмы учёта и администрирования. Стандартные «компоненты»:

- «Бухгалтерский учёт»;

- «Оперативный учёт»;

- «Расчёт»;

- «Управление распределёнными ИБ» (Информационными Базами);

- «Web-расширение 2.0».

Кроме объектов, соответствующих реализующим механизмы учёта компонентам, существуют также компонент-независимые «базовые объекты», поддержка которых присутствует всегда.

Может работать в нескольких режимах:

- 1С:Предприятие — основной режим работы пользователя, ввод данных, получение отчётов;

- Конфигуратор — режим администрирования и изменения конфигурации;

- Отладчик — режим отладки и замера производительности конфигурации;

- Монитор — режим просмотра активных пользователей и журнала регистрации событий.

 

Версия 8.3

В качестве крупных изменений этой версии можно отметить:

- предоставление пользователям нативных 64-битных клиентов под Linux и MacOS. (Клиентские приложения существуют только для Mac OS X 10.8 и выше, и выпускаются для целей бета-тестирования).

- 64-битный клиент и Конфигуратор для Windows

- полноценную мобильную платформу для iOS, Android и Windows Phone

- переработку механизма расположения элементов в формах

- изменения в интерфейсных механизмах

Разработчики также получили большое количество изменений, в том числе:

- возможность создавать расширения конфигурации, позволяющие изменять конфигурацию без снятия её с поддержки

- улучшение механизмов хранилища конфигурации и сравнения объектов

- механизм рефакторинга кода

- механизм автоматизированного тестирования интерфейса

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

 

Система защиты

Для защиты продукта «1С:Предприятие» от несанкционированного использования компания 1С использует аппаратные ключи HASP. Такая система защиты не даёт 100 % защиты от пиратов, например Сергей Давыдюк создал программный эмулятор системы защиты, за что в 2005 году был приговорён к двум годам заключения условно. Однако у неопытных специалистов создаёт значительные трудности при внедрении продукта.

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