Programing

Bugzilla 또는 Mantis?

crosscheck 2020. 12. 14. 07:53
반응형

Bugzilla 또는 Mantis?


제목에서 알 수 있듯이 지금 하나의 프로젝트를 시작하고 프로젝트의 인프라 (SVN, 이메일, 버그 추적, 온라인 포럼 등)를 레이아웃하려고합니다.

그래서, Bugzilla 또는 Mantis?


나는 당신의 팀이 Bugzilla 또는 Mantis보다 Trac 또는 Redmine을 더 좋아할 것이라고 생각합니다. 둘 다 Subversion과 잘 통합됩니다. 둘 다 위키, 포럼, 프로젝트 관리 기능을 포함합니다.

빠른 개요:

Trac : 매우 널리 사용되고 사랑 받고 있으며 파이썬, 거대한 커뮤니티, 많은 "플러그인"으로 작성되었습니다. 일반적인 불만은 여러 프로젝트를 즉시 지원하지 않지만 플러그인을 추가하여 도움을 줄 수 있다는 것입니다.

Redmine : RubyOnRails에 작성되었습니다. Trac과 비슷하지만 상자에서 꺼내면 더 완벽합니다. Redmine의 저자는 Trac보다 더 나은 Trac을 만들려고 노력하고 있습니다.

버그 추적기를 검색하는 다른 사람들이 작성한 내용에 관심이 있고 추적기를 서로 비교하는 데 관심이 있다면 여기에 몇 가지 링크를 추가했습니다.
http://ifdefined.com/blog/post/2007/10/Links-to-other -comparisons-of-issue-trackers.aspx

Windows를 사용하고 계시다면 .NET / MS SQL Server에서 사용하기 쉽고 매우 구성 가능한 버그 추적 시스템 인 BugTracker.NET도 고려해보십시오 . (면책 조항 : 저자입니다).


나는 사마귀를 좋아합니다. 간단하고 작업이 완료됩니다.


저는 Bugzilla와 Mantis를 사용했지만 Mantis의 단순함을 선호합니다. Bugzilla만큼 풍부한 기능은 아니지만 Bugzilla와 더 많이 싸웠던 것을 기억합니다. Mantis는 한 번 설정하고 떠날 수있는 종류입니다.


Mantis는 확실히 Bugzilla보다 유용성 측면에서 승리합니다.

특히 Mantis에 버그를 기록하는 것이 훨씬 빠릅니다. 버그를 기록하는 시간은 어떤 사람들에게는 방해가되는 일입니다. 버그를 기록하지 않고 수정하고 수정할 버그가없는 척 (더 깊은 팀 문제의 증상)하는 변명으로 사용되었다고 들었습니다.

클라이언트 (현재 Basecamp, bleah를 사용 중입니다!)가 Mantis의 아이디어를 통조림 할 때까지는 (위에서 언급했듯이) 일부 사람들이 추악하다고 생각한다는 것을 깨달았 기 때문에 Mantis의 아이디어를 통조림으로 만들었습니다.

Bugzilla 또는 우리가 구현하려고 시도한 다른 시스템과 비교할 때, 이상한 유럽인 Mantis는 훌륭합니다.

나는 Mantis가 저울을 잘 알고 있다는 것을 알고 있습니다. 친구가 영화 Happy Feet의 제작에 그것을 사용했습니다. 그는 다른 수준의 분류를 제공하기 위해 하나의 추가 필드를 추가하여 사용자 정의했습니다.


Bugzilla는 더 크고, 더 큰 커뮤니티, 더 많은 기능, 더 많은 힘 ... 그 이유 때문에 저는 항상 mantis를 선호했습니다.) Mantis는 죄처럼 추악하지만 대부분의 프로젝트에서 간단하고 직관적 인 방식으로 필요한 것을 제공합니다.

큰 팀이 있다면 큰 QA 부서와 나머지 버그 질리 아가 더 적합 할 수 있습니다. 작업을 완료해야하는 소규모 팀-그러면 mantis가 더 나은 imo 일 것입니다.

mantis에서 누락 된 가장 큰 기능 (몇 년 전부터 추가했을 수 있음)은 보고서 기능이므로 멋진 선 및 원형 차트로 진행 상황을 추적 할 수 있습니다. 그러나 저는 간단한 PHP 스크립트를 작성하여 데이터를 추출하고 매주 수동으로 생성했습니다 (5 분 정도 소요). 그 당시 우리가 필요로했던 것에 대해 훌륭하지는 않지만 기능적으로 충분합니다.

그러나 둘 다의 온라인 데모가 있으므로 시도해보고 가장 적합한 것을 선택하는 것이 좋습니다.

HTH


Mantis는 훌륭하고 설정이 매우 쉽습니다.

약 3 년 동안 사용하고 있습니다.

다음과 같은 문제가 있습니다.

이슈에 저장할 수있는 파일 크기에는 2Meg 제한이 있습니다. 문제의 스크린 샷을 포함하려는 경우 문제가됩니다.

두 사람이 동시에 문제를 업데이트하는 경우-누군가 데이터를 잃게됩니다.


Mantis는 위대하고 간단합니다. 고객은 기술이 아닌 사람들이기 때문에 단순함이 중요합니다.


두 가지를 모두 사용했지만 전혀 마음에 들지 않았습니다. Trac을 선호 합니다.이 두 가지 중에서 선택해야한다면 Bugzilla를 선택하겠습니다. TRAC와 Subversion의 통합은 정말 좋습니다 ( Assembla 를 살펴보십시오. 통합 작동 방식)

Trac은 또한 오픈 소스이며 새로운 보고서와 같은 것을 추가하는 것이 매우 간단합니다.


Redmine을 사용해 볼 수 있습니다. 리포지토리 액세스, 트래커, 포럼, 위키, 캘린더를 한 곳에서 제공합니다.


저는 Bugzilla (작업중인 프로젝트의 기본값)를 광범위하게 사용했지만 Mantis는 쉬운 설정과 사용에 대한 제 표를 얻었습니다.


나는 fogbugz에 대해 좋은 소식을 들었지만 아직 그것을 사용할 기회를 찾지 못했습니다. http://www.fogcreek.com/FogBUGZ/


나는 사마귀를 선호합니다. 그것은 훌륭하게 수행되며 플러그인을 사용하거나 코딩을 통해 쉽게 확장 할 수 있습니다.


Trac에 대한 또 다른 투표-시작하기가 간단하고 저장소에 대한 멋진 웹 기반보기 등.


Choosing the right bug tracker requires that you know who is going to use it (and how it is going to be used). I've used Bugzilla and Mantis and found Bugzilla better from a technical point of view but Mantis wins if some of your bug reporters are not programmers / not programmer minded. Its interface is less 'threatening' for a novice bugtracker user.

If you are going to have a private bugtracker you also need to consider the options it gives you to specify who is allowed to view/edit etc.


I've used bugzilla for a while, but Redmine get my vote. easy setup, very very intuitive.

참고URL : https://stackoverflow.com/questions/323411/bugzilla-or-mantis

반응형