ЕМДЕВ

Спасибо за вопросы. Отвечаем:

1. Да. Для Entaxy ION есть готовый сценарий на Docker Compose: сборка и запуск выполняются из distribution/entaxy-docker командой docker compose up. Для быстрого локального старта можно также собрать образ и поднять один контейнер с пробросом портов 8101 и 8181. Это избавляет от ручной установки окружения; останется подключить тестовые системы и загрузить/настроить сам маршрут.

2. Готовый маршрут оформляется как приложение в Entaxy CI/CD: в исходной среде создаёте билд, экспортируете артефакт в репозиторий (например, Maven/Nexus), а на целевой среде импортируете и разворачиваете его. Конфигурации можно редактировать при переносе через UI, поэтому URL, учётные данные и параметры тестового/промышленного контура не нужно «зашивать» в маршрут.

Спасибо за точное замечание. Действительно, собрать модель данных и интерфейс - это одно, а перенос данных, проверка их качества и закрепление владельца решения требуют отдельного планирования. При этом мы особое внимание уделяем автоматизации миграции - например мы ранее представляли наш механизм синхронизации с Sharepoint на переходной период https://incomand.ru/ru/b/sharepoint_incomand_sync

По производительности также уточним важный момент. В Инкоманд работа с объектами (списками) - теми самыми кубиками - включая фильтрацию, сортировку, группировку и поиск, рассчитаны на работу с массивами в сотни тысяч записей. Для сравнения: в SharePoint действует порог обработки элементов списка всего лишь в 5 000 элементов.

При этом вы правы - если исходные системы содержат дубли, разнородные справочники, неконсистентные связи и файлы без понятной привязки к записям, миграция становится самостоятельной задачей внедрения. В таком случае до загрузки нужны аудит источников, правила сопоставления полей, дедупликация, очистка данных, пилотный перенос и сверка результата. Ни один конструктор не должен маскировать этот объём работ обещанием «перенести все за несколько минут».

Наконец, вопрос владельца приложения критичен. Для решений, собранных на Инкоманд, стоит сразу назначать бизнес‑владельца и администратора, описывать модель объектов, права, статусы, связи и автоматизации. Это не отменяет наглядности no-code‑настройки, но делает приложение поддерживаемым, когда его автор меняет роль, уходит в отпуск или покидает компанию.

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

Спасибо за обратную связь! Журнал аудита включая историю изменений каждого поля очень не хватает табличным решениям😉

Вы можете выкачать схему приложения в локальный Git-репозиторий, редактировать ее в IDE, пушить в ветку и деплоить на стейджинг через ваш стандартный CI/CD (GitHub Actions / GitLab CI).

Не без этого :) Если процесс сложный, мы не запрещаем использовать JS-сниппеты. Но 80% рутинных задач закрываются UI-настройками. Git у нас есть на уровне версионирования структуры приложения, так что откатить накосяченный процесс можно в один клик на любой сохраненный снапшот.

Мы решаем это через автоматизации по смене статуса. При переходе в "Ожидание" пишется pause_start. При выходе — дельта плюсуется к total_paused_time. Формула SLA выглядит так: (NOW() - CreatedAt) - total_paused_time. Никакого сброса времени не происходит.

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

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

Да, именно. В нашем видео https://incomand.ru/ru/b/incomand_workgroup мы как раз показываем, как портал становится точкой сборки, т.е. проект виден целиком - люди, документы, события и решения.