Системы контроля версий файлов в инженерном деле

Системы контроля версий файлов в инженерном деле

Термины

Техническая цивилизация создана инженерами

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

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

Цели

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

Цели автоматизации:

• Уменьшить трудоемкость обмена информацией и наработками
• Уменьшить неразбериху с версиями
• Упростить анализ изменений
• Увеличить производительность труда

Причины и предпосылки

Когда документация создавалась руками, проблемы электронных архивов ещё не было

• Документы современных w:САПР, системы инженерных и математических расчетов, электронные таблицы с калькуляцией, пояснительные записки, исходные материалы (особенно материалы инженерных изысканий) образуют огромный массив информации в электронном виде, организация которого отнимает много времени.
• Файлы, находящиеся в разработке постоянно меняются (как самим инженером, так и его коллегами, смежниками и заказчиками), разбор этих версий требует большого внимания. Пересылка новых версий по эл. почте или чатом, при всей их скорости и удобстве, быстро ставит вопрос "Какая версия актуальна?" или "Где полный набор материалов"? Особенно быстро путаница возникает при групповой работе.

Распространение САПР вызвало молниеносное накопление огромных массивов файлов

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

Задачи

Исходя из целей, формулируем постановку задач.

Дано:

• Дан инженер, работающий самостоятельно, либо группа инженеров, работающая совместно
• В своей работе они используют САПР, текстовые редакторы, системы расчетов и другие средства подготовки и выпуска документации в электронном виде. Исходные данные также накапливаются в электронном виде.
• По указанным выше (или иным причинам) пользователи не удовлетворены распространенными решениями задачи (почта, сетевой ресурс, DropBox, PDM).

Требуется:

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

Отличия потребностей инженера от программиста

 Программист - тоже инженер. Но в данном учебнике под инженером мы понимаем именно проектировщика и конструктора.

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

• Основной массив материалов в разработке ПО - это программный код. В большинстве случаев это текстовые файлы, которые пишет и читает программист, к которым возможно применение автоматического сравнения (операция w:diff) с наглядным отображением результатов сравнения и выполнением автоматического слияния .
• Документы САПР, как правило - это бинарные файлы (либо текстовые, но не легко читаемые человеком, например, Visio vdx формат, основанный на XML). Сравнение бинарного либо текстового вида хранения векторной информации, а тем более его автоматическое слияние, как правило, затруднено либо невозможно.

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

Варианты организации решения

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

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

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

• Новая версия файла затирает старую под тем-же названием, поэтому на любом ресурсе копятся файлы вида "Схема водоснабжения (в17 последняя)_Иванов_15декабря.dwg" или "Спецификация самая последняя.spw". Такие переименования файла также нарушают цельность ссылок между документами.
• Любой пользователь, имеющий доступ на запись к папке, может легко удалить или переименовать любой файл. Можно организовать резервное копирование, но сам факт удаления/изменения файла все равно не будет замечен ещё очень долго.
• Работа все равно ведется на рабочих компьютерах, т.е. синхронизировать материалы нужно либо руками, либо с помощью программ-синхронизаторов (например, w:en:FreeFileSync). На практике люди часто ленятся это делать, предпочитая работать локально, а на сетевой ресурс выкладывать материал по запросу или в последний день перед сдачей проекта.
• Сверка версий (что изменилось на чертеже) выполняется вручную (глазами).

Если инженер работает один (на мелких заказах) простым выходом является опубликованный файловый ресурс на сервисах типа w:Dropbox или w:Google Диск. Они удобны, но имеют недостатки

• Ограниченный размер (а инженерные файлы часто очень велики, например, чертеж с отсканированной подложкой - это уже десятки мегабайт)
• Сервер - только в облаке, вам не принадлежит, и доступ к нему может быть ограничен правилами корпоративной сети.
• Клиентские приложения мало чем могут помочь в плане отображения отличий в сравниваемых версиях файлов.

Частично эти ограничения сняты в системах типа w:ownCloud - сервер размещается на площадке самой организации, соответственно правила доступа и требуемые мощности можно регулировать. Но клиентское приложение всё равно ничем не поможет в визуальном сравнении.

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

Использование системы управления версиями файлов

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

Данные системы должны в нашем случае обеспечить следующие функции:

• Сервер:
  • Хранение всех версий файлов на сервере (в т.н. репозитарии), с историей их правок
  • Управление правами доступа, проверка авторизации
• Клиентское приложение:
  • Подключение к серверу, синхронизация файлов с рабочей копией (в обе стороны), отображение истории правок, откат к предыдущей/сохраненной версии, визуальное сравнение версий файлов.

Выбор типа сервера

Subversion (SVN) - централизованная система, для выполнения большинства операций (например, просмотр истории) требуется подключение. Можно назначать права доступа на отдельные подпапки репозитория, брать в работу часть репозитория (например, просто рассылайте пользователям URL 'репозиторий\папка\подпапка').

w:Git - наиболее известная децентрализованная система, часть операций (например, просмотр истории) выполняется локально. Права доступа можно выдавать выполнять только целиком на весь проект, взятие в работу также выгружает только весь проект (взять только 1 подпапку, как в SVN - нельзя). Также децентрализованность означает, что рабочая копия содержит также и всю историю правок (что увеличивает ее размер на локальном диске), и операции синхронизации выполняются не в 1 операцию (commit), как в svn, а в 2 (commit-push).

Для нашей цели мы остановимся на варианте SVN.

Общие вопросы

Общие вопросы организации коллективной работы, не зависящие от типа ПО.

• Определите заранее, будете ли вы создавать отдельный репозиторий на каждый проект, или выберите другой подход. Если проекты мало связаны друг-с-другом, то рекомендуется выбирать отдельные репозитории. В любом случае слить их воедино будет проще, чем разделять один большой репозиторий на части.
• Не переименовывайте файлы с пометками "версия_7_от_Петровича". Система контроля версий берет ведение истории на себя.
• Будет лучше не создавать огромных многостраничных файлов, содержащих весь проект на отдельных листах. Предпочтительнее побольше отдельных файлов - так гораздо удобнее отслеживать изменения от разных авторов.
• При использовании сканированных подложек (что часто встречается при реконструкциях или на чертежах с привязкой к местности) не внедряйте подложку в чертеж, делайте ссылку. Это значительно ускорит работу сервера.
• В документах со ссылками (например, с той-же привязкой к подложке) делайте ссылки с относительными путями, а не абсолютными. Тогда файл будет корректно открываться на всех рабочих местах

Публикация ссылок на репозитории

Необходимо определить, как пользователи будут получать ссылки на репозитории.

Если репозиторий один, то задача упрощается. Если под каждый проект заводится новая ссылка - необходимо:

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

У клиента w:en:Version Control for engineers имеется возможность публикации каталога репозиториев.

Общие термины

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

Репозиторий - полный набор всех файлов и их версий, хранящийся на сервере.

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

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

Subversion (SVN)

Subversion (SVN) - open-source решение, сервер и клиентская библиотека для работы с ним.

Установка и настройка сервера

1. В случае Windows - скачать и установить w:en:VisualSVN Server, бесплатную версию (не имеет существенных для нашей задачи ограничений). В случае наличия у организации домена - VisualSVN Server обеспечит прозрачную авторизацию пользователей.
2. В консоли VisualSVN Server создать репозиторий, указать права доступа к проекту
3. Запомнить и разослать пользователям http или https ссылку на новый репозиторий

Использование бесплатных провайдеров SVN-хостинга

Имеется набор бесплатных провайдеров, предоставляющих готовый хостинг для SVN-проектов.

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

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

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

Установка и настройка клиентской части

Имеется большой выбор клиентов w:en:Comparison of Subversion clients для работы с svn. Наиболее известным является w:TortoiseSVN, который встраивается в Проводник Windows (что требует прав администратора для установки). Доступна подробная документация на русском языке .

Также рассмотрим специализированный клиент w:en:Version Control for engineers. Он устанавливается как отдельное приложение, для чего не требует прав администратора Windows. В рабочем окне показан перечень проектов, что упрощает их поиск. В дополнение к функции сравнения графических форматов (Gif, PNG и т.д., как в TortoiseSVN), есть поддержка сравнения страниц w:Microsoft Visio и чертежей КОМПАС-График. Эти графические инструменты часто используются для оформления проектной документации, поэтому наглядное отображение внесенных правок на выбранной странице может быть очень полезным. Также клиент сигнализирует пользователю о том, что на сервере SVN появились обновления файлов, и стоит обновить рабочую копию.

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

Общий сценарий для проектирования с сфере ПГС

Мы развернули сервер, установили клиентские приложения у пользователей.

Сценарий использования для типового российского проектного института следующий

1. При старте проекта создать под него репозитарий. Выполняет эту операцию ГИП, его помощник, либо администратор системы по запросу ГИПа. Название для репозитория можно давать по коду проекта либо по его краткому названию.
2. Всем участникам проекта рассылается ссылка на новый репозиторий (см. Публикация ссылок на репозитории).
3. ГИП либо его помощник задает корневую структуру папок в репозитории, например
   1. Задание на проектирование (для всех материалов от заказчика)
   2. Изыскания
   3. Проектная документация
   4. Экспертиза
   5. Рабочая документация
4. В папку Задание на проектирование ГИП в свой рабочей копии размещает все исходные данные, выполняет коммит (отправку изменений на сервер)
5. В папку для изыскателей в своей рабочей копии файлов ГИП кладет задание для них (как правило, это просто текстовый документ), выполняет коммит (отправку изменений на сервер)
6. Изыскатели выполняют обновление своей рабочей копии, получают документ с заданием, выполняют работы, все материалы, представленные в электронном виде, помещают в свою рабочую копию и выполняют коммит.
7. ГИП выполняет обновление рабочей копии, проверяет наличие материалов изысканий, формирует задание для ведущего отдела (в нашем примере пусть это будет технологический), создает в папке Проектная документация папку ТХ, кладет в него задание, выполняет коммит (отправку изменений на сервер)
   1. Как вариант, для всех заданий между отделами можно выделить отдельную папку в данном репозитории, чтобы отделить их от самой документации
8. Далее все отделы выполняют свою работу, размещают задания смежникам в репозитории, все материалы размещают в соотв. папках своих рабочих копий. Коммуникации осуществляются в обычном режиме (устно, почтой, чатом), но измененные документы никому почтой не пересылаются, т.к. все материалы есть в SVN, от всех инженеров требуется только работать в своих рабочих копиях, и регулярно проверять изменения с сервера.
9. Внутренняя экспертиза, отдел выпуска, архив - все берут актуальную электронную копию из общего репозитория, скан копии результирующих документов также помещают в соотв. разделы репозитория.

Общий сценарий для конструкторского бюро

В случае, если проекты КБ - набор изделий с пересекающейся частью, т.е. часть СЕ и деталей общая, то есть смысл работать в едином репозитории.

Его структура примерно такова

1. Общие ДСЕ
2. Проекты
   1. Проект 1
      1. Эскизный проект
      2. Инженерные расчеты
      3. ДСЕ Номер
   2. Проект 2

В папку эскизного проекта можно помещать предварительные эскизы, т.е. общие проработки, не имеющие пока четкой структуры вложенности элементов. В папки ДСЕ Номер - уже проработанные модели и чертежи.

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

Типичные вопросы и возражения

Вопрос: Зачем так много лишних действий?

Ответ: Надо определить, лишних действий по отношению к чему? Если к пересылке файлов по почте, то пересылка - это скорее разовая акция, которая, к сожалению, входит в привычку, хотя ее недостатки очевидны (см. #Цели). Если сравнивать с самым простым и распространенным решением - сетевой папкой - то пользователь выигрывает, ведь вместо ручного сравнения и синхронизации каталогов функции отправить и получить делают сравнение автоматически.

Вопрос: Как вести реестр доступных проектов (репозиториев)?

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

Вопрос: Если всё так просто, почему так не делают все?

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

1. Многие - делают. И получают отдачу. Пробуйте и вы, ищите преимущества, боритесь с рутиной в своей работе.
2. Как уже было указано выше, системы управления версиями изначально разрабатывались программистами для программистов. Поэтому у решений этого класса часто есть множество функций, мало понятных не программисту, и ореол специфичности. На самом деле, уже есть клиентские приложения, максимально удобные в работе, не перегруженные лишним, которые могут дать многое инженеру.
3. Зачастую бесплатность определенного решения (все указанное ПО - бесплатное) может мешать его популярности, т.к. нет материальной заинтересованности у продавцов и других агентов влияния.

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

Ответ:

1. Если есть уверенность, что проектировщику действительно не нужны все материалы по проекту, он может брать в рабочую копию только папку со своим заданием, и туда-же помещать результаты.
2. Если материал нужен только посмотреть, то единичный файл можно получить через веб-интерфейс по адресу установленного VisualSVN-Server, через обычный веб-браузер.
3. Если работы над проектом выполнены, рабочую копию можно удалять, её повторное скачивание выполняется очень быстро.