Redmine для управления ИТ: практический опыт обширного внедрения opensource-системы

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

Что значит хаос в наших системах? Это значит, что от пользователей поступают неупорядоченные, не подлежащие аналитике и структурированию запросы, и отсутствует проектное управление, как таковое. Запросы зависают где-то в почте, в Word, в голове у аналитиков, программистов, руководителей отделов – в зависимости от того, какая структура используется в организации.

Свой хаос мы решили устранять с помощью программного продукта Redmine. Сразу оговорюсь, что про методологии мы говорить не будем. Будем говорить именно про возможности Redmine, про то, как мы применяем его у себя. У каждой компании есть свои нюансы, не равняйтесь на нас, не равняйтесь на других. Сделайте свой анализ, поступайте так, как считаете правильным и нужным именно для вас. Не бойтесь ошибок, ведь на ошибках мы учимся.

Из хаоса, который у нас был, мы стараемся двигаться к порядку. Сейчас мы на середине этого пути. Конечно, не все было и будет безоблачно и гладко, но мы очень стараемся.

Внутри своей компании мы выделили три основные проблемы:

  • Во-первых, нам нужна была система отслеживания ошибок, инцидентов и поступающих запросов, т.е. нам надо было автоматизировать Bug Tracker;
  • Во-вторых, мы хотели в какой-то мере выделить управление проектами. Не с полной отслеживаемой автоматизацией, которая подразумевает под собой применение методологий, а в той мере, как это необходимо было сделать на том этапе развития и с неким заделом на будущее. Далее вы увидите, каким образом мы используем для этого Redmine, и куда мы собираемся его развивать дальше;
  • В-третьих, мы выделили блок управления ИТ-услугами (ITSM) в отдельную систему, правда, тоже не в полном объеме. Наш отдел предоставляет разные ИТ-услуги, которыми также необходимо управлять.

Дополнительно мы выделили наши частные проблемы:

  • Это, повторюсь, разноплановые ИТ-службы, потому что программисты живут своей жизнью, системные администраторы своей, есть еще отдел интернет-маркетинга и другие;
  • У каждого своя структура и свои пожелания по управлению отделом. Во всех отделах разные методологии, подходы, руководители и психотипы – это накладывает свой отпечаток на выбор системы. Но двигаться надо всем одновременно, причем, достигая одной цели – определенного порядка в организации, доступности информации и прогнозируемости;
  • Кроме этого есть еще KPI, который у всех рассчитывается по разным показателям;
  • Чтобы развиваться дальше, нам нужен дополнительный анализ поступающей информации, того, что происходит в отделах и как это отражается на организации в целом;
  • Мы должны контролировать внутренние бюджеты, в рамки которых мы входим или, чаще всего, не входим. Их тоже надо как-то анализировать и ими управлять. Лучше все это делать в единой системе – в частности, это удобно для руководства.

Таким образом, мы выделили три системы, которые хотелось бы объединить в одну.

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

На слайде перечислены не все продукты, их гораздо больше, причем не только на российском рынке, но и на западном. Но для нас одним из требований был русскоязычный интерфейс, потому что этим продуктом будут пользоваться не только программисты и системные администраторы, которые более-менее понимают английский, но и рядовые пользователи.

Куда же пойти? Продуктов много. Требования к ним у различных отделов и управлений разные. Будем выбирать.

В результате анализа и выбора, а также с подачи Алексея Лустина, к нам пришел продукт Redmine, покрывающий собой определенную область. Давайте выясним, какую область он покрывает?

Он полностью покрывает Bug Tracker, который мы хотели запустить в компании. Это централизация поступления заявок от пользователей и заказчиков любого уровня. Это была самая основная болевая точка, которую необходимо было быстро автоматизировать. Я думаю, что эта проблема есть у всех, потому что, как я уже говорила, информация поступает неупорядоченно и оседает в разных местах – в почте, в Word, в Excel или в головах. Такая информация не подлежит анализу и получению выводов и итогов. В результате получается, что:

    • Информационная составляющая базы знаний, которую можно проанализировать и понять, что делать дальше, отсутствует. Это замедляет скорость реакции и влияет на бесперебойность и качество работы, от которых напрямую зависит прибыль;
    • Увеличивается время «погружения» новых сотрудников в работу с корпоративными системами;
    • Отказоустойчивость также у каждого своя – кто-то без работающей системы не может прожить и двух минут. Поэтому Bug Tracker играет большую роль, и на тот момент проблематика встала очень остро.

Управление проектами Redmine покрывает наполовину, потому что этот продукт не специализируется на управлении проектами, но там есть определенный блок, который в этом помогает. К сожалению, это не идеальный продукт, но на тот момент он покрыл те требования, которые мы выставляли к системе.

И покрывается совсем небольшой блок ITSM. Система Redmine не предназначается для управления ИТ-услугами, поэтому там есть некоторые огрехи в ведении и структурировании данных. Мы вышли и из этой ситуации, выбрав свой вариант системы для ITSM.

Итак, наш выбор – это Redmine. Он довольно кастомизируемый, масштабируемый, гибкий и с удобными настройками.

Почему Redmine?

  • Это сладкое слово «халява». Redmine бесплатен, правда, с оговоркой, что к нему есть платные плагины, которые вы сами для себя выбираете. В любом случае у вас появляется какое-то прогнозирование затрат, потому что если вы купили плагин и не меняете платформу Redmine, то какое-то время этим плагином можно пользоваться без дополнительных вложений. А если вам, например, нужно его обновить, то вы платите за это обновление и используете его дальше. Обновление платформы Redmine происходит раз или два в год, а обновляться или нет – это уже по вашему желанию.
  • У Redmine интуитивно понятный интерфейс. Мы у себя внедрили Redmine не только как продукт для управления ИТ, но и как продукт, куда поступают заявки от пользователей для различных отделов. Например, выделена отдельная ветка для заявок административно-хозяйственного отдела.
  • Есть возможность управления приоритетами в различных аналитических формах, в том числе и индивидуально по задачам.
  • Управление временем и ресурсами. Я думаю, что это – основной блок для руководителя. Он позволяет понимать, насколько загружен его отдел, с какими задачами какие затраты связаны и как можно классифицировать затраты, но об этом ниже.
  • Аналитика и отчеты в Redmine выражены слабо, но есть обширный API. Можно взять данные из базы по API, выгрузить их в свою систему и получить любые отчеты.
  • Гибкие настройки, кастомизация и автоматизация ручных операций с помощью плагинов.
  • Интеграция с Git – это один из важных показателей. Хранилище нашей базы подключено к GitLab, и в любой задаче Redmine можно посмотреть логи (связанные редакции): кто, когда и что изменил по этой задаче, с переходом в GitLab.

Для информации: Git - это распределенная система управления версиями. Она отслеживает, фиксирует и хранит информацию (версии) об изменениях в любых файлах и каталогах, а также следит за целостностью данных. В нашем случае речь идет об исходном коде 1С.

Вот так выглядит список связанных редакций:

  • Управление задачами и отслеживанием ошибок. Это стандартный Bug Tracker, который мы будем использовать.
  • Управление инцидентами, проектами, бюджетами. У всех формирование бюджетов осуществляется по-своему. Я покажу, как мы автоматизировали это у себя, а вы можете потом попробовать автоматизировать управление бюджетом у себя – я думаю, это будет несложно, потому что трудозатраты в Redmine есть, и на деньги их переложить тоже можно.
  • Wiki в Redmine реализована не очень удачно, поэтому для цели создания базы знаний и совместной работы лучше использовать другой продукт. Для себя мы выбрали систему Confluence от компании Atlassian, которая является одной из самых распространенных и удобных в работе. Также можно рассмотреть системы: DokuWiki, MediaWiki и другие.

Что же у Redmine под капотом?

  • Redmine очень быстро и просто разворачивается.
  • Он работает на большинстве ОС.
  • Платформа, на которой он реализован – это Ruby on Rails. Если вы хотите кастомизировать Redmine под себя, нужно иметь компетенцию по Ruby on Rails, иначе будет не очень удобно, т.к. не все можно сделать готовыми плагинами.
  • Поддержка различных СУБД говорит сама за себя.
  • С помощью RSS или e-mail можно организовать оповещения по любым событиям.
  • Доступна аутентификация по AD.
  • Интеграция с системами управления версиями SCM (SVN, CVS, Git, Mercurial, Bazaar и Darcs).

Знакомство с Redmine

Вы можете скачать Redmine, установить его себе на компьютер и «поэкспериментировать». Или использовать облачный сервер, и «в один клик» поставить себе предустановленный вариант Redmine, который обычно входит в услугу хостинга.

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

Так выглядит список задач в Redmine.

Есть стандартный и несколько дополнительных интерфейсов. Правда, при смене интерфейсов некоторые функции могут перестать работать, т.к. кастомные интерфейсы не учитывают плагины, с которыми вы будете работать – все-таки это продукт Open Source. Но это не мешает ему быть удобным инструментом даже с использованием стандартного интерфейса.

Администрирование выделено в отдельную и довольно понятную структуру.

Список модулей, подключенных к вашему Redmine, вы всегда можете посмотреть и проанализировать в соответствующем разделе администрирования.

У нас не «чистый» Redmine, т.к. установлено около 35-ти плагинов. Несколько из них мы покупали.

Информацию по плагинам можно найти в поисковике по ключевым словам «плагины для Redmine». Для примера есть два сайта, на которых можно скачать или приобрести хорошие плагины для начала работы с Redmine:

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

Немного об автоматизации наших потребностей

Структура «Проектов»

Мы используем Redmine не по стандартному руководству. Как пример, в рамках системы понятие «Проект» – это отдельная ветка в иерархии структуры. Мы же используем дерево «Проектов» как классификацию уровней. На верхнем уровне находится отдел-исполнитель, ему подчиняются обслуживаемые департаменты, далее идут системы, подсистемы и сервисы.

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

В отделе системного администрирования также используется свой подход иерархии «Проектов». Работа выстроена на основе классификации предоставляемых сервисов – это помогло решить проблему с сервисным управлением. Поэтому в ветке ITSM иерархия «Проектов» – это каталог бизнес-сервисов. Для удобства они пронумерованы.

Поступление заявок в Redmine

На примере расскажу, как мы организовали поступление заявок в Redmine.

Наш отдел КИС делится на 3 группы:

  • Группа разработки;
  • Группа аналитики и сопровождения – сюда входят сотрудники, которые производят уровень поддержки «два с половиной». Они консультируют, анализируют проблему, в случае необходимости «читают» код, могут написать запросы для анализа данных, а также исправить ошибки в коде. В итоге нам удается исключить отвлечение программистов от мелких проблем, а также с помощью аналитиков мы отделяем программистов от заказчиков и обратно, т.к. все, наверное, сталкивались с проблемами взаимоотношений между ними.
  • И группа администраторов БД 1С.

Итак, поступление заявок в Redmine у нас осуществляется через написание обычного письма на выделенный почтовый ящик. Для организации отдельных почтовых ящиков мы в каждом отделе и в каждой группе выделили свою структуру «Проектов», например:

Для каждого из «Проектов» мы в плагине HelpDesk настроили свой почтовый ящик. На скриншоте показаны настройки плагина HelpDesk для одного из «Проектов»:

Письма, поступающие на привязанный к «Проекту» почтовый ящик, попадают в нашу систему в качестве заявок с видом трекера «Запрос пользователя». Все это приводит к уменьшению трудозатрат сотрудников на первичную классификацию поступающих запросов. (Пример на скриншоте: 1.2 Администраторы 1С, 1.4 Ticket Confluence, 1.5 Поддержка Юрайт-ДПП)

Если же такое выделение структуры произвести нельзя, тогда вполне возможно выделить один почтовый ящик, а в дереве создать подчиненные ветки, куда будет распределять заявки первая линия поддержки после первичной классификации (пример на скриншоте: 1.3 поддержка пользователей).

В итоге заявка проходит цикл:

  • Сначала происходит первичное автоматическое поступление в ветку проекта;
  • Потом аналитик распределяет заявку, т.е. классифицирует, категоризирует и приоритезирует ее;
  • После чего аналитик переносит заявку в нужную ветку.

В заявке есть определенные классификационные поля, часть из них преднастроенные, а часть добавлены нами. В соответствии с этим производится первичное необходимое заполнение с использованием параметров:

  • Приоритет;
  • Категория;
  • Департамент-заказчик;
  • Кастомные поля различных типов.

Т.е. при возникновении инцидента можно быть уверенным, что он не пройдет незамеченным.

Пример поступившей заявки и используемых полей:

Настройки «Проекта»

Внутри «Проекта» может вестись несколько видов трекеров. У нас, например, часто используемые трекеры:

  • Запрос пользователя;
  • Задача;
  • Ошибка;
  • Предложение;
  • Бизнес-проект;
  • Программа бизнес-проектов и др.

Трекеров может быть неограниченное количество – их можно добавлять вручную. Каждый трекер гибко настраивается.

В настройках «Проекта» мы можем указать, какие трекеры в нем применяются, а также какие кастомные поля можно подключить.

Также к каждой ветке индивидуально подключаются/отключаются необходимые модули и другие настройки. Это вы можете найти в стандартной документации по Redmine.

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

Кроме этого, в Redmine очень гибко настраиваются права доступа разного уровня как на «Проект», так и на отдельные связанные с ним функции, а также на доступность каждого поля.

На обзорной странице «Проекта» вы можете увидеть все виды трекеров и статистику по ним. А также, когда «проваливаетесь» в трекер, вы видите подчиненные этому «Проекту» Issues – назовем их «карточки».

Ведение бизнес-проектов

Немного повторюсь. Поскольку в понятиях Redmine «Проект» – это ветка дерева структуры, то для ведения реальных проектов мы выделили отдельную ветку с трекерами «Бизнес-проект» и «Программа бизнес-проектов». Это позволяет нам вести статус-отчеты по нашим бизнес-проектам и формировать затраты в разрезе баз распределения.

Структура этой ветки также поделена на подветки по специфике: отдел, заказчик, система, подсистема.

Т.к. наша компания управляющая, отделы централизованно сопровождают все компании, входящие в ГК WiseAdvice. В связи с этим мы ведем проекты как индивидуально для какой-либо компании, так и совместные для нескольких компаний. В итоге, по каждому проекту и задаче ведется свое бюджетирование и списание затрат отделов.

В карточке бизнес-проекта можно также настроить необходимые поля. Пример используемых нами полей:

  • База распределение/получатель затрат;
  • Бонус за проект;
  • Оценка трудозатрат;
  • Даты начала/завершения плановые;
  • День статус-отчета и другие.

Все задачи, которые созданы в рамках проекта, подчиняются основной карточке бизнес-проекта.

Статус-отчет сдается заказчикам не реже, чем раз в неделю. Вся история накапливается в карточке и направляется заинтересованным лицам.

Заказчик и другие стейкхолдеры могут в любое время посмотреть следующую информацию по бизнес-проекту:

  • Статус проекта;
  • Оцененные трудозатраты по проекту;
  • Фактические трудозатраты на текущий момент в разрезе процессов исполнения и сотрудников;
  • Готовность проекта;
  • Постановку бизнес-проекта;
  • Всю историю переписки;
  • Плановую дату начала проекта, если он был отложен в связи с приоритезацией;
  • Плановую дату завершения проекта.

Фактические трудозатраты собираются из подчиненных бизнес-проекту задач по времени, затраченному сотрудниками отделов.

На основании сформированных задач можно построить диаграмму Ганта, но только в информативном варианте. Дополнительно настраивать и интерактивно использовать ее нельзя.

При работе с графиком календарного планирования можно использовать графические отчеты. Например:

Мы используем доски задач, для распределения задач в рамках недельного планирования.

Все это реализуется посредством плагинов, которые включают в себя возможность ведения досок Agile или Kanban.

Как пример:

С учетом особенностей плагина получается похоже на канбан-доску. В ней можно интерактивно перекидывать тикеты –  как между статусами, так и между исполнителями. На трех интерфейсах проверяли – работает только на двух. На стандартном интерфейсе точно работает. Очень удобно выводить на большой телевизор/экран для проведения планерок/митингов.

Также планирование можно осуществлять с помощью версий и потом преобразовывать версии в выпуск релизов.

Как результативность работы отдела мы формируем отчеты в разрезе баз распределения затрат и фактических трудозатрат сотрудников отделов.

Стандартные отчеты по трудозатратам могут выводиться в разрезе:

Мы используем разрезы отчета по трудозатратам:

  • База распределения затрат - наше кастомное поле;
  • Получатель затрат - наше кастомное поле;
  • Пользователь - стандартное поле.

Формирование может происходить в разрезе периодов:

Для нашего бюджетирования мы используем только «Месяц». Пример отчета:

На скриншоте представлен пример с фактическими трудозатратами в разрезе баз распределения за август.

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

И, конечно, как истинные 1С-ники, мы можем написать выгрузку информации из Redmine в 1С, чтобы формировать свой отчет в 1С с нужными группировками и сведениями.

Пример одного из отчетов по затратам:

Еще немного о функциях Redmine

Из дополнительных полезных функций в Redmine хотелось бы выделить:

  • Режим аутентификации – либо по ad, либо по логину и паролю;

  • Система оповещений. Пользователю будут приходит уведомления об изменениях в задаче. Можно настроить оповещения по email и по RSS;

  • Объединение пользователей в группы. С помощью этого инструмента можно сформировать внутри Redmine иерархическую структуру предприятия. Существуют плагины по интеграции с учетной системой и клонированием ее структуры в группы;
  • Ролевая модель прав, с множественной разноуровневой настройкой;

  • Настройка Workflow (жизненного цикла) каждого трекера для каждой роли;

  • Наличие плагинов интеграции с MS Outlook. Например, довольно удобный плагин с множеством функций, таких как создание заявки в Redmine прямо из письма, комментирование, отслеживание и т.д.; Официальный сайт:

https://ru.ahausoftware.com/

  • Также существуют плагины для интеграции с системами мгновенного обмена сообщениями, такими как Telegram, и SMS-шлюзами. По любому каналу связи можно присылать оповещения, например по возникшим инцидентам, мониторинговые сведения и т.д.;
  • При наличии компетенции есть возможность просто самим сделать любые плагины.

Вопросы - ответы:

Вопрос из зала: Допустим, мы предоставили доступ заказчику, и у нас для него есть определенный перечень поддерживаемых услуг. Например, как в вашем примере – есть услуги сисадминов и услуги кодеров. С каким-то заказчиком мы работаем по обоим типам услуг, а с каким-то – только один тип. Можно ли на уровне прав ограничить, какой тип услуги доступен заказчику?

Ответ:Это варьируется только отдельной выделенной под заказчика веткой – «Проектом», где будут создаваться задачи по выбранным услугам индивидуально для этого заказчика. Или же придется предоставлять доступ ко всем задачам в ветке – «Проекте» поддержки данной услуги. Стандартной возможности ограничить права по признаку услуги и заказчику в «Проекте» в Redmine «из коробки» нет. Можно поискать такой плагин или написать его самому. У нас такой сложной структуры нет, но есть задачи, которые должны быть доступны только отдельным крупным подразделениям, поэтому для них созданы свои ветки.

Вопрос из зала: Получается, что каждый заказчик – это «Проект». А внутри одного «Проекта» можно подпроекты делать?

Ответ: Да, сколько угодно. Мы, например, даже выделяем подветки на отдельные департаменты заказчика, и даем туда доступы его ключевым сотрудникам, чтобы они не видели весь HelpDesk, связанный с заказчиком, и всю его структуру, т.к. она довольно большая. Redmine гибкий в настройках, но, к сожалению, и в его гибкости есть ограничения, которые доставляют некоторые неудобства. Конечно, есть и более удобные узкоспециализированные решения, но они платные.

Вопрос из зала: А проставленные на каждом статусе трудозатраты суммируются? Например, на статусе «В работе» я поставил трудозатраты 0.3, а потом на статусе «Анализ» я поставил еще какие-то трудозатраты.

Ответ: Трудозатраты идут в целом по задаче. Классифицировать трудозатраты по статусам невозможно, но у трудозатрат есть поле «Деятельность», суть которого может отражать процесс, по которому вы списываете время. Он также редактируемый. При списании трудозатрат сотрудник выбирает вид деятельности, которая фиксируется. Далее с помощью отчетов можно вывести время в разрезе процессов.

Без указания вида деятельности отчет можно будет сформировать только по общему времени в разрезе сотрудник + день.

Сводные аналитические данные можно посмотреть отчетами. Напрямую в задаче видны только затраты по текущей задаче.

Вопрос из зала: Получается, что у меня есть первая линия техподдержки и вторая линия техподдержки. Каждая из них затрачивает на одну и ту же задачу в одном и том же статусе «В работе» определенное время. Соответственно, как мне определить фактические трудозатраты на человека по задаче на первой линии, на второй линии, на третьей линии?

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

Вопрос из зала: Как организовано взаимодействие с пользователем? Через e-mail?

Ответ: Отправка идет на e-mail стандартным письмом – либо написанным пользователем, либо автоматической отбивкой Redmine, если он является наблюдателем по данной задаче. Также, если он является пользователем Redmine, то на верхней панели отображается, сколько ему задач назначено, сколько новых и сколько измененных. Я сейчас вижу, что на мне 20 задач, одна из которых новая и одна измененная. Со стороны пользователя – только e-mail.

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

Вопрос из зала: А веб-интерфейс для подачи заявок есть?

Ответ: Нет. Redmine работает на смартфонах и планшетах, т.е. имеет адаптированный интерфейс. Но заявки можно подавать либо через e-mail, либо дать доступ пользователю непосредственно в систему, ограничив его в правах только на создание. В качестве дополнительной возможности можно поставить плагин в Outlook на создание задач в Redmine.

На текущий момент существует плагин Tracker Hider, с помощью которого можно ограничить доступ к трекерам в разрезе пользователей или ролей.

Пример: Любому пользователю с ролью «Наблюдатель» в «Проекте» доступны только карточки с трекером «Запрос пользователя».

Вопрос из зала: А функциональность по работе с электронной почтой – это из коробки или из плагинов?

Ответ: Да, это есть «из коробки». С помощью плагинов она просто приобретает дополнительные удобства и настройки.

Вопрос из зала: А можно ли настроить, чтобы уведомление заказчику, которого мы пустили в систему, шло только на определенном статусе. Зачем ему смотреть наши внутренние десять этапов, если ему нужно, чтобы уведомление шло только тогда, когда задача выполнена?

Ответ: Мы решили эту ситуацию следующим образом.

1. Первым делом мы отключили для пользователей-заказчиков стандартные уведомления Redmine в настройках пользователей. Эта настройка глобальная для всего Redmine по текущему пользователю.

2. Далее, для необходимой ветки («Проекта») подключили возможность отправки писем.

3. Аналитик, либо РП-шник может отправить письмо, используя стандартный механизм: нажав признак «Отправить заметку» в режиме редактирования карточки. При необходимости можно указать дополнительных получателей.

4. Отправитель может написать любой текст и добавить необходимые вложения. Или же использовать ранее настроенные шаблоны.

 

Для этого выбирается готовый шаблон, подставляется в тело письма и остается только заполнить при необходимости дополнительные сведения.

После этого нужно нажать кнопку «Принять», тогда комментарий сохранится и письмо будет отправлено. Заказчик получит уведомление в виде обычного письма. 

Это – стандартный механизм, мы ничего не трогали. Шаблоны для каждого проекта настраиваются индивидуальные. Это довольно значительное упрощение труда консультанта-аналитика, потому что каждый раз писать один и тот же текст – это трудоемко.

Скрыть какой-либо текст от заказчика, при наличии доступа у него непосредственно к карточкам задач, возможно только через использование «приватного» комментария или путем отключения доступа к такому виду комментариев.

Второй вариант – использовать дополнительный плагин, т.к. по умолчанию такой настройки  нет.

Вопрос из зала: А возможна ли привязка контрагента к поступившей задаче? Например, у меня идет телефонный звонок с АТС, куда забит номер контрагента, и Redmine берет поступивший номер из АТС, создает задачу и подвязывает ее к контрагенту. Решили ли вы задачу иерархии контрагентов?

Ответ: Нет, мы не интегрировали Redmine с IP-телефонией, это не было нашей целью. Идея хорошая, но в нашей специфике она не нужна. На просторах интернета можно найти интеграцию Redmine с Asterisk.

Вопрос из зала: У нас вопрос не по IP-телефонии, а по иерархии контрагентов. У нас менеджеры хотят видеть в Redmine такую же иерархию контрагентов, как в 1С.

Ответ: Нет, структура контактов плоская. Единственное, что мы добавили – это ссылку на департамент. Максимум, что мы используем – это собираем контакты по департаментам, мы же делаем Bug Tracker для внутреннего обслуживания, а не для внешних клиентов. В самом Redmine нельзя организовать иерархию по контрагентам, но вы можете связать подразделения в Redmine и 1С, и формировать этот отчет из 1С.

Вопрос из зала: А где здесь задается глубина Scrum’а? У нас условно спринт – 7 календарных дней (5 рабочих дней). Где я могу видеть, какая это итерация спринта? Какая это календарная неделя, какой это номер спринта?

Ответ: Глубину Scrum’а можно контролировать версиями. Здесь есть функция формирования версий.

Для этого есть специальный раздел «Оперативный план» (или «Версии» в зависимости от интерфейса).

У меня для примера создано три версии.

 

Каждая версия может иметь свое наименование, статус и ограничиваться датой завершения.

По каждой версии видны списки задач при их наличии, а также количество незавершенных.

Для визуализации можно сформировать диаграммы

По версиям можно группировать, разбивать задачи, по ним можно строить доски. Можно переносить задачи между спринтами – такая возможность есть в отчете «Планирование версий».

Фактически, Redmine может быть инструментом для организации работы по скраму или канбану. Однако надо учесть, что иногда для удобства не хватает каких-то сортировок и других мелочей. Возможно, есть плагины, которые это поддерживают. В необходимом нам объеме текущей функциональности хватает. Здесь можно делать назначение задач, перемещение между спринтами, видеть, что не успели сделать за плановое время и т.д.

Вопрос из зала: Каким образом мы учитываем задачи, которые в текущем спринте были не выполнены? Я должен это видеть по статусу? Или они каким-то автоматическим образом у меня высветится, что их теперь нужно на новую версию забронировать?

Ответ: Можно отобрать задачи по версии. Например, посмотреть в «Оперативном плане», на сколько процентов он выполнен и насколько не выполнен. Т.е., сколько закрыто задач из спринта и сколько еще не закрыто – здесь будет написано. При нажатии на соответствующий пункт откроется список задач, которые не закрылись. Далее, как я уже говорила, их можно проанализировать и перенести на другой спринт.

Также можно формировать доски с задачами, по тем же самым версиям и в разрезе статусов.

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

Вопрос из зала: Как можно перенести задачу на другой спринт – я должен открыть список задач на одной вкладке, канбан-доску на другой и перекинуть?

Ответ: Можно и так. Но удобнее воспользоваться инструментом «Планирование версий». Выбираем из списка неназначенных задач или незавершенных задач конкретной версии нужную задачу и перекидываем ее в следующую версию мышкой – показываем, что мы эту задачу берем в спринт.

Вопрос из зала: А каким образом можно суммарно увидеть все незакрытые задачи? Может быть, три-четыре версии назад у меня там была какая-то не особо важная задача. Я ее записал, она там висит. Как мне ее не потерять, чтобы она у меня постоянно висела? Насколько я понял, сейчас вы здесь видите только нераспределенные задачи или задачи из выбранного спринта. А как увидеть все незакрытые задачи с накопительным итогом, чтобы понять, брать их в текущий спринт или не брать?

