Bugzilla – Обзор

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

Он был написан Терри Вейсманом на языке программирования TCL в 1998 году.
Позже Bugzilla была написана на PERL и использует базу данных MYSQL.
Bugzilla можно использовать в качестве инструмента управления тестами, поскольку его можно легко связать с другими инструментами управления тест- кейсами, такими как Quality Center, ALM, Testlink и т. Д.
Bugzilla предоставляет мощное, простое в использовании решение проблем управления конфигурацией и репликации.
Это может значительно повысить производительность и подотчетность отдельного человека, предоставляя документированный рабочий процесс и положительные отзывы о хорошей производительности.

Он был написан Терри Вейсманом на языке программирования TCL в 1998 году.

Позже Bugzilla была написана на PERL и использует базу данных MYSQL.

Bugzilla можно использовать в качестве инструмента управления тестами, поскольку его можно легко связать с другими инструментами управления тест- кейсами, такими как Quality Center, ALM, Testlink и т. Д.

Bugzilla предоставляет мощное, простое в использовании решение проблем управления конфигурацией и репликации.

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

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

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

Bugzilla – Ключевые особенности

Bugzilla имеет много ключей, а также расширенные функции, что делает его уникальным. Ниже приведен список некоторых наиболее важных особенностей Bugzilla –

Bugzilla является мощным и имеет расширенные возможности поиска.
Bugzilla поддерживает настраиваемые пользователем почтовые уведомления при изменении статуса ошибки.
Bugzilla отображает полную историю изменений ошибок.
Bugzilla обеспечивает отслеживание зависимости между ошибками и графическое представление.
Bugzilla позволяет пользователям прикреплять файлы поддержки ошибок и управлять ими.
Bugzilla имеет интегрированную, детальную схему безопасности, основанную на продукте, что делает ее более безопасной.
Он имеет полный аудит безопасности и работает в режиме заражения Perl.
Bugzilla поддерживает надежную и стабильную серверную часть RDBMS (Rational Data Base Management System).
Он поддерживает Web, XML, E-Mail и консольные интерфейсы.
Bugzilla имеет широкий спектр пользовательских функций.
Он поддерживает локализованный веб-интерфейс пользователя.
Обширная конфигурируемость, так как она позволяет настраивать другие инструменты управления тестированием для лучшего взаимодействия с пользователем.
У Bugzilla есть плавный путь обновления среди разных версий.

Bugzilla является мощным и имеет расширенные возможности поиска.

Bugzilla поддерживает настраиваемые пользователем почтовые уведомления при изменении статуса ошибки.

Bugzilla отображает полную историю изменений ошибок.

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

Bugzilla позволяет пользователям прикреплять файлы поддержки ошибок и управлять ими.

Bugzilla имеет интегрированную, детальную схему безопасности, основанную на продукте, что делает ее более безопасной.

Он имеет полный аудит безопасности и работает в режиме заражения Perl.

Bugzilla поддерживает надежную и стабильную серверную часть RDBMS (Rational Data Base Management System).

Он поддерживает Web, XML, E-Mail и консольные интерфейсы.

Bugzilla имеет широкий спектр пользовательских функций.

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

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

У Bugzilla есть плавный путь обновления среди разных версий.

В следующей главе мы обсудим предварительные условия для установки Bugzilla.

About

Bugzilla is a robust, featureful and mature defect-tracking system, or bug-tracking system. Defect-tracking systems allow teams of developers to keep track of outstanding bugs, problems, issues, enhancement and other change requests in their products effectively. Simple defect-tracking capabilities are often built into integrated source code management environments such as GitHub or other web-based or locally-installed equivalents. We find organizations turning to Bugzilla when they outgrow the capabilities of those systems — for example, because they want workflow management, or bug visibility control (security), or custom fields.

Читайте также: Pop что это за программа

Bugzilla is both free as in freedom and free as in price. Most commercial defect-tracking software vendors charge enormous licensing fees. Despite being free, Bugzilla has many features which are lacking in both its expensive and its free counterparts. Consequently, Bugzilla is used by hundreds or thousands of organizations across the globe.

Bugzilla is a web-based system but needs to be installed on your server for you to use it. However, installation is not complex.

Bugzilla is…

Under active development
Used in high-volume, high-complexity environments by Mozilla and others
Supported by a dedicated team
Packed with features that many expensive solutions lack
Trusted by world leaders in technology
Installable on many operating systems, including Windows, Mac and Linux

A Brief History of Bugzilla

