WeKan для самостоятельной канбан-доски: импорт задач и выбор базы данных

README WeKan заявляет самостоятельное размещение, несколько вариантов баз данных и импорт из разных систем. Разбираем, что это говорит о выборе инструмента и что нужно проверить перед переносом задач.

WeKan для самостоятельной канбан-доски: импорт задач и выбор базы данных. Тематическая карточка Comrad404.

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

Самостоятельное размещение: что заявляет проект

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

GitHubRadar описывает WeKan как доску для личной и командной работы, упоминает обновление карточек, списков и колонок в реальном времени, а также импорт из Trello, Jira, Asana и Notion. Сообщение GitHubRadar — краткое описание проекта; README WeKan подробнее перечисляет варианты установки, базы данных и функции. Совпадение названий систем в сообщении и README подтверждает, что импорт заявлен, но не показывает, какие данные сохраняются при переносе.

Базы данных и варианты развёртывания

В README FerretDB v1 с SQLite назван вариантом по умолчанию для bundle, Docker, Snap и Kubernetes; документация уточняет, что для него не требуется отдельный сервер базы данных. Там же перечислены FerretDB v1 с PostgreSQL и MongoDB версий 6–9. Связки FerretDB с MySQL, MariaDB и SAP HANA документация помечает как экспериментальные. Для выбора стоит сверить этот список с инфраструктурой команды и её опытом администрирования, а не считать перечисленные конфигурации одинаковыми по готовности.

README утверждает, что перечисленные базы отвечают одинаково на каталог из 110 запросов соответствия; SAP HANA включается в эту проверку только по запросу. Это заявление проекта о проверке соответствия, а не независимое исследование производительности и не результат теста редакции. В документации также сказано, что MongoDB отказывается запускаться на Linux-ядрах от 6.19 до 7.0.13; по утверждению README, это ограничение не относится к FerretDB.

Импорт и экспорт: широкий список, но не гарантия миграции

README перечисляет форматы WeKan JSON и ZIP, CSV/TSV, Excel, Markdown, Obsidian Kanban, OPML, Org mode и todo.txt. Среди систем, названных документацией для импорта и экспорта, — Trello, Jira, Asana, Notion, Microsoft Planner, Linear, ClickUp и Redmine. Проект также заявляет импорт нескольких досок за один раз из отдельных файлов или ZIP-архива и возможность разделить экспорт приложения на доски по проектам.

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

Функции для командной работы

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

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

Практический вывод и ограничения

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

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