Конструктор тонет в папках «финал2»: версии чертежей на своём сервере

MAATRIX

У каждого конструктора рано или поздно на сетевом диске заводится папка «финал». Потом рядом появляется «финал2». Потом «финал_ИСПРАВЛЕННЫЙ», «финал_ТОЧНО ПОСЛЕДНИЙ» и файл с припиской «использовать ЭТОТ, не тот что выше». Если это вам знакомо — вы не одиноки, так живёт большинство небольших конструкторских бюро и одиночек-инженеров. Дальше разберём, почему имя файла — плохая система версионирования, и как за вечер поднять на своём сервере нормальную историю изменений чертежей, не переплачивая за тяжёлый PDM.

Знакомая боль: как рождаются «финал2» и «окончательный_ТОЧНО»

Механизм всегда один и тот же. Вы открываете сборку, вносите правки, жмёте «Сохранить как» — потому что боитесь испортить рабочий вариант, если что-то пойдёт не так. Через неделю таких копий уже пять, и вспомнить, чем «Корпус_v3» отличается от «Корпус_v3_испр», без пристального сравнения невозможно. Если над проектом работает не один человек, к этому добавляется вторая проблема: коллега параллельно открыл ту же сборку из своей локальной копии, внёс свои правки, сохранил — и теперь у вас два «финала», один из которых потеряется безвозвратно.

Самое неприятное случается не на этапе разработки, а на этапе передачи в производство или заказчику. Кто-то берёт файл не из той папки — потому что структура «Проект / Чертежи / Финал / Финал2 / Актуальное» интуитивно понятна только тому, кто её создавал, и то через месяц забывает логику. Деталь режут по старой версии, узел не собирается, разбор полётов упирается в вопрос «а кто и когда поменял этот размер» — и ответа на него нет, потому что имя файла не хранит историю, оно хранит только текущее состояние.

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

Что должно уметь нормальное версионирование чертежей

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

• Автоматическая история каждого сохранения — без ручного действия «сделай копию перед правкой». Система сама хранит предыдущие версии файла при каждой перезаписи.
• Один актуальный путь к файлу — деталь или сборка живёт по одному и тому же адресу всё время, а не переезжает между папками «в работе» / «финал» / «архив» вручную.
• Откат без звонка админу — если нужно вернуться к состоянию недельной давности, инженер делает это сам за пару кликов, а не пишет заявку в ИТ-отдел.
• Кто и когда сохранил — метаданные версии: автор и время, а лучше и комментарий к изменению, если формат это позволяет.
• Защита от одновременной правки — блокировка файла, пока один человек с ним работает, чтобы не получить два несовместимых «финала» одновременно.
• Доступ из привычного «Открыть/Сохранить» — если для каждой правки нужно лезть в браузер и скачивать-загружать файл руками, через месяц команда вернётся к локальным копиям и старым привычкам.
• Контроль, где физически лежат данные — часть чертежей у многих команд подпадает под NDA с заказчиком или ограничения на передачу данных за рубеж, и публичное облако третьей стороны тут не всегда вариант.

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

Обзор подходов: от сетевой шары до PDM

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

Для одиночки-конструктора или бюро на несколько человек первые два варианта не решают проблему, а последний — избыточен и дорог. Золотая середина — файловое хранилище с историей версий вроде Nextcloud или Seafile: оно ощущается как обычная папка на диске, но помнит каждое сохранение и умеет блокировать файл во время правки. Разница между ними: Nextcloud больше про экосистему приложений и знаком большему числу людей, Seafile — про более экономное хранение версий на диске за счёт хранения дельт, а не полных копий каждой версии. Сравнение разобрано отдельно в статье Seafile или Nextcloud: что выбрать для сервера — если сомневаетесь, начните с Nextcloud, он проще в первом знакомстве.

Git с LFS — рабочий вариант, если в команде уже есть человек, комфортно чувствующий себя с командной строкой, а чертежи по большей части в нейтральных обменных форматах (STEP, DXF), которые физически являются текстом и худо-бедно поддаются просмотру различий. Для тяжёлых бинарных сборок и людей, для которых git — незнакомое слово, это будет лишним барьером, который команда обойдёт возвратом к папкам.

Разворачиваем версионирование на своём сервере: практика

Дальше — вариант с Nextcloud, как наиболее универсальный. Общий процесс с Seafile отличается в деталях, но идея та же: контейнер с приложением, база данных, диск под файлы.

Минимальный docker-compose.yml:

services:
  db:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_DB: nextcloud
      POSTGRES_USER: nextcloud
      POSTGRES_PASSWORD: замените-на-свой-пароль
    volumes:
      - ./db:/var/lib/postgresql/data

  nextcloud:
    image: nextcloud:apache
    restart: unless-stopped
    depends_on:
      - db
    ports:
      - "8080:80"
    environment:
      POSTGRES_DB: nextcloud
      POSTGRES_USER: nextcloud
      POSTGRES_PASSWORD: замените-на-свой-пароль
      POSTGRES_HOST: db
    volumes:
      - ./nextcloud:/var/www/html
      - ./drawings:/var/www/html/data

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

После первого запуска и создания администратора версионирование файлов в Nextcloud включено по умолчанию — это встроенное приложение files_versions. Проверить и настроить политику хранения версий можно через occ:

docker exec -u www-data nextcloud-nextcloud-1 php occ config:app:set files_versions expire_after_max_period --value=180
docker exec -u www-data nextcloud-nextcloud-1 php occ app:list | grep versions

Или через config.php внутри контейнера, директивой versions_retention_obligation, которая задаёт минимальный и максимальный срок хранения версий в днях — например, «не удалять младше недели, автоматически чистить старше полугода». Конкретные сроки задавайте исходя из объёма правок и свободного места на диске, единого правильного числа тут нет.

Дальше — доступ из привычного окна «Сохранить». Два практичных способа:

1. Синхронизирующий клиент (десктопное приложение Nextcloud) — папка на компьютере ведёт себя как обычная локальная папка, но фоново синхронизируется с сервером. CAD-программа сохраняет туда как в любую другую директорию.
2. Подключение как сетевой диск через WebDAV — если синхронизировать всё локально не хочется (большие сборки, ограниченное место на ноутбуке), сервер монтируется как буква диска, и файл сохраняется напрямую на сервер.

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

Структура папок и блокировка файлов поверх системы версий

Версионирование само по себе не отменяет необходимость в порядке — оно снимает панику «а вдруг я всё испорчу», но не заменяет договорённости в команде. Практика, которая реально работает:

• Один актуальный файл на деталь/сборку, без суффиксов «финал» в имени. Вся история — в версиях системы, а не в названии.
• Ревизионная буква или номер добавляется в имя только в момент официального выпуска чертежа (в производство, заказчику), а не при каждой промежуточной правке. Например, Корпус_Rev.C.dwg — это конкретный контролируемый релиз, а не рабочая версия среды.
• Статусные папки верхнего уровня, если нужен формальный процесс согласования: 01_в_работе, 02_на_согласовании, 03_выпущено. Файл физически переезжает между ними по мере готовности, история версий при этом сохраняется.
• Блокировка на время правки, чтобы не получить два расходящихся варианта одной сборки. В Nextcloud файловые блокировки поддерживаются на уровне WebDAV и приложения files_lock — при открытии файла через синхронизирующий клиент или подключённый диск он помечается занятым для остальных до сохранения и закрытия.

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

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

Версии — это не бэкап: как не обмануть себя

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

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

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

Частые вопросы