Ответ: Это можно реализовать с помощью фильтрации в задачах. Можно сделать настройки отборов в статусе «открыто» с необходимыми параметрами и сохранить.

 

Для примера можем рассмотреть настройку, которая называется «Задачи для закрытия». Сюда попадают задачи со статусом «Решена», которые были реализованы нашим отделом и переданы заказчику в производственную эксплуатацию, но обратной связи от заказчика еще не поступило. Т.е. это пул задач, которые необходимо проверить, уточнить результаты производственной эксплуатации и закрыть. Например, можно изменить в фильтре для статуса значение «соответствует» и признак «Новая». В результате будут отображаться новые задачи, которые еще не взяты в работу. Можно варьировать статусами, приоритетами, категориями, любыми значениями как стандартных, так и настраиваемых полей.

Например, можно добавить для фильтра специальное пользовательское поле. Это удобный инструмент, очень простой. Для проекта, для задачи, для контакта.

Новое поле – указываем тип объекта, куда добавляем, чаще всего используются «Задачи».

Указываем формат поля – варианты, которые есть, покрывают где-то 90% потребностей.

Указываем имя, каким ролям будет доступно.

Указываем, для каких проектов, для каких трекеров применяется.

Вопрос из зала: А настраиваемые поля можно сделать обязательными?

Ответ: Конечно, по аналогии с дополнительными реквизитами в 1С.

Обязательные поля отмечены красной звездочкой справа от наименования.

Вопрос из зала: А как у вас сделаны отчеты по выполненным работам? Там же задача уходит на другого пользователя – есть инициатор задачи и есть исполнитель.

Ответ: Правильно, если меняется поле – кому назначено, то в отчете он возвращает конечное значение.

Давайте я расскажу, как у нас все это устроено. Частично повторюсь.

  • Самый главный трекер для Service Desk – это «Запрос пользователя», при котором почта разбирается автоматически и письма превращаются в «Запросы пользователей». Если пользователь направил ответное письмо на уведомление из Redmine или направил уточняющее письмо с такой же темой, то он по теме или ID в теме автоматически прикрепляет текст из такого письма в существующий запрос  – используется классическая функция склейки.
  • Далее – когда, например, пришел запрос на консультирование в отдел КИС, консультанты-аналитики разбирают заявку и производят ее первичную классификацию. Определяют, что это – инцидент, ошибка или задача. Бывает даже – идея на новый проект. Соответственно, это тоже часть Service Desk. После классификации все «Запросы пользователей» распределяются по подпроектам ветки iTask, где с ними уже производится дальнейшая работа.
  • Если эта работа вырождается в задачу для разработчика, то на основании запроса пользователя создается связанная подчиненная «Задача». То есть, трекер «Запрос пользователя» живет сам по себе, а трекер «Задача» также отдельно. Это мы говорим о мелких доработках и исправлениях ошибок, которые у нас идут отдельным потоком – они появляются из «Запросов пользователя».
  • Если задача касается конкретного бизнес-проекта и разработчик сделал ее не на основе «Запроса пользователя», она привязывается к подчиненным бизнес-проекту блокам функциональности КИСа, чтобы потом по задаче можно было увидеть – по какому блоку и в связи с чем мы ее делали – был это «Запрос пользователя» или бизнес-проект.
  • Отдельно живет трекер «Бизнес-проект», с помощью которого мы коммуницируем с бизнесом – не с пользователями по запросам и мелким доработкам, а уже с реальными проектами, которые несут бизнес-ценность. В «Бизнес-проекте» в качестве подчиненных задач также могут быть свои подзадачи и даже пачки задач – большие, с подчинением и связями. Это такой мини-проджект. Все эти подзадачи мы опять же привязываем к блокам функциональности КИСа.
  • Неважно, откуда появилась задача – из сервис-деска или из бизнес-проекта. Но мы их всех привязываем к блокам функциональности.

Исходя из вышеперечисленного, повторюсь, мы можем увидеть трудозатраты  в разрезе:

  • Блоков функциональности КИСа;
  • Проектов;
  • Исполнителей;
  • Связи «Запрос – Задачи/Бизнес-Проект – Подчиненные трекеры».

На скриншоте представлен пример с фактическими трудозатратами в разрезе проектов за август месяц. Сотрудники должны распределять свое фактически отработанное время на задачи, которые они выполняли. Это называется Time Sheet. У нас разработчики ежедневно заходят в спецконтур «Рабочие отчеты» и распределяют свое время – формируется факт трудозатрат. Тем самым, мы хотя бы примерно, по факту управляем бюджетом проекта.

У наших проектов есть предварительный план трудозатрат. И в каждом проекте мы видим, превысили мы его или нет. Redmine автоматически суммирует списанные трудозатраты всех задач, подчиненных проекту. Соответственно, мы знаем, что на этот проект выделено 700 часов. Видим факт – уже отработано 617 часов. Это один из элементов проектного управления.

Процесс деятельности отдела КИС по инцидентам можно представить следующим образом:

  • Консультант-аналитик проводит анализ поступившего запроса, при необходимости формирует задачу на разработку;
  • Разработчик реализует задачу и возвращает ее консультанту-аналитику для проверки и дальнейшей коммуникации;
  • Консультант-аналитик уже коммуницирует по запросу пользователя с описанием результатов;
  • Если все в порядке, аналитик закрывает задачу – разработчику запрещено закрывать задачи.

По более крупным задачам, в т.ч. проектным, процесс выстроен более расширенно:

И, конечно, все изменения попадают в рабочую базу через выпуск релиза.

Если представить это в более удобном варианте, то у нас существует своя «Восьмерка».

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

Вопрос из зала: Есть ли возможность получить информацию о том, какие задачи выполнил конкретный разработчик?

Ответ: Есть. Существует инструмент «Рабочий отчет», по которому можно посмотреть какой сотрудник на какую задачу сколько времени и в какой день потратил.

Или это можно посмотреть стандартным отчетом «Трудозатраты» – его тоже можно формировать в разрезе пользователей с расшифровками.

Вопрос из зала: А как пользователю отслеживать свои трудозатраты?

Ответ: Свои трудозатраты сотрудник тоже контролирует через «Рабочий отчет». А фиксация трудозатрат в задаче производится вручную – либо непосредственно в задаче, либо в «Рабочем отчете». Есть плагины, позволяющие вести учет времени. Например, плагин Redmine Issue Timer выглядит следующим образом:

При начале работы над задачей сотрудник нажимает кнопку «Play», а при завершении – кнопку «Pause». При сохранении задачи трудозатраты в ней фиксируются.

Вопрос из зала: Вопрос касаемо управления временем и ресурсами – это  управление постфактум, регистрация уже реально произошедших работ, когда я смотрю, как мои сотрудники были загружены, или есть возможность планирования? Когда я смотрю, что завтра у меня программист должен взять задачу вот эту, а послезавтра вот эту. И я понимаю, что, условно говоря, это – мощный программист, и он может какие-нибудь отчеты без проблем по два, по три в день клепать, и я могу на неделю ему поставить очередь задач.

Ответ: Возможность планировать есть, но она не идеальная – бесплатный продукт вносит свои нюансы. Есть поле «Плановое время», есть возможность задать свое кастомное поле, если вам не хватает стандартного поля по плановому времени – сколько часов/минут он затратит. Есть возможность указать плановое время и потом сравнить плановое и фактическое время. И, конечно, можно использовать стандартное поле Story Points для покер-планирования.

Вопрос из зала: Вы говорили, что Wiki в Redmine неудобный.

Ответ: Wiki в Redmine выглядит недружелюбно.

 

Для форматирования статей и задач используется язык разметки Markdown. Форматирование происходит не «на лету», а с указанием символов разметки.

Поиск есть – по слову внутри текста и по заголовкам. Если ввести в поиск «exchange» – он выдаст и темы, и трекеры. Присутствует отбор по виду трекера.

Оглавление не является основной страницей и при входе в Wiki выводится просто список созданных статей.

Оглавление выглядит следующим образом:

И, конечно, Wiki в Redmine предназначено только для хранения статей. Ее нельзя использовать для совместной работы.

История изменения статей ведется и можно посмотреть когда, кто и какие изменение произвел.

Вопрос из зала: Каким образом происходит наполнение Wiki?

Ответ: У нас процесс построен следующим образом. Производится анализ Service Desk с определенной периодичностью за прошедший период. С помощью первоначальной классификации, которая была произведена аналитиками при поступлении запроса, мы пытаемся обобщить тематики и выявить наиболее проблемные зоны. Дальше – внедряем самообслуживание, т.е. документирование того, каким образом пользователь сам может решить свою проблему или возникший вопрос. Помимо этого, во время текущей работы, аналитик может создавать статьи по своему усмотрению, при возникновении потребности, не дожидаясь общего анализа. Также подготовка wiki-инструкции проходит в рамках разработанных бизнес-проектов или специально выделенных проектов по документированию. Это не Confluence, не Collaboration. Это сверху вниз административными методами. Пользователи в этом не участвуют.