When mozilla.org first came online in 1998, one of the first products that was released was Bugzilla, a bug system implemented using freely available open source tools. Bugzilla was originally written in TCL by Terry Weissman for use at mozilla.org to replace the in-house system then in use at Netscape. The initial installation of Bugzilla was deployed to the public on a mozilla.org server on April 6, 1998.

After a few months of testing and fixing on a public deployment, Bugzilla was finally released as open source via anonymous CVS and available for others to use on August 26, 1998. At this point. Terry decided to port Bugzilla to Perl, with the hopes that more people would be able to contribute to it, since Perl seemed to be a more popular language. The completion of the port to Perl was announced on September 15, 1998, and committed to CVS later that night.

After a few days of bake time, this was released as Bugzilla 2.0 on September 19, 1998. Since then a large number of projects, both commercial and free have adapted it as their primary method of tracking software defects. In April of 2000, Terry handed off control of the Bugzilla project to Tara Hernandez. Under Tara’s leadership, some of the regular contributors were coerced into taking more responsibility, and Bugzilla began to truly become a group effort. In July of 2001, facing lots of distraction from her “real job,” Tara handed off control to Dave Miller, who is still in charge as of this writing.

Additional release history after version 2.0 can be viewed on the releases page.

Where We’re Going

Bugzilla has been installed in enough places that Bugzilla’s focus has changed from being a mozilla.org centered tool to a more generalized bug tracking system. As such, we need to make installation of Bugzilla easier, have it support more databases and make it easier to optionally enable and disable features. It also needs modularity in terms of features and in the UI so that forking of the code base at individual installations will no longer be a necessity to fit the local engineering culture. We also need to allow customization of other previously hardcoded features, like resolutions and statuses.

Design Principles

Bugzilla’s development should concentrate on being a bug system. While the potential exists in the code to turn Bugzilla into a technical support ticket system, task management tool, or project management tool, we should focus on the task of designing a system to track software defects. While development occurs, we should stick to the following design principles:

Bugzilla must run on freely available, open source tools. Bugzilla support should be widened to support commercial databases, tools, and operating systems, but not at the expense of open source ones.
Speed and efficiency should be maintained at all costs. One of Bugzilla’s major attractions is its lightweight implementation and speed. Minimize calls into the database whenever possible, don’t generate speed sucking HTML, don’t fetch more data than you need to, etc, etc.
ANSI SQL calls and data types must be used in all new queries and tables. Avoid database specific calls and datatypes whenever possible. Existing SQL calls and data types should be converted to ANSI SQL.
This should be obvious, but we should be browser agnostic in our HTML and form generation, which means cleaning up the HTML output of Bugzilla, and following all applicable standards.

Читайте также: Ктп в программе что это

Milestone plans

The Milestone plans portion of our roadmap is now maintained on the Bugzilla Wiki.

Who Runs This?

The Bugzilla Project is managed by Zarro Boogs Corporation, a taxable non-charitable non-profit organization based in the United States (501(c)(4) status pending IRS approval), which was founded in 2023 by a group of the core developers. The Bugzilla logo and related trademarks are used under license from the Mozilla Foundation. Zarro Boogs is not owned by or affiliated with the Mozilla Foundation.

GitHub GitHub
Twitter Twitter
Mastodon Mastodon
Facebook Facebook
LinkedIn LinkedIn
IRC IRC on Libera.Chat
Discord

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

Планирование, постановка задачи, контроль — вот одни из важных принципов на которых строится управление проектами и web проектами в частности. А в процессе руководства удаленными командами и организации взаимодействия между ними, без использования систем постановки и контроля задач не обойтись.
В данном посте я хочу рассказать о самой популярной системе багтрекинга BugZilla и успешном ее внедрении и эксплуатации в веб-студии «Твинс». Почему-то на хабре БагЗиллу всегда упоминают вскольз. Но никто и никогда подробно не ней не останавливался. А зря…

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

Преамбула

Скажу честно как все было… Надеюсь руководство меня не побьет и не уволит. Работать в компанию я пришел молодым и не опытным руководителем проектов. Быстро освоил весь производственный процесс и целиком в него влился. Стал руководить проектами: выявлять потребности заказчика, переводить все это на язык веба и формировать задания для разработчиков.

Компания росла и развивалась. Проекты становились все больше и сложнее, а вот организационные процессы при работе над проектами оставались неизменным. Все было донельзя просто — все задачи ставились устно или же отправлялись списком по e-mail техническому директору, а он уже перераспределял задачи программистам. А в связи с тем, что производство было удаленным (часть разработчиков находилось в другом городе), то технический директор переформулировал задачи и отправлял их уже непосредственно программистам.

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

