Редмайн мосрег что это
Redmine
Redmine — открытое серверное веб-приложение для управления проектами и задачами (в том числе для отслеживания ошибок). Redmine написан на Ruby и представляет собой приложение на основе широко известного веб-фреймворка Ruby on Rails. Распространяется согласно GNU General Public License.
Содержание
Функциональные возможности
Данный продукт предоставляет следующие возможности:
Структура базы данных
Пользователи системы
Пользователи являются одним из центральных понятий предметной области. Модель пользователя является основой для идентификации и аутентификации работающего с системой персонала и клиентов, а также для авторизации их в разных ролях, проектах и т. п.
Роли пользователей определяются гибкой моделью определения прав доступа пользователей. Роли включают в себя набор привилегий, позволяющих разграничивать доступ к различным функциям системы.
Пользователям назначается роль в каждом проекте, в котором он участвует, например «менеджер в проекте по разработке сайта А», «разработчик в проекте по поддержанию интранета компании» или «клиент в проекте по рефакторингу информационной системы компании Б». Пользователь может иметь несколько ролей. Назначение роли для отдельной задачи (issue) в данный момент невозможно.
Проекты
Проект является одним из основных понятий в предметной области систем управления проектами. Благодаря этой сущности возможно организовать совместную работу и планирование нескольких проектов одновременно с разграничением доступа различным пользователям (см. выше). Проекты допускают иерархическую вложенность.
Трекеры
Трекеры являются основной классификацией, по которой сортируются задачи в проекте. Само по себе понятие «трекер» восходит к системам учёта ошибок (англ. Bug tracking tool ), представлявшим каждая в отдельности один проект.
По сути, в «Redmine» трекеры представляют собой аналог подклассов класса «Задача» и являются основой для полиморфизма разного рода задач, позволяя определять для каждого их типа различные поля. Примерами трекеров являются «Улучшение», «Ошибка», «Документирование», «Поддержка»,
Задачи
Задачи являются центральным понятием всей системы, описывающим некую задачу, которую необходимо выполнить. У каждой задачи в обязательном порядке есть описание и автор, в обязательном порядке задача привязана к трекеру.
Каждая задача имеет статус. Статусы представляют собой отдельную сущность с возможностью определения прав на назначение статуса для различных ролей (например, статус «отклонен» может присвоить только менеджер) или определение актуальности задачи (например, «открыт», «назначен» — актуальные, а «закрыт», «отклонен» — нет).
Для каждого проекта отдельно определяются набор этапов разработки и набор категорий задач. Среди других полей интересны также «оцененное время», служащее основой для построения управленческих диаграмм, а также поле выбора наблюдателей за задачей (см. «Получение уведомлений»). К задачам имеется возможность прикреплять файлы (имеется отдельная сущность «Приложение»).
Значения других перечислимых свойств (например, приоритетность) хранятся в отдельной общей таблице.
Отслеживание изменения статуса задач
За отслеживание изменений параметров задач пользователями в системе отвечают две сущности: «Запись журнала изменений» и «Измененный параметр». Запись журнала отображает одно действие пользователя по редактированию параметров задачи и/или добавление комментария к ней. То есть служит одновременно инструментом ведения истории задачи и инструментом ведения диалога.
Сущность «Измененный параметр» привязана к отдельной записи журнала и предназначена для хранения старого и нового значения измененного пользователем параметра.
Связи между задачами
Задачи могут быть взаимосвязаны: например, одна задача является подзадачей для другой или предшествовать ей. Эта информация может быть полезна в ходе планирования разработки программы, за её хранение в Redmine отвечает отдельная сущность.
Учет затраченного на проект времени
Система поддерживает учет затраченного времени благодаря сущности «Затраченное время», связанной с пользователями и задачей. Сущность позволяет хранить затраченное время, вид деятельности пользователя (разработка, проектирование, поддержка) и краткий комментарий к работе. Эти данные могут быть использованы, например, для анализа вклада каждого участника в проект или для оценки фактической трудоемкости и стоимости разработки
Привязка репозиториев
Redmine предоставляет возможность интеграции с различными системами контроля версий (репозиториями). Интеграция заключается в отслеживании изменений во внешнем репозитории, их фиксации в базе данных, анализе изменений с целью их привязки к определенным задачам. В инфологической структуре системы за интеграцию с внешними репозиториями отвечают три сущности: «Репозиторий», «Редакция» и «Изменение». «Репозиторий» представляет собой связанную с проектом сущность, хранящую тип подключенного репозитория, его местонахождение и идентификационные данные его пользователя.
«Редакция» является отображением редакции репозитория, и, кроме информационных полей, может быть привязана к конкретной задаче (для этого требуется указать в описании изменений «refs #NUM», где NUM — номер задачи), и к пользователю-автору редакции. Сущность «Изменение» предназначена для хранения списка измененных (добавленных, удаленных, перемещенных, модифицированных) файлов в каждой редакции.
Получение уведомлений
Уведомления пользователей об изменениях, происходящих на сайте, осуществляется с помощью сущности «Наблюдатели», связывающей пользователей с объектами различных классов (проекты, задачи, форумы и др.). В базе данных хранятся также ключи доступа к подписке RSS, позволяющие получать уведомления посредством этой технологии, также уведомления рассылаются с помощью электронной почты.
Некоторые недостатки Redmine
ChiliProject
В результате того, что видение некоторых пользователей относительно проекта отличалось от видения лидера разработчиков, был создан форк Redmine под названием ChiliProject.
См. также
Литература
Ссылки
FlexWiki • WWWiki • Perspective • ScrewTurn Wiki
Clearspace • Atlassian Confluence • JAMWiki • JSPWiki • Kerika • Mindquarry • SnipSnap • Traction TeamPage • XWiki
Kwiki • Noösphere • PodWiki • Socialtext • TWiki • Foswiki • UseModWiki • OddMuseWiki • WikiWikiWeb
CitiWiki • DokuWiki • GetWiki • MediaWiki • PhpWiki • PmWiki • PukiWiki • TigerWiki • TikiWiki • WackoWiki • Wiclear • WikkaWiki
MoinMoin • OghamWiki • PikiPiki • PikiePikie • TamTam • Trac • Zwiki
Instiki • Pimki • Redmine
Полезное
Смотреть что такое «Redmine» в других словарях:
Redmine — Startseite der Redmine Demo Basisdaten Maintainer Jean Philippe Lang Aktuelle Version 1.2.2 ( … Deutsch Wikipedia
RedMine — Aperçu du suivi des demandes dans RedMine … Wikipédia en Français
Redmine — Développeur Jean Philippe Lang Dernière version … Wikipédia en Français
RedMine (logiciel) — RedMine Redmine Développeur Jean Philippe Lang Dernière version … Wikipédia en Français
Comparison of issue-tracking systems — This article is a comparison of issue tracking systems which are notable, including bug tracking systems, help desk and service desk issue tracking systems, and asset management systems. The comparison includes client server application,… … Wikipedia
Gravatar — Logo de Gravatar URL www.gravatar.com Slogan A Globally Recognized Avatar … Wikipédia en Français
Bugzilla — Bugzilla … Википедия
Subversion — У этого термина существуют и другие значения, см. Subversion (игра). Subversion Логотип Subversion Тип централизованная … Википедия
Оперативное планирование в Redmine
В прошлой статье я рассказывал, как мы в Redmine настроили жизненный цикл задач для программистов, сейчас хочу рассказать о том, как мы планируем задачки в Redmine в разрезе месяца (про стратегическое планирование, наверное, напишу в отдельной статье).
Как мы планируем
Вкратце расскажу о процессе оперативного планирования, которое работает в нашем IT-отделе.
Любой сотрудник компании может написать заявку в ИТ-отдел на разработку какой-то функции в ПО или на другую работу (некоторые заявки требуют согласования руководителя, другие — нет).
Заявка попадает в тех. поддержку, которая затем спускает заявку на руководителя направления, ответственного за выполнение данного вида работ.
Руководитель направления, в том случае, если видит необходимость в выполнении данной работы, создает задачу на основе заявки и ставит ее в план на определенный месяц или в очередь (на потом), уведомляя заказчика, написавшего заявку, о смещении сроков.
Также, руководитель направления ставит задания на основе своего собственного виденья, наполняя план следующего месяца задачами, и распределяет задачи по исполнителям.
В последнюю пятницу месяца происходит нечто похожее на планирование спринта Scrum (я как-то переболел этой методологией). Принципиальная разница в том, что у нас много заказчиков присутствует на согласование плана, а в Scrum со стороны заказчика только Product owner.
На собрание по планированию приходит руководитель направления и ключевые заказчики (ключевые заказчики определяются приказом и привязываются к направлению разработки), так же на согласование планов могут прийти другие заказчики, заинтересованные в том, чтобы их задачи попали в обсуждаемый план.
На этом междусобойчике решается, какие задачи нужно выкинуть из составленного руководителем плана, а какие нужно включить. Руководитель корректирует план и утверждает его версию, согласованную ранее на собрании.
В процессе исполнения плана, руководителю могут прилетать срочные заявки, и он может включать их в текущий план на основе собственного виденья.
К этому процессу мы пришли опытным путем, не сразу, и он живет в компании, достаточно давно.
Что мы сделали в Redmine
Стандартный Redmine позволяет объединять задания в версии, проставлять сроки исполнения и оценочные часы. Наверное, на этом стандартные возможности планирования заканчиваются.
Кому-то может хватить этих возможностей, но нам не хватило: нет возможности распределять ресурсы, нет возможности контролировать отставания и еще много чего нет, как выяснилось в процессе внедрения.
В свободном доступе имеется ряд плагинов для более глубокого планирования. Большинство из них заточено под гибкие методологии разработки (Scrum, Kanban и т.д.). Но гибкие методологии не всегда подходят для большой компании. Тем более, у нас есть разные программистские отделы со своей спецификой, есть куча заказчиков и нет желающих становиться Product owner-ом, нужно было внедрять оперативное планирование и не в программистских отделах.
Мы пользовались около квартала плагином «Advanced roadmap», а затем мы стали делать свой и вот что сделали.
Постановка в план
Первое, что мы сделали — ввели понятие исполнителя (я немного рассказывал об этом в прошлой статье). Исполнитель — это тот на кого назначается задача однажды, и он отвечает за ее конечное исполнение. Поле «Назначено» сразу же переименовали в «На ком», в процессе исполнения задачки это поле может меняться несколько раз от автора до заказчика.
Для руководителей проектов сделали кнопку «Назначить», которая ставит задачу в план.
Ввели понятие самого плана, в который может входить несколько версий. Т.е. в плане октября, например, может быть две версии самой программы. При этом в сторонних не программистских отделах, для прозрачности работы с планом, сделали автоматическую привязку задачи к плану по дате завершения. А также, сделали автоматическое создание плана и версии, если их не существовало. Это сделало планирование более прозрачным для специалистов далеких от ИТ.
По исполнителю и по версии (с возможностью переключения в интерфейсе) стали формировать план. Последнюю, кстати, переименовали в этап. Это было понятнее пользователям.
Приоритезация
Довольно быстро возникла проблема приоритезации. У руководителей была необходимость показывать исполнителю в каком порядке необходимо выполнять задачки.
Стандартные текстовые приоритеты Redmine не очень подходили, поскольку не задавали четкой последовательности выполнения задач.
Еще в Redmine есть возможность связывать задачки в последовательные цепочки. Это тоже не подошло, так как смена приоритетов превращается в нетривиальную задачу. Действие иногда блокировались, и скрытое автоматическое изменение сроков во всей цепочке не всегда было к месту.
Сделали запись числового приоритета в настраиваемое поле, а изменение приоритета в плане реализовали с помощью обычного перетаскивания, как во всем плане, так и по конкретному исполнителю. Теперь, если ситуация изменилась, то в любой момент можно перестроить порядок исполнения. Строковые приоритеты, впрочем, оставили, чтобы визуально отражать важность задачек.
Распределение задач
Для того, чтобы эффективно распределять задачи по исполнителям, мы прикрутили несколько счетчиков, которые показывали насколько заполнен план по сотруднику, на сколько исполнитель его выполнил и т.д.
Если сотрудник участвовал в нескольких проектах, то просчитывать его загруженность по проектному плану было проблематично, поэтому мы сделали общий план по исполнителям, который показывал общую картину по исполнителям в разрезе месяца. В него собирались задачки из всех проектов, и он давал более полную картину по загруженности исполнителей.
Согласование плана
Поначалу, план согласовывался только на словах на собрании раз в месяц. Со временем у заказчиков стали возникать вопросы, почему согласованные задачи вылетели из плана и мы прикрутили функцию согласования плана в Redmine.
Теперь, руководитель просто нажимает ссылку «Согласовать план». После этого делается слепок плана и можно смотреть все изменения, которые с ним происходят: как меняется оценка часов, какие задачи вылетают из плана, а какие появляются в нем и даже то, как меняются заголовки задач. Это дает удивительную гибкость руководителю проекта, а контроль над планом остается высоким.
Где зависают задачки и почему
У нас есть как большие, так и маленькие отделы по разработке ПО. В больших отделах есть полный набор должностей, связанных с разработкой ПО: аналитики, программисты, тестировщики и руководитель. Бывало так, что аналитики писали требования «в ящик», а программисты не успевали писать код. Это не очень хорошо, чтобы контролировать такие ситуации мы придумали аналог Scrum-доски (мой руководитель называет ее WIP(Work in progress)-доской). Каждую колонку этой доски можно гибко настроить на основе стандартных запросов задач Redmine. Т.е можно сказать, что задачи этого запроса попадают вот в эту колонку, а запросы этого — в другую.
Доска помогает визуализировать то, на какой стадии жизненного цикла копятся задачи.
Иногда задачи копятся не на должностях, а на конкретных людях или в конкретных статусах. Поэтому мы сделали подробную статистику по тому, сколько времени проводили задачи в определенных статусах и на определенных людях. Этой статистикой удобно пользоваться для анализа жизненного цикла задач, например, или для оценки загруженности определенных людей. Статистика доступна как в рамках всего плана, так и в рамках конкретной задачи.
Система управления проектами Redmine + Mercurial на Ubuntu 16.04
По мере увеличения числа вовлечённых в проект людей возникает необходимость как-то более эффективно организовывать и управлять их деятельностью. На начальном этапе для этой цели использовались Google-таблицы, но их возможности ограничены, и появилось желание перейти на новый уровень. Изучение доступных систем управления проектами показало, что из систем с открытым кодом Redmine наиболее продвинутая и по некоторым показателям обгоняет даже проприетарные системы.
Redmine, действительно, обладает большими возможностями: управление несколькими проектами, отслеживание ошибок, интеграция с репозиториями, перекрёстные ссылки на исправленные баги в коммитах и на коммиты в баг-репортах, назначение разных ролей пользователей в каждом проекте и т.д. Однако процедура установки довольна сложна, а для некоторых очень полезных функций требуется небольшая доработка или использование плагинов. Надеюсь, что предлагаемое ниже руководство поможет желающим использовать Redmine в своих проектах.
Компоненты
Система управления проектами Redmine
Система контроля версий Mercurial
Кросс-платформенная распределённая система управления версиями.
Также понадобится
Web-сервер и система управления базами данных. Использованы Mysql и Apache.
Установка
Также использовалась официальная инструкция по установке
Redmine Installation Guide.
Предполагаем что у нас уже есть сервер с предустановленным на нём Ubuntu Server 16.04. Дальнейшие инструкции описывают установку системы управления и вспомогательного ПО.
Итак, начнём. Сначала устанавливаем LAMP server:
Во время установки понадобится ввести пароль root-пользователя базы данных MySQL (не путать с паролем root операционной системы).
Создаём базу данных MySQL и пользователя redmine для работы с ней. Вместо [password] вставляем желаемый пароль пользователя.
Распаковываем Redmine в каталог /usr/share/redmine. Находим подкаталог config и копируем config/database.yml.example в config/database.yml. После этого редактируем файл, для того чтобы установить «production» режим базы данных:
Вводим текст и сохраняем файл (ctrl+x):
Устанавливаем необходимые пакеты:
Теперь можно установить gems, необходимые для Redmine:
Создаём случайный ключ, который Rails будет использовать для шифрования данных в cookie:
Дальше создаём структуру базы данных (выполняем в /usr/share/redmine):
Устанавливаем необходимые права доступа:
При желании можно протестировать установку Redmine с помощью веб-сервера WEBrick:
После запуска WEBrick стартовая страница Redmine должна быть доступна в браузере по адресу http://localhost:3000/
Интеграция с Apache
Добавить символьную ссылку на public каталог Redmine:
Необходимо настроить пользователя Passenger по умолчанию, для этого редактируем файл:
Нужно добавить следующую строчку и сохранить (ctrl+x):
В итоге файл должен выглядеть так:
Далее создать конфигурационный файл redmine.conf для apache:
Добавить следующий текст и сохранить (ctrl+x):
Подключить модули Passenger и Rewite:
Отключить default вебсайт и подключить redmine:
Установить права доступа на /tmp/cache Redmine:
Установка Mercurial
Необходимо установить пакеты:
Создать директорию, в которой будут храниться репозитории проектов:
Теперь мы хотим сделать репозитории доступными по http протоколу. Для этого необходимо создать cgi-скрипт:
Добавить следующий текст и сохранить:
Теперь нужно создать файл hgweb.config:
Добавить следующее содержимое и сохранить:
Установить разрешения для файлов:
Теперь надо создать conf файл для Apache:
Добавить следующее содержимое и сохранить:
Ещё необходимо создать ссылки:
Включить CGI модуль и перезапустить Apache:
Чтобы клонировать репозиторий надо будет выполнить:
Если клонируемый проект не публичный (устанавливается в настройках проекта через веб-интерфейс системы Redmine), то потребуется ввести имя пользователя и пароль.
Авторизация осуществляется по проектам, т.е. доступ будет возможен только для участников проекта (менеджеры и разработчики).
При создании репозитория в веб-интерфейсе Redmine необходимо указать путь к нему, например /var/hg/projectname. Репозитории в /var/hg необходимо создать вручную для каждого проекта и инициализировать командой ( hg init ).
После создания нового репозитория надо убедиться, что у него установлены нужные права доступа:
В принципе, есть возможность автоматизировать создание репозиториев. Информация об этом есть в руководстве по ссылке HowTo Install Redmine 1.2.x with Mercurial and Subversion on Ubuntu Server 10.04
Уведомления о фиксации изменений по email
Redmine поддерживает уведомления о разных событиях (изменениях в жизни баг/фич и т.п.). Для того чтобы пользоваться этим функционалом достаточно настроить способ отправки email-сообщений. Делается это в файле /usr/share/redmine/config/configuration.yml В файле имеются шаблоны для разных конфигураций. Нужно разкомментировать и отредактировать нужный.
Обратите внимание, что каждая секция в файле configuration.yml сдвинута на два пробела. Это важно.
Базовые уведомления должны быть доступны после указания способа рассылки электронных писем. Однако для уведомлений об изменениях в репозитории необходимо использовать внешний плагин. Скачать его можно с сайта github.com/lpirl/redmine_diff_email.
Установим этот плагин. Для этого скопируем содержимое плагина в каталог /usr/share/redmine/plugins/redmine_diff_email. В соответствии с инструкцией по установке плагина изменяем файл /usr/share/redmine/app/views/repositories/_form.html.erb:
Оригинальный плагин работает с устаревшей версией redmine. Для redmine-3.3 нужно внести изменения в файл
/usr/share/redmine/plugins/redmine_diff_email/db/migrate/002_add_repositories_is_diff_email_attached.rb. Содержимое файла должно быть таким:
После этого в каталоге /usr/share/redmine выполнить команду для обновления базы данных:
Если плагин установлен правильно, то в списке плагинов Administration → Plugins появится Redmine Diff Email Plugin, а также в веб-интерфейсе Redmine SomeProject → «Settings» Tab → «Repositories» Tab → «Edit» появятся настройки уведомлений.
Кроме того, чтобы информация об изменениях в репозиториях автоматически отслеживалась Redmine, необходимо выполнить дополнительные действия. Сначала нужно включить WS для управления репозиториями и сгенерировать API key. Как это делается:
* В web-интерфейсе Redmine в меню Administration выбрать Settings
* Перейти на вкладку Repositories
* Включить ‘Enable WS for repository management’
* Кликнуть на ссылку ‘Generate a key’
* Сохранить изменения кнопкой ‘Save’
Далее создаём скрипт:
Добавляем следующий текст и сохраняем: (необходимо заменить [your API key] сгенерированным в API-ключом)
Устанавливаем права доступа для созданного файла:
Остаётся добавить в /var/hg/hgweb.config секцию [hooks], чтобы скрипт fetch_changes выполнялся после каждого коммита:
Теперь при изменениях в репозитории Redmine будет автоматически отсылать уведомления участникам проекта.
Установка Redmine за 15 минут (RVM + RoR + Unicorn + Nginx)
Эта статья является результатом работы по установке и автономизации работы сервера на базе ОС Linux с Redmine по различным источникам (в том числе и по официальной инструкции), часть команд и последовательность действий были взяты из других источников. Все используемые источники указаны в конце статьи.
Введение
В общем задача звучала так: установить Redmine на сервер, где веб-сервер на nginx.
Так как Redmine написан на RoR, то необходимо иметь RoR среду, но проблема в том, что разные RoR приложения могут требовать разные версии окружения. В моем случае необходимо было предусмотреть возможность установки RoR приложений с разным окружением, а значит нужен менеджер версий, который будет разворачивать нужную среду в нужном месте.
Также хотелось классический вариант веб-сервера на nginx. Однако, nginx не знает как исполнять приложение, и в данном случае выступает в качестве прокси на исполняющий веб-сервер RoR приложения.
Теперь задача становится более ясной: установить Redmine на сервер, развернув стек RoR+Unicorn+Nginx, с автоматическим запуском.
Подготовка
Отключение ipv6
Примечание: необязательно, написал потому что мне надо было решить проблему 🙂
Установив на VPS Ubuntu 16.04 при попытке apt-get install не мог получить данные по ipv6 :
Решение: отключить ipv6 добавив соответствующую информацию в /etc/sysctl.conf:
Установка общего софта
curl для установки RVM (Ruby Version Manager):
Примечание: остальное необязательно если читатель пользуется другим софтом для этих дел 🙂
Установка
Получение Redmine
На данный момент самая свежая стабильная версия Redmine 4.1.1. Заходим в директорию /opt/ скачиваем туда архив, распаковываем переименовываем в redmine и удаляем архив:
Теперь путь до Redmine: /opt/redmine/
PostgreSQL
Этот раздел нужен только если Вы выбрали в качестве СУБД PostgreSQL!
Проверим текущую версию пакета в репозитории:
Если все нормально двигаемся дальше, иначе ищем способ установить нужную версию пакета.
Теперь нужно зайти на сервер PostgreSQL (чтобы зайти надо сменить юзера терминала, потому что только юзер postgres может в psql), создать пользователя и базу данных:
Для выхода надо ввести \q
На работе уже использовалась СУБД PostgreSQL, в тоже место предполагалось ставить GitLab (он работает с PostgreSQL), поэтому здесь сделал так.
My SQL
Этот раздел нужен только если Вы выбрали в качестве СУБД MySQL!
Установка сервера MySQL:
Действия с MySQL = 8.0 для пользователя необходимо использовать старый метод аутентификации mysqlnativepassword (и вот еще ссылка):
У меня в одном проекте уже использовалась СУБД MySQL 8, поэтому решил поставить с использованием MySQL.
Сначала надо установить gnupg2 и установить проверочные ключи для установки RVM:
Теперь в директорию /opt/ надо скачать rvm скрипт:
Затем установка самого RVM (из директории /opt/ ):
Окружение Ruby On Rails для текущей сессии терминала можно установить так (а можно и по другому):
Вывод достаточно большой, но нас интересует именно это:
Создадим окружение для Redmine:
Теперь при входе в директорию /opt/redmine/ через терминал, для этой директории будет установлено окружение ruby-2.6.5@redmine :
Настройка и тестовый запуск Redmine
Настройка базы данных
Файл /opt/redmine/config/database.yml.sample является примером как должен выглядеть конфиг подключения к БД. Создадим конфиг:
Запишем в конфиг данные для работы с БД:
Сборка зависимостей и решение проблем
Теперь надо собрать все зависимости RoR приложения:
При сборке RoR приложения в разных условиях могут возникать разные проблемы.
Используя PostgreSQL в качестве СУБД команда bundle может закончится ошибкой связанной с модулем pg :
Решение нашел здесь, а именно:
Для MySQL тоже возникает проблема с модулем mysql2 (детали ошибки аналогичны как и для PostgreSQL). Решение нашлось здесь, а именно:
Еще была проблема с nokogiri, решение нашел здесь, а именно:
Не забываем опять запустить bundle
Инициализация БД
Теперь нужно сделать 5-ый, 6-ой и 7-ой шаги: сгенерировать случайный ключ для сессий, создать структуру БД и инициализировать данные в БД:
Тестовый запуск
Пробуем запустить Redmine на webrick:
Если запуск прошел успешно, то на 3000 порту можно посмотреть сайт ( localhost:3000 или ip:3000 ).
Unicorn
В /opt/redmine/GemFile запишем зависимость:
Создадим конфигурационный файл для unicorn:
И вставляем туда текст конфига:
Создаем директории в соответствии с конфигом и меняем владельца:
Теперь выполнив bundle (если нет ошибок), можно запускать unicorn (из директории /opt/redmine/ ):
Уничтожить процесс unicorn можно по pid файлу :
Nginx
Пишем в конфиг nginx (у меня путь /etc/nginx/nginx.conf ), в секцию http (при этом виртуальные хосты должны быть отключены):
Или вот полный конфиг (для доступа к Redmine по ip адресу):
Если nginx запустился без ошибок, то пробуем обратится на сайт по ip адресу (или по localhost ), Redmine должно работать.
Автозагрузка
Если перезагрузить сервер (или внезапно уничтожить Unicorn), то сам Unicorn автоматически не поднимется, надо это организовать.
Почитать о том, что происходит ниже можно здесь и здесь.
Идем в /etc/systemd/system/ и создаем файл redmine.service :
Создаем файлы скрипты в /opt/redmine/config/ меняем владельца и группу, и ставим права на запуск:
unicorn_stop для остановки сервиса:
unicorn_reload для перезапуска сервиса (останавливаем и запускаем):
Теперь просмотрев статус сервиса можно увидеть: