Добрейшего.

Доогое время слежу за развитием open source проекта eTraxis, это система управления запросами на изменения. Большинству такие систенмы известны под именем «багтрекеры». Мне довелось написать для неё немного кода и поучаствовать в её внедрении для нужд большой команды (несколько десятков человек). Отличительная особенность его — большая гибкость в настройке шаблонов workflow, их полей, групп пользователей и прав доступа — вплоть до отдельного поля в произвольном состоянии.

В общем, проект мне интересен, слежу за его развитием. Ну а не так давно создатель системы решил выйти на новый уровень — и именно, создать онлайн-сервис (то, что сейчас принято называть SaaS). Сказано — сделано, был запущен https://www.etraxis.com/.

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

Учет задач мы ведем не в солидном таск-трекере, а в… текстовом файле. Точнее не просто текстовом, а в расшаренном документе Google Docs. Происходит это так:

• Записываем возникающие задачи обычным черным шрифтом в виде обычного ненумерованного списка.
• Размером шрифта отмечаем приоритет задач — чем крупнее, тем важнее.
• Цветом помечаем задачи, назначенные на конкретного человека — за каждым разработчиком закреплен свой цвет.

В начале файла обычно помещаем "легенду", чтобы всегда можно было вспомнить, где чей цвет. Вот как это выглядит:

Приветствую.

Некоторое время назад я участвовал в разработке open source проекта eTraxis — системы отслеживания ошибок, а точнее — системы отслеживания запросов на изменения. Если вдруг кто до сих пор не знает, что это за класс систем — читайте мою статью про системы отслеживания запросов на изменения из цикла материалов по Software Configuration Management.

Вместо предисловия

И снова доброго времени суток!

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

1. Цикл статей по основам Software Configuration Management. О том, что такое СМ, каковы его задачи и за что отвечает в рамках проекта CM-инженер.
2. Software Configuration Management // Конфигурации и baselines. О том, что такое рабочий продукт в терминах SCM, что такое конфигурация, как она стабилизируется, а так же что такое базовые конфигурации — baselines.

В этой заметке речь пойдет о том, что большинство называют bugtracking systems. Мы посмотрим на этот класс задач и инструментов с более обобщенной точки зрения.

Хочу представить свой перевод статьи «Your Code Sucks and I Hate You: The Social Dynamics of Code Reviews».

Я ненавижу тебя: твой код – хлам!
Взаимоотношения участников ревизий кода

Джонатан Лэндж (Jonathan Lange), 15.09.2008

Обзор

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

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

Сегодня с утра началась пятидневная программа по раздаче годовой подписки на JIRA или Confluence за $5 (на пять пользователей).

Да-да, Вы не ослышались, за пять долларов.

blogs.atlassian.com/rebelutionary/archives/2009/04/atlassian_stimulus_package_announced.html

Мы покупаем на три года подписку, благо, всего 15 долларов.

Недавно на работе был поднят такой вопрос: пора бы завести наконец-то систему баг-трекинга, но вот только какую? Условия были поставлены следующие: система должна быть open source, должна без проблем ставиться на не-виндовс системы, использовать в качестве БД MySQL и желательно быть написанной на PHP, на случай, если очень захочется доработать напильником.

Варианты предлагались такие: Jira (отпадает в виду небесплатности), BugZilla (отпала в виду того, что админ обвинил ее в требованиях «каких-то специфичных настроек MySQL-я»), Trac (в нем долго сомневались, т.к. у нас svn).

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

Итак: краткий обзор систем баг-трекинга.

1. BugZilla.

О ней, наверно, знают все, но на всякий случай кратко для тех, кто еще не знает.

Система от разработчиков FireFox, вообще ребята очень ответственно подходят к проблеме багов.

Установка: Гарантируется поддержка Linux или Solaris, для работы нужен Perl и одна из СУБД: MySQL, PostgerSQL, Oracle.

Список использующих BugZilla, впечатляющий: Mozilla Foundation (ну это в общем-то не удивительно), Open Office, RedHat, NASA, Facebook и еще сотня довольно известных и тысячи неизвестных компаний.