Вопрос из зала: У одного из коллег применяется очень интересная система. Мне очень понравилось, я хочу ее себе внедрить. Первая линия техподдержки всегда обязана закрыть задачу из Wiki. И если она не находит статью в Wiki, она обращается на вторую линию техподдержки. И уже вторая линия создает статью, которую обязательно нужно приаттачить к задаче.

Ответ: Мы тоже так стараемся, но мы действуем итерационно – сели, проанализировали, сделали ряд мероприятий. Но это занимает месяцы. Потом опять – сели, проанализировали, выделили необходимые блоки, сделали еще ряд мероприятий.

Вопрос из зала: Не очень понятно – как происходит интеграция Git с Redmine?

Ответ: При сохранении изменений в хранилище 1С (при коммите) в описании указывается номер задачи с тегом «#», например «#74516». Тем самым мы получаем сквозной учет – можем посмотреть, какой коммит в хранилище Git привязан к задаче. Нам было важно, что это – desktop-решение, чтобы мы могли удобно им управлять, и, в случае необходимости, перейти на другое решение, потому что все равно потребности растут, и не все потребности Redmine может покрыть. Поэтому я еще раз прошу – если вы будете выбирать продукт, сначала проанализируйте, что вы хотите автоматизировать и какие блоки «покрыть».

Вопрос из зала: А мобильное приложение у Redmine вы использовали?

Ответ: Мобильное приложение есть, но оно не совсем удобное. В нашей организации потребности в нем нет. Мы в основном работаем на стационарном компьютере или ноутбуке. Также можно воспользоваться плагинами с возможностями информирования – например, с помощью SMS либо по Telegram.

Вопрос из зала: Вы сказали, что выгружаете хранилище в Git, а что вы там в Git видите?

Ответ: В коммите Git есть ссылка на задачу. Из коммита мы открываем саму задачу. И из задачи мы тоже можем открыть связанный с ней коммит. К каждому проекту, не важно, какой он иерархии, можно подключить свое хранилище. Конечно, интеграция с Git администрируется не совсем через веб-интерфейс. Ручками туда все-таки приходится залезть, но быстро и просто.

Что мы имеем в итоге:

Исходя из всего вышеописанного, подведем краткие итоги.

Плюсы:

  • Redmine – OpenSource-продукт с большим и активным сообществом;
  • Он прогнозируемый по затратам, недорогой, гибкий, кастомизируемый, легко интегрируемый и масштабируемый;
  • Полностью покрывает Bug Tracker, наполовину – управление проектами, совсем немного – ITSM;
  • Имеет интеграцию с Git;
  • Кастомизируется «на лету»;
  • Имеет довольно широкий спектр плагинов. Кроме того, несложно найти специалистов для автоматизации своих процессов;
  • Удобный учет фактических трудозатрат. Возможность планирования трудозатрат и бюджетов.

Минусы:

  • Неудобный Wiki;
  • При необходимости автоматизации своих процессов и при отсутствии компетенции по Ruby on Rails возможно только использование плагинов или поиск сторонних разработчиков;
  • Небольшое количество аналитических отчетов;
  • Не всегда «дружественный» интерфейс;
  • Неудобные массовые классификаторы, которые хотелось бы хранить в виде иерархии.

В процессе использования продукта Redmine мы проделали большой объем работы по анализу, систематизации и автоматизации нашей деятельности и уменьшению хаоса в наших структурах. Произвели изменение и оптимизацию процессов как внутри отделов, так и в бизнес-процессах всей организации.  Оптимизированы и улучшены контрольные, аналитические и управленческие функции в работе отделов и по проектной деятельности.

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

В части Redmine будут дополнительные шаги по выстраиванию более четких и контролируемых бизнес-процессов.

В общем, выбирайте инструмент, и пусть ваш хаос не останется незамеченным.

****************

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2017 COMMUNITY. Больше статей можно прочитать здесь.

В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.

Выбрать мероприятие.

Redmine — открытое серверное веб-приложение для управления проектами и задачами (в том числе для отслеживания ошибок). Redmine написан на Ruby и представляет собой приложение на основе широко известного веб-фреймворка Ruby on Rails. Распространяется согласно GNU General Public License.

Функциональные возможности

Данный продукт предоставляет следующие возможности:

  • ведение нескольких проектов;
  • гибкая система доступа, основанная на ролях;
  • система отслеживания ошибок;
  • диаграммы Ганта и календарь;
  • ведение новостей проекта, документов и управление файлами;
  • оповещение об изменениях с помощью RSS-потоков и электронной почты;
  • вики для каждого проекта;
  • форумы для каждого проекта;
  • учёт временных затрат;
  • настраиваемые произвольные поля для инцидентов, временных затрат, проектов и пользователей;
  • лёгкая интеграция с системами управления версиями (SVN, CVS, Git, Mercurial, Bazaar и Darcs);
  • создание записей об ошибках на основе полученных писем;
  • поддержка множественной аутентификации LDAP;
  • возможность самостоятельной регистрации новых пользователей;
  • многоязыковой интерфейс (в том числе русский);
  • поддержка СУБД MySQL, PostgreSQL, SQLite, Oracle.

Структура базы данных

Пользователи системы

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

Роли

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

Пользователям назначается роль в каждом проекте, в котором он участвует, например «менеджер в проекте по разработке сайта А», «разработчик в проекте по поддержанию интранета компании» или «клиент в проекте по рефакторингу информационной системы компании Б». Пользователь может иметь несколько ролей. Назначение роли для отдельной задачи (issue) в данный момент невозможно.

Проекты

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

Трекеры

Трекеры являются основной классификацией, по которой сортируются задачи в проекте. Само по себе понятие «трекер» восходит к системам учёта ошибок (англ. Bug tracking tool), представлявшим каждая в отдельности один проект.

По сути, в «Redmine» трекеры представляют собой аналог подклассов класса «Задача» и являются основой для полиморфизма разного рода задач, позволяя определять для каждого их типа различные поля. Примерами трекеров являются «Улучшение», «Ошибка», «Документирование», «Поддержка»,

Задачи

Задачи являются центральным понятием всей системы, описывающим некую задачу, которую необходимо выполнить. У каждой задачи в обязательном порядке есть описание и автор, в обязательном порядке задача привязана к трекеру.

Каждая задача имеет статус. Статусы представляют собой отдельную сущность с возможностью определения прав на назначение статуса для различных ролей (например, статус «отклонен» может присвоить только менеджер) или определение актуальности задачи (например, «открыт», «назначен» — актуальные, а «закрыт», «отклонен» — нет).

Для каждого проекта отдельно определяются набор этапов разработки и набор категорий задач. Среди других полей интересны также «оцененное время», служащее основой для построения управленческих диаграмм, а также поле выбора наблюдателей за задачей (см. «Получение уведомлений»). К задачам имеется возможность прикреплять файлы (имеется отдельная сущность «Приложение»).

Значения других перечислимых свойств (например, приоритетность) хранятся в отдельной общей таблице.

Отслеживание изменения статуса задач

За отслеживание изменений параметров задач пользователями в системе отвечают две сущности: «Запись журнала изменений» и «Измененный параметр». Запись журнала отображает одно действие пользователя по редактированию параметров задачи и/или добавление комментария к ней. То есть служит одновременно инструментом ведения истории задачи и инструментом ведения диалога.

Сущность «Измененный параметр» привязана к отдельной записи журнала и предназначена для хранения старого и нового значения измененного пользователем параметра.

Связи между задачами

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

Учет затраченного на проект времени

Система поддерживает учет затраченного времени благодаря сущности «Затраченное время», связанной с пользователями и задачей. Сущность позволяет хранить затраченное время, вид деятельности пользователя (разработка, проектирование, поддержка) и краткий комментарий к работе. Эти данные могут быть использованы, например, для анализа вклада каждого участника в проект или для оценки фактической трудоемкости и стоимости разработки

Привязка репозиториев

Redmine предоставляет возможность интеграции с различными системами контроля версий (репозиториями). Интеграция заключается в отслеживании изменений во внешнем репозитории, их фиксации в базе данных, анализе изменений с целью их привязки к определенным задачам. В инфологической структуре системы за интеграцию с внешними репозиториями отвечают три сущности: «Репозиторий», «Редакция» и «Изменение». «Репозиторий» представляет собой связанную с проектом сущность, хранящую тип подключенного репозитория, его местонахождение и идентификационные данные его пользователя.