Выбор системы багтрекинга

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

Продукт — это проект
Раздел — включает в себя проекты. Мы поделили проекты по логическим группам: в работе, завершенные, на поддержке, продвижение.
Компонент — это этап: концепция, дизайн, верстка, программирование
Ошибка — это задача или баг.

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

Разграничение прав доступа к проектам

Внедрение системы среди ограниченного числа сотрудников и отлаживание взаимодействия
Вовлечение всех сотрудников на всех этапах производственного процесса
Доступ к системе сторонних разработчиков и клиентов

А расскажу я об этапе 3 и о том как правильно настроить багзилу, чтобы в нее можно было пустить сторонних разработчиков, менеджеров и клиентов. Но при этом запретить сторонним разработчикам видеть уже поставленные ошибки по проекту и вообще не иметь доступ к проектам компании.

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

Так как багзила в основном используется для поддержки Open Source проектов, то в ней по умолчанию действует принцип — что не запрещено в явном виде — то разрешено (т.е. так настроены настройки по умолчанию). Т.е. при создании новой задачи или проекта — он автоматически становится виден всем.

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

Так как у нас проектная разработка, то под каждый новый проект заведен соответствующий продукт в багтрекере.
Каждому проекту мы создали группы, совпадающую с названием проекта. Делается это в разделе «Администирование» -> «Группы» — «Создать группу»
В свойствах каждого проекта производим настройку доступа («Администрирование» -> «Продукты» -> Выбираем продукт -> «Права доступа по группам»)
Выставляем доступ по группам для продукта. Для того чтобы ошибки данного проекта были доступны только членам созданной группы выставляем параметры как показано на рисунке: для «Группы»-> «Включено», «Остальные» -> «Запрещено». Для остальных групп везде ставим «Запрещено», «Запрещено».
Соответсвующим пользователям в разделе «Администрирование» -> «Пользователи» выбираем нужного пользователя и в столбце с группами под названием «Включен в группы» назначаем соответствующую группу (проект), все задачи по которому пользователь должен видеть.
Так же давайте запретим пользователям видеть все продукты в поиске, доступ к которым запрещен. Для этого убедимся что в настройках системы «Администрирование» -> «Настройка системы» -> раздел «Групповые права доступа» -> параметр «useentrygroupdefault» выбран как «Вкл.»
Теперь необходимо ранее заведенные ошибки, связанные с проектом, так же связаться с соответсвующей группой и таким образом закрыть их от постороннего взора:
— Переходим к поиску
— Выбираем продукт
— Отбираем все ошибки по нему (новые, закрытые, выполненные и т.д.)
— Выбираем групповое редактирование
— Выделить все
— В самом конце выбираем «Добавить ошибки в эту группу» — название нашей созданной группы под проект
— Сохранить

Кстати, нет необходимости каждому программисту или дизайнеру присваивать каждый раз группу проекта, над которой он будет работать. Если в качестве исполнителя задача поставлена не него, то он будет видеть конкретную задачу по данному проекту.
Для этого надо убедиться, что в настройках системы «Администрирование» -> «Настройка системы» -> раздел «Групповые права доступа» -> параметр «strict_isolation» выбран как «Выкл.» Таким образом над одним проектом смогут работать различные исполнители и не видеть задач друг друга, в то время как менеджер будет видеть полную картину проекта.

Установим в настройках системы «Администрирование» -> «Настройка системы» -> раздел «Групповые права доступа» -> параметр «makeproductgroups» выбран как «Вкл.»
Теперь при создании нового продукта к нему автоматически будет создаваться группа.
Вот и все. Теперь при создании ошибок к данному проекту они будут доступны только тем пользователям, которым назначена группа данного проекта.

Заключение

И вот по истечению 2,5 лет я могу сказать что решение в пользу BugZilla было принято верным. Сейчас без этой системы не могут обойтись ни менеджеры, ни сами разработчики, ни клиенты. Сейчас это один из основных инструментов при работе над проектами. В любой момент можно сделать срез по выбранному разработчику и посмотреть что у него стоит в работе. Тем самым планировать загрузку разработчиков и очередность решения задач.

Олег Демьянов
Руководитель отдела веб-разработки
компании «Твинс»

При подготовке материала использовались источники:
https://coderlessons.com/tutorials/kachestvo-programmnogo-obespecheniia/uchitsia-bugzilla/bugzilla-obzor
https://www.bugzilla.org/about/
https://habr.com/ru/companies/twins/articles/92769/

Bugzilla что это за программа