- Город
- Новосибирск
- Опыт работы
- 26 лет
- На сайте с
- 2013 года
- Юридический статус
- ИП
Задача. Заказчику требовалась собственная система управления проектами и задачами на своей инфраструктуре, без привязки к внешним SaaS. Проекты содержат задачи, задачи декомпозируются на подзадачи, по ним считается процент выполнения. Отдельным требованием шло быстрое развёртывание: система должна разворачиваться на чистом сервере под новую площадку без ручной настройки.
Функциональность. Проекты и участники, задачи с подзадачами и исполнителями, учёт выполненного объёма и процент готовности, комментарии, вложение файлов к задачам и комментариям, чаты, реакции, push-уведомления, публичные проекты (доступны на просмотр без авторизации), поддержка и категории.
Архитектура: тонкий API, логика в базе. Сознательно выбранное разделение — API принимает запрос, валидирует его и передаёт в СУБД, обработка данных выполняется на уровне PostgreSQL.
API на Go в Docker-контейнере: маршрутизация, middleware, валидация, работа с файлами, интеграция с Firebase Cloud Messaging для push-уведомлений. Конфигурация через yml с приоритетом переменных окружения — один образ работает в любом окружении.
PostgreSQL: вся бизнес-логика в хранимых процедурах на PL/pgSQL, принимающих и возвращающих jsonb, с единым шаблоном обработки исключений и кодами ошибок. Объекты разбиты по схемам согласно бизнес-доменам (пользователи, задачи, системные данные), выполнение процедур выдаётся отдельному пользователю приложения через GRANT EXECUTE — API не имеет прямого доступа к таблицам.
Единый контракт API: любой ответ — объект {status, data, errors} с массивом ошибок и числовыми кодами, что упрощает разработку клиентов.
Единый сквозной идентификатор запроса, генерируемый на nginx и далее передаваемый до БД для фильтрации по логам.
Авторизация и права: вход по пин-коду, хранение только хэша токена сессии, дополнительный заслон от ботов на уровне Basic Auth. Ролевая модель — глобальные администраторы, право создания проектов, администраторы проектов, исполнители задач с ограниченными правами (свои комментарии и файлы, отметка выполненного объёма), режим просмотра для остальных участников.
Миграции с версионированием и историей накатов в отдельной схеме, деплой миграций отдельными джобами CI/CD, мультиязычные словари системных сообщений истории выкатываются собственным пайплайном.
Документация API в Swagger/OpenAPI генерируется из кода и актуализируется вместе с ним.
Веб-бэкофис. Приложение управления сервисом: Go-сервер в контейнере рендерит HTML-шаблоны, дальше браузер работает с данными через тот же публичный API — то есть админка использует ровно тот контракт, что и остальные клиенты. Статика отдаётся nginx мимо Go-сервера; при деплое JS-бандл минифицируется и склеивается. Вёрстка на базе шаблона AppStack.
Инфраструктура и развёртывание. Развёрнут self-hosted GitLab с собственным Docker-registry, вся выкладка идёт через GitLab CI/CD: компиляция бинарника, сборка образа, доставка конфигов из переменных окружения, обновление конфигурации nginx, деплой.
Поднятие нового окружения автоматизировано Ansible-плейбуками, встроенными в пайплайн — от чистого сервера до готовой площадки за несколько запусков джобов:
первичная настройка Ubuntu: создание служебного пользователя, генерация ssh-ключей, запрет root-логина и парольной аутентификации;
установка всего необходимого ПО;
установка и настройка nginx с выпуском сертификатов Let's Encrypt через certbot;
создание базы данных и раздельных пользователей ОС и Postgres под каждую роль — владелец схемы только для наката миграций, отдельный пользователь для API, отдельный для сервиса уведомлений; сгенерированные пароли и ключи возвращаются артефактами джоба.
Такое разделение прав означает, что компрометация одного компонента не даёт доступа к остальным.
Результат. Система работает на инфраструктуре заказчика: код и данные не покидают его контур, API открыт для разработки любых клиентов, обновления выкатываются по пушу. Один и тот же продукт развёрнут более чем на десяти изолированных окружениях — каждое поднимается из пайп