«Редакция» является отображением редакции репозитория, и, кроме информационных полей, может быть привязана к конкретной задаче (для этого требуется указать в описании изменений «refs #NUM», где NUM — номер задачи), и к пользователю-автору редакции. Сущность «Изменение» предназначена для хранения списка измененных (добавленных, удаленных, перемещенных, модифицированных) файлов в каждой редакции.

Получение уведомлений

Уведомления пользователей об изменениях, происходящих на сайте, осуществляется с помощью сущности «Наблюдатели», связывающей пользователей с объектами различных классов (проекты, задачи, форумы и др.). В базе данных хранятся также ключи доступа к подписке RSS, позволяющие получать уведомления посредством этой технологии, также уведомления рассылаются с помощью электронной почты.

Некоторые недостатки Redmine

Ambox scales.svgПроверить нейтральность.

На странице обсуждения должны быть подробности.

  • Управление файлами и документами в Redmine сводится к их добавлению, удалению и редактированию. Правами доступа ни к файлам, ни к отдельным документам управлять нельзя.
  • Отсутствуют оповещения об изменении документов.
  • В Redmine нельзя управлять правами доступа на уровне отдельных полей задачи. Например, на данный момент от клиентов нельзя скрыть оценки времени работы над проектом или информацию о потраченном времени.
  • В Redmine все дополнительные поля доступны всем пользователям, все участники проекта смогут их видеть и изменять. Это ограничение может привести к сложностям при наличии неоднородной команды, когда доступ к проекту имеют и менеджеры, и разработчики, и клиенты.
  • В Redmine нет прав на отдельные типы переходов в workflow. Например, сейчас нельзя указать, что когда кто-то заканчивает исправлять ошибку, он должен выбрать ответственным тестировщика и должен указать номер билда. Также нельзя скрыть внутреннюю переписку между программистами от клиента.
  • В Redmine в список задач не выводится общая трудоемкость задач, а в отчетах по трудоемкости нельзя делать отборы, в том числе и по исполнителю.

ChiliProject

В результате того, что видение некоторых пользователей относительно проекта отличалось от видения лидера разработчиков, был создан форк Redmine под названием ChiliProject.

См. также

Литература

  • 前田剛 (Go Maeda) 入門Redmine Linux/Windows対応. — 秀和システム. — 226 с. — ISBN 978-4-7980-2137-9
  • Gunther Popp Konfigurationsmanagement mit Subversion, Maven und Redmine: Grundlagen für Softwarearchitekten und Entwickler. — 3. — Dpunkt.Verlag GmbH, 2009. — P. 362. — ISBN 9783898645218

Ссылки

Redmine [ɹɛdˈmɑɪn] — открытое серверное веб-приложение для управления проектами и задачами (в том числе для отслеживания ошибок). Redmine написан на Ruby и представляет собой приложение на основе широко известного веб-фреймворка Ruby on Rails. Распространяется согласно GNU General Public License.

Энциклопедичный YouTube

  • 1/4Просмотров:337

    1 067

    20 314

    1 108

  • How to Install Redmine (Project Management) on Antsle

  • Mit Redmine effizient Mitarbeiter, Projekte und Aufgaben verwalten

  • RedMine - Herramienta de Gestion de Proyectos

  • [ Kube 42 ] Deploying Redmine in Kubernetes Cluster

Содержание

Функциональные возможности

Данный продукт предоставляет следующие возможности:

  • ведение нескольких проектов;
  • гибкая система доступа, основанная на ролях;
  • система отслеживания ошибок;
  • диаграммы Ганта и календарь;
  • ведение новостей проекта, документов и управление файлами;
  • оповещение об изменениях с помощью RSS-потоков и электронной почты;
  • форумы для каждого проекта;
  • учёт временных затрат;
  • настраиваемые произвольные поля для инцидентов, временных затрат, проектов и пользователей;
  • лёгкая интеграция с системами управления версиями (SVN, CVS, Git, Mercurial, Bazaar и Darcs);
  • создание записей об ошибках на основе полученных писем;
  • поддержка множественной аутентификации LDAP;
  • возможность самостоятельной регистрации новых пользователей;
  • многоязычный интерфейс (в том числе русский);
  • поддержка СУБД MySQL, Microsoft SQL Server[2], PostgreSQL, SQLite.

Структура базы данных

Пользователи системы

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

Роли

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

Пользователям назначается роль в каждом проекте, в котором он участвует, например, «менеджер в проекте по разработке сайта А», «разработчик в проекте по поддержанию интранета компании» или «клиент в проекте по рефакторингу информационной системы компании Б». Пользователь может иметь несколько ролей. Назначение роли для отдельной задачи (issue) в данный момент невозможно.

Проекты

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

Трекеры

Трекеры являются основной классификацией, по которой сортируются задачи в проекте. Само по себе понятие «трекер» восходит к системам учёта ошибок (англ. Bug tracking tool), представлявшим каждая в отдельности один проект.

По сути, в «Redmine» трекеры представляют собой аналог подклассов класса «Задача» и являются основой для полиморфизма разного рода задач, позволяя определять для каждого их типа различные поля.Примерами трекеров являются «Улучшение», «Ошибка», «Документирование», «Поддержка».

Задачи

Задачи являются центральным понятием всей системы, описывающим некую задачу, которую необходимо выполнить. У каждой задачи в обязательном порядке есть описание и автор, в обязательном порядке задача привязана к трекеру.

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

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

Значения других перечислимых свойств (например, приоритетность) хранятся в отдельной общей таблице.

Отслеживание изменения параметров задач

За отслеживание изменений параметров задач пользователями в системе отвечают две сущности: «Запись журнала изменений» и «Изменённый параметр». Запись журнала отображает одно действие пользователя по редактированию параметров задачи и/или добавление комментария к ней. То есть служит одновременно инструментом ведения истории задачи и инструментом ведения диалога.

Сущность «Изменённый параметр» привязана к отдельной записи журнала и предназначена для хранения старого и нового значения изменённого пользователем параметра.

Связи между задачами

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

Учёт затраченного на проект времени

Система поддерживает учёт затраченного времени благодаря сущности «Затраченное время», связанной с пользователями и задачей. Сущность позволяет хранить затраченное время, вид деятельности пользователя (разработка, проектирование, поддержка) и краткий комментарий к работе. Эти данные могут быть использованы, например, для анализа вклада каждого участника в проект или для оценки фактической трудоёмкости и стоимости разработки.

Привязка репозиториев

Redmine предоставляет возможность интеграции с различными системами управления версиями (репозиториями). Интеграция заключается в отслеживании изменений во внешнем репозитории, их фиксации в базе данных, анализе изменений с целью их привязки к определённым задачам.

В инфологической структуре системы за интеграцию с внешними репозиториями отвечают три сущности: Репозиторий, Редакция и Изменение.

  • Репозиторий — связанная с проектом сущность, хранящая тип подключенного репозитория, его местонахождение и идентификационные данные его пользователя.
  • Редакция — отображение редакции репозитория, и, кроме информационных полей, может быть привязана к конкретной задаче: для этого требуется указать в описании изменений «refs #NUM», где NUM — номер задачи), и к пользователю-автору редакции.
  • Изменение — хранит список измененных (добавленных, удалённых, перемещенных, модифицированных) файлов в каждой редакции.

Получение уведомлений

Уведомления пользователей об изменениях, происходящих на сайте, осуществляется с помощью сущности «Наблюдатели», связывающей пользователей с объектами различных классов (проекты, задачи, форумы и др.).В базе данных хранятся также ключи доступа к подписке RSS, позволяющие получать уведомления посредством этой технологии, также уведомления рассылаются с помощью электронной почты.

Некоторые недостатки Redmine

  • Управление файлами и документами в Redmine сводится к их добавлению, удалению и редактированию. Правами доступа ни к файлам, ни к отдельным документам управлять нельзя.
  • В Redmine нельзя управлять правами доступа на уровне отдельных полей задачи. Например, на данный момент от клиентов нельзя скрыть оценки времени работы над задачей. Но можно сделать дополнительные поля видимыми только пользователям с определёнными ролями.
  • В Redmine в список задач не выводится общая трудоёмкость задач.
  • Нет возможности дать пользователю роль во всей системе; например, «Руководитель проектного офиса» должен иметь доступ ко всем проектам в системе: для этого нужно добавить пользователя с этой ролью во все проекты.
  • Подключить git репозиторий возможно только в случае, если и Redmine, и репозиторий находятся на одном сервере.

ChiliProject

В результате того, что видение некоторых пользователей относительно проекта отличалось от видения лидера разработчиков, был создан форк Redmine под названием ChiliProject. В настоящее время данный проект закрыт.

См. также

Примечания

Литература

  • 前田剛 (Go Maeda). 入門Redmine Linux/Windows対応. — 秀和システム. — 226 с. — ISBN 978-4-7980-2137-9.
  • Gunther Popp. Konfigurationsmanagement mit Subversion, Maven und Redmine: Grundlagen für Softwarearchitekten und Entwickler. — 3. — Dpunkt.Verlag GmbH, 2009. — P. 362. — ISBN 9783898645218.

Ссылки

  • Официальный сайт Redmine  (англ.)
  • Android клиент для Redmine  (англ.)
  • Установка и настройка связки REDMINE с GEM, RUBY, RAILS, POSTGRESQL, PASSENGER, NGINX
  • Установка и настройка связки REDMINE с GEM, RUBY, RAILS, MYSQL, PASSENGER, NGINX (недоступная ссылка)
  • Создание плагинов для Redmine
  • RedmineApp — iPhone-приложение для Redmine
  • Redmine PM — клиент Redmine для iPhone/iPad
  • Redmine To Go — Windows Phone клиент для Redmine
  • RedmineUP – Набор бесплатных и коммерческих плагинов и тем для Redmine.
  • RMClient – Клиент для Windows, Mac, Linux, коммерческий.
  • Настройка жизненного цикла задач
  • Решение проблем с производительностью
  • Оперативное планирование в Redmine
  • Руководство по написанию плагинов
  • Подробная инструкция по установке
  • Easy Redmine — коммерческий вариант
  • Конструктор Jetware инсталляторов и виртуальных машин с Redmine

Эта страница в последний раз была отредактирована 3 мая 2021 в 13:31.

  • - ведение нескольких проектов;
  • - система отслеживания ошибок;
  • - оповещение об изменениях посредством электронной почты и RSS-каналов;
  • - настраиваемые статусы задач;
  • - настраиваемые произвольные поля для задач, временных затрат, проектов и пользователей;
  • - учет временных затрат (часов);
  • - диаграммы Ганта и календарь;
  • - Wiki для каждого проекта;
  • - ведение новостей проекта, управление файлами и документами;
  • - форумы для каждого проекта;
  • - многоязыковой интерфейс, в том числе русский;
  • - легкая интеграция с репозиториями (SVN, CVS, Git, Mercurial, Bazaar и Darcs);
  • - система разделения доступа, основанная на ролях;
  • - поддержка множественной аутентификации LDAP;
  • - возможность самостоятельной регистрации новых пользователей;
  • - расширение функциональности системы посредством установки дополнительных плагинов;
  • - поддержка СУБД: MySQL, PostgreSQL, SQLite, MS SQL Server (с версии 2.3).
  • Рассмотрим систему Redmine более подробно. Ниже приведено несколько скриншотов, на первом из них - список задач по одному из проектов. Вкладка "Задачи" позволяет увидеть как текущие задачи проекта (по умолчанию), так и ранее закрытые задачи - возможна настройка пользовательских запросов (фильтров). Пользовательские запросы могут быть сохранены для последующего использования всеми пользователями системы (при установке флажка "Общедоступный" запрос) или для использования пользователем, создавшим запрос. После создания запроса можно настроить список задач в один клик, воспользовавшись ссылкой с названием запроса разделе "Сохраненные запросы" на боковой панели справа.

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

    Список задач проекта

    Все пользователи системы могут создавать новые задачи. Для того, чтобы добавить новую задачу в проект, необходимо перейти на вкладку "Новая задача", выбрать трекер задачи и заполнить обязательные (*) и дополнительные (в том числе и настраиваемые пользовательские) поля задачи. В поле "Тема" формулируется кратко, но информативно смысл задачи (при переходе к другому полю по нажатию клавиши "Tab" в случае установки дополнительного плагина может осуществляться поиск по вхождению темы среди ранее созданных задач). В поле "Описание" излагается подробное содержание задачи. Для повышения читабельности текста можно воспользоваться возможностями встроенного web-редактора. К задаче могут быть прикреплены файлы, максимальный размер которых регулируется администратором системы.

    К задаче можно подключить наблюдателей: по созданию задачи, при внесении зменений в задачу, изменения статуса задачи наблюдатели будут получать соответствующие уведомления на свой адрес электронной почты. Пользователи так же могут добавлять себя в качестве наблюдателя к доступной задаче, для чего в карточке задачи следует щелкнуть по ссылке "Следить".

    Создание новой задачи - карточка задачи

    Задачи в системе могут быть взаимосвязаны: например, одна из них является подзадачей для другой, предшествует ей или эти задачи просто связаны между собой. В системе Redmine предусмотрена отдельная сущность, которая называется "Связанные задачи". Связанные задачи могут иметь следующие виды связей:

    • - "Дублирует" - связывает задачи таким образом, что закрытие одной влечет закрытие другой задачи;
    • - "Связана с" - просто ссылка на другую задачу. Такая связь используется, чтобы продемонстрировать, что эти задачи объединены одной целью или другими общими атрибутами;
    • - "Блокирует" - показывает, что данная задача должна быть завершена перед началом работ над другой задачей. В обеих задачах можно независимо менять процент выполнения, даты, статус, но с одним исключением: заблокированную задачу нельзя закрыть, пока не закрыта блокирующая задача. Однако, в заблокированной задаче можно выставить статус "Выполнена", готовность 100%, даже если готовность блокирующей задачи оставляет желать лучшего;
    • - "Предшествует" - задает порядок выполнения задач так, что данная задача должна быть закончена за N дней до начала связанной. В карточке связанной задачи не только появится запись о привязке, но и автоматически изменятся сроки начала и окончания задачи. Срок начала задачи станет равным дате выполнения привязанной задачи, увеличенной на количество дней, указанной в связке;
    • - "Следующая" - задает порядок выполнения задач таким образом, что данная задача может быть выполнена только после выполнения связанной. Эта связь обратна предыдущей. Сроки автоматически изменятся не в привязываемой, а в редактируемой задаче. Поэтому связь "Следующая" нужно использовать, только убедившись в том, что задачи действительно должны идти одна за другой с заданным промежутком времени между ними.

    Нижеследующие рисунки посвящены вопросам настройки и администрирования системы Redmine. Трекеры играют важную роль в отслеживании задач. Они участвуют в определении условий перехода задач из одного состояния в другое, доступность полей. Трекер - это логическое объединение задач в одну группу в рамках проекта, например, устранение ошибки, разработка нового функционала и т.д. Трекер может быть включен в один, несколько или все проекты.

    Настройка трекера

    Пользователи системы Redmine должны быть включены в одну из ролевых групп, количество ролей не ограничивается. В системе предусмотрены две предопределенные роли: роль "Аноним" - для незарегистрированных в системе пользователей, роль "Не участник" - для зарегистрированных, но не включенных ни в один проект пользователей. Анонимы не могут создавать задачи.

    Настраиваемый список ролей системы Redmine

    Каждой роли устанавливаются права доступа на возможные действия с задачами, проектами, документами, файлами, wiki, форумами и т.д. Очевидно, что роли "Руководитель проекта" следует дать больше полномочий, роли "Исполнитель" - поменьше, роли "Не участник" - еще меньше, роли "Аноним" разрешить минимальные возможности в публичных проектах, а в отдельных проектах и вовсе всё запретить. Участники системной роли "Администратор" имеют неограниченные права в рамках всей системы.

    Настройка глобальных прав доступа для роли

    В зависимости от выбранного трекера каждая задача может проходить через определенные этапы и иметь разные статусы. Так, в примере ниже для созданных трекеров "Устранение ошибки", "Разовая задача, adHoc", "Новая разработка" максимально полный путь через статусы задач следующий: 1. Новая –> 2. Распределена –> 3. Анализ –> 4. В работе –> 5. Выполнена –> 6. Приемка Заказчиком –> 7. Закрыта Были созданы роли "Руководитель проекта", "Исполнитель", "Заказчик, участник". Поскольку руководитель проекта является администратором своего проекта, то в рамках своего проекта может перемещать задачу из - в разные статусы. Исполнитель задачи или Заказчик/участник могут переводить задачу только из - в определенные статусы. На любом этапе задача может быть аннулирована (переведена в статус «Отклонена») с указанием причины. При внесении изменений в задачу, изменения статуса задачи, добавления комментариев всем задействованным в задаче пользователям будет приходить автоматическое уведомление по электронной почте.

    Настройка статус-переходов для роли в указанном трекере

    Для каждой пары "Роль - Трекер" имеется возможность настроить видимость, обязательность заполнения полей (в том числе и настраиваемых полей) в карточке задачи. Системные поля "Проект", "Трекер", "Тема", "Приоритет", "Частная" (задача) обязательны для заполнения всегда. Настроив последовательность действий для одной из пар "Роль - Трекер", настройки последовательности можно скопировать для другой пары (ссылка "Копировать").

    Настройка прав на изменение полей для роли в указанном трекере

    В системе Redmine для задач, пользователей и других сущностей можно создать произвольное количество настраиваемых (пользовательских) полей. Пользовательские поля будут отображаться в карточке задачи в двух колонках после области предопределенных системных полей. Сортировка определяет порядок следования пользовательских полей в карточке задачи. Пользовательских поля поддерживают следующие типы данных: строка, длинный текст, целое число, вещественное число, дата, список для выбора единственного значения, список для выбора множественных значений, ссылка, пользователь.

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

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

    Создание настраиваемого (custom) поля для задачи

    Программу для управления серверами и службами Redmine можно найти как Пуск --> группа Bitnami Redmine Stack --> Redmine manager tool. С помощью этого административного приложения можно управлять службами Redmine, web-сервером Apache, сервером баз данных MySQL.

    Приложение для управления серверами и службами Redmine

    Отчетность

    В системе Redmine предусмотрена диаграмма Ганта, а с помощью дополнительных плагинов возможно формировать отчеты для понимания состояния дел по проектам и задачам. Возможно, частное представление разработчиков о форматах этих отчетов устроят Вас.

    И все же аналитические отчеты по проектным задачам лучше создать на основе экспортированных в csv-файл данных. Для этого в главном меню системы Redmine следует выбрать "Проекты" –> "Все проекты", перейти по ссылке "Просмотреть все задачи", к списку задач применить/отменить желаемые критерии фильтрации и щелкнуть по ссылке "Экспортировать в CSV" внизу справа под списком задач. Таким образом будет сформирована выгрузка списка задача - файл issues.csv.

    Далее необходимо открыть новую книгу MS Excel, в главном меню выбрать "Данные" –> "Из текста", указать путь к файлу issues.csv, в диалоговом окне выбрать формат кодовой страницы "1251: Кириллица (Windows)", (возможно, в качестве символа-разделителя отметить - "другой", указать символ | (вертикальная черта)) и нажать кнопку «Готово». Данные будут импортированы в файл Excel с сохранением подключения к csv-файлу. На базе таблицы исходных данных необходимо создать сводные таблицы, диаграммы (выделить таблицу/столбцы, затем в главном меню выбрать "Вставка" -> "Сводная таблица"). Возможно, для обеспечения аналитических показателей в базовой таблице потребуется создать дополнительные вычисляемые столбцы. Пример отчета можно посмотреть во вложении к настоящей статье.  

Redmine¶

Redmine is a flexible project management web application. Written using the Ruby on Rails framework, it is cross-platform and cross-database.

Redmine is open source and released under the terms of the GNU General Public License v2 (GPL).

Features¶

Some of the main features of Redmine are:

Read more about Redmine features.

Documentation¶

You can read the Redmine guide.

Other resources:

Online demo¶

A shared online demo can be found at http://demo.redmine.org/. It's been setup to give registered users the ability to create their own projects. This means once you register, you can create your own project on there and try out the project administration features.

Alternatively, you can get your own Redmine demo environment at http://m.redmine.org with full administrator privileges after filling a simple form.

Support & getting help¶

For getting help or discussing Redmine, you can browse the Redmine forums hosted right here in Redmine. We also have a chatroom - join #redmine on the freenode IRC network.There's also an unofficial workspace on Slack where you can ask questions and participate in discussions with other Redmine users.

Before submitting a bug report, a patch or a feature request here, please read the Submission guidelines.

Contributing and helping out¶

Redmine is built and maintained by community volunteers. If you enjoy using it and would like to give back to the community, the Contribute page has several ideas. Software development experience is not required. Check out the Teams Page if you are interested in a specific area to contribute regularly.

You can also make a donation and get listed on the Redmine Donors page.

Who uses Redmine?¶

This page lists some companies and projects using Redmine.

Redmine books¶

Mastering Redmine 2nd Edition is a comprehensive guide with tips, tricks and best practices for using Redmine.You can buy it online.Redmine Plugin Extension and Development provides an overview of the tools available to developers who want to extend Redmine to work their way.You can buy it online.Redmine Cookbook: over 80 hands-on recipes to improve your skills in project management, team management, process improvement, and Redmine administration.You can buy it online.

Дисклеймер: это не обычное руководство вида «Как установить Redmine». В нем я не буду погружаться в настройку базы данных или установку веб-сервера. Я также не буду рассказывать о настройке Redmine. Документация по Redmine в этом плане является достаточно полной. А для того, что не упоминается в официальной документации, есть общая процедура запуска Rails-приложений, которую можно легко найти в Интернете.

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

Готовы? Тогда начнём.

Отложите сборки типа «все-в-одном» и готовые к запуску виртуальные машины

Установочные пакеты Bitnami или предварительно установленные виртуальные машины хороши для быстрой пробы Redmine, но не подходят для продуктивного использования. Почему? Потому что у них нет обновления. Ой, секундочку, у Bitnami есть. Правда, оно больше похоже на шутку. «Установите новую версию всего стека в другой каталог и переместите туда свои данные» — это не обновление. Ни слова о настройке, кастомизации и плагинах, которые, вероятно, также нужно сохранить и переустановить. Желаю удачи с таким «обновлением».

Релизы патчей Redmine выходят один или два раза в месяц. Исправления ошибок, связанных с безопасностью, выпускаются по мере необходимости — вы же не хотите пропустить их?

Факт, о котором люди часто забывают: время обновления не всегда зависит от вас. Конечно, можно отложить обновление до выхода следующей младшей версии Redmine — на несколько недель (наверное, даже и на более длительный срок). Но вы же не хотите при обнаружении новых проблем безопасности в Redmine или Rails сидеть с непатченной системой, пока не получится освободить время для установки и настройки нового стека Bitnami и вручную переместить все данные?

Установка — это только верхушка айсберга. Обновление — вот что придется делать регулярно.

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

Ниже я расскажу, как просто поддерживать Redmine в актуальном состоянии.

Используйте Git

Даже если вы намереваетесь запустить стоковый Redmine без каких-либо настроек или плагинов, всё равно используйте репозиторий Git для хранения копии Redmine. По крайней мере, наличие специализированного репозитория даст вам место хранения всего необходимого для развертывания (позже это будет рассмотрено подробнее). Рано или поздно вы (или ваши пользователи) захотите установить какой-нибудь плагин или настраиваемую тему, и для этого уже будет готова инфраструктура. Эксперименты с изменениями и тестирование плагинов и тем в локальных ветвях без нарушений в производственном коде становятся очень простыми при наличии собственного репозитория git c Redmine. Так что сейчас мы начнем с настройки репозитория.

Хотя основной репозиторий Redmine является экземпляром Subversion, на Github есть полуофициальный репозиторий, который поддерживается основным коммиттером и постоянно обновляется. Используйте его для настройки собственного репозитория:

Настройка локального клона Redmine

$ git clone [email protected]:redmine/redmine.git$ cd redmine$ git remote rename origin upstream$ git remote add origin [email protected]:redmine.git$ git checkout -b redmine/3.2-stable upstream/3.2-stable$ git checkout -b local/3.2-stable$ git push --set-upstream origin local/3.2-stable

Измените номер версии 3.2-stable на номер последней стабильной версии Redmine.

Удаленный репозиторий [email protected] должен быть частным, так как в нем будет храниться конфигурация развертывания (а возможно, и прочая информация, публиковать которую не стоит). Поскольку описанный ниже процесс развертывания будет извлекать из этого репозитория код, то репозиторий должен быть доступен во время развертываний, поэтому не размещайте его на настольных компьютерах. Идеальной будет ситуация, когда репозиторий также будет доступен с веб-сервера, на котором происходит развертывание. Но это при необходимости можно обойти.

Теперь у вас есть две локальные ветви:redmine/3.2-stable, который отслеживает Redmine 3.2 без дополнительного функционала из репозитория github/redmine, представленная вышеуказанным удаленным восходящим репозиторием,local/3.2-stable, куда будут помещены все настройки развертывания, кастомизации, темы и плагины.

Пропатчите обновления версий

Redmine использует следующую схему нумерации версий: xyz Major/Minor/Patch. Каждая младшая версия имеет собственную стабильную ветку, в которой исправления и патчи безопасности будут применяться с течением времени (до тех пор, пока эта версия все еще поддерживается). В нашем случае это ветвь 3.2-stable.

Время от времени эта восходящая ветвь будет получать некоторые новые коммиты. Ваша задача — включить новые коммиты в локальную ветвь local/3.2-stable для развертывания.

Хотя возможно и просто регулярно дополнять восходящую ветвь, я предлагаю использовать git rebase для поддержки собственного набора изменений поверх стокового кода Redmine:

Перебазирование локальных изменений поверх «голого» Redmine:

$ git checkout redmine/3.2-stable$ git pull                          # new upstream commits coming in$ git checkout local/3.2-stable$ git rebase redmine/3.2-stable

Команда rebase:

  • Отменит все локальные изменения в local/3.2-stable.
  • Обновит local/3.2-stable, чтобы отразить изменения, произошедшие в redmine/3.2-stable.
  • Повторно применит все локальные изменения поверх «голой» версии.

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

Младшие и старшие обновления

Теперь, когда есть новая стабильная ветвь (скажем, 3.3-stable), делайте то же самое — перебазируйте ваши изменения поверх неё. Команды git будут немного отличаться из-за изменения восходящей ветви:

Перенос локальных изменений в новую стабильную ветвь

$ git fetch upstream$ git checkout -b redmine/3.3-stable upstream/3.3-stable$ git checkout -b local/3.3-stable local/3.2-stable$ git rebase --onto redmine/3.3-stable redmine/3.2-stable local/3.3-stable

Эти команды вначале создают две новые локальные ветви для версии 3.3: одну из восходящей, а другую — из локальной ветви 3.2. Затем они перебазируют локальные изменения поверх redmine/3.3-stable. Локальные изменения здесь — это разность между redmine/3.2-stable и local/3.3-stable (что по-прежнему является redmine/3.2-stable). Теперь local/3.3-stable содержит Redmine 3.3 плюс любые локальные изменения.

Для новой старшей версии требуется сделать то же самое.

Бог ты мой, у меня конфликты!

Рано или поздно (вероятно, уже во время первого обновления до новой младшей версии) вы столкнетесь с конфликтами слияния. Во время ребазирования Git применяет коммиты один за другим и останавливается каждый раз, когда применение коммита происходит с ошибками. В этом случае команда git status покажет проблемные файлы.

Проверьте, какой из коммитов дал сбой, узнайте, для чего он предназначался (хорошо помогут осмысленные сообщения коммитов), исправьте файлы, командой git add добавьте каждый исправленный файл, когда закончите. Если конфликты были устранены, можно просмотреть изменения, которые будут зафиксированы, с помощью команды git diff --cached. Как только вы сочтете результат удовлетворительным, можно продолжить ребазирование с помощью команды git rebase --continue.

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

Что дальше?

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

Ссылки

  1. Deploy and maintain Redmine the right way
  2. Развертывание Redmine с помощью Capistrano (вторая часть).
Redmine как управление проектом с открытым исходным кодом

Основные характеристики

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

Ключевая особенность

Если вы хорошо разбираетесь в языке программирования, на котором написано приложение, то тогда вы сможете вносить различные изменения, чтобы заставить программное обеспечение работать так, как вам это нужно. Это позволяет обеспечить высокий уровень настройки, а Redmine может быть разработан для конкретных и уникальных возможностей.

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

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

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

Добавить комментарий