It’s an issue/defect tracking open source software. If you want to know the background about how it all started then check the following wiki link
http://en.wikipedia.org/wiki/Bugzilla
Check the following wiki link in case if you are interested in doing a comparison of various issue tracking systems
http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems
You can visit the following website for good tips on installation and how to use Bugzilla.
http://www.bugzilla.org/
I am going to focus on what I had to do when I had to configure bugzilla on a Red Hat Enterprise Linux 5.X O.S. (same applies for fedora). Going forward, I will be using the following acronym for Red Hat - RHEL5
- Download the latest version of bugzilla from the website (http://www.bugzilla.org/) I have downloaded Stable Release (3.6.1)
- In RHEL5 make sure you install the apache web server that comes with the OS
- Configure the firewall for apache
- In RHEL5 make sure you install MySql database that comes with the OS
- Configure the firewall for MySql
- Unzip the downloaded bugzilla at a virtual directory of your choice (if you are just trying it out unzip the file at /var/www/html/
(this is the default document root of apache that comes with the OS) - If you do use the default apache virtual directory to create the bugzilla virtual directory then you need to run the “restorecon -R -v '/var/www/html/bugzilla'” command to re-label the entire directory otherwise SELinux will prevent you from accessing the website.
- Refer to the website (http://www.bugzilla.org/) for installation and configuration instructions. One thing that is not mentioned in the installation and configuration instructions on that website is that the version of MySql that comes with RHEL5 does not have the developer package (MySql-devel-5.0.77-4.el5_4.2.i386.rpm – it’s a different RPM for 64 bit processor) installed by default. Make sure you install that before you install the Perl module for MySql as the Perl module for MySql expects the developer package for MySql installed, if it’s not installed the installation of the MySql Perl module will fail. Also ensure that you have the right version of the RPM for the MySql developer package and that it matches with the rest of the versions of MySql packages that comes with the OS otherwise your RPM install will fail. You can get the RPM file from the red hat website.
- Just install the required Perl modules to get you going. The optional Perl modules can be installed later
- Use “./checksetup.pl --check-modules” to get the list of required and optional Perl modules.
- Use “perl install-module.pl
” to install the respective modules - Two optional Perl module that you might need if you are planning to use Gmail SMTP server or for that matter any SMTP Server with TLS enabled is the “Authen::SASL” Perl module and the “Email::Send::SMTP::TLS” module, after these modules are installed you can see the “SMTP:TLS” option in the dropdown box on bugzilla’s administration page for setting up parameters. Just in case if you are interested, the Perl module that gets executed behind the scene is defined in “TLS.pm” file which gets installed when you install the “Email::Send::SMTP::TLS” Perl module . I just changed the code in the “TLS.pm” file to set up the Gmail as my SMTP server and on the parameters page I selected the “SMTP:TLS” option in the dropdown box, I did not change the remaining SMTP server settings on the parameters page but instead hardcoded the same in the “TLS.pm” file. The “TLS.pm” file has a sample snippet that demonstrates how to send email to a Gmail SMTP server that has TLS enabled. (NOTE: Gmail SMTP needs TLS and talks at port 587).
- Define your backup strategy
- If you follow the configuration instructions provided on http://www.bugzilla.org/ website for database configuration, then you will have a “bugs” database in MySql database. All you need to do is back-up this database.
- You have a couple of choices for MySql database backups
- I used mysqldump – refer to http://www.mysql.com/products/backup/ for other options
- The command for MySQL backup is “mysqldump -u root -p
--databases bugs > onlybugs.sql” - The command for MySQL restore is "mysql –u root –p
<> - Once the database restore is done on the new box; re-install bugzilla on the new box (I am assuming that the web server and the database server are on the same box, it does not have to be that way). Change the “localconfig” file that “./checksetup.pl” will create after the first successfully run to point to the new restored database you have created. Do not forget to rerun the “./checksetup.pl” after you change the “localconfig” file as that will create the appropriate “.htaccess” files needed for Apache. And there you go you have the bugzilla running on a new box with old data.
- If you want you can define shell scripts to run daily in order to back-up the MySql database that stores bugzilla’s data (that’s all you need to do in order to back-up bugzilla. NOTE - take a look at what happens when the “Big File” option gets enabled within bugzilla as that results in attachments that are flagged as “Big File” not getting stored in the MySql database table “attach_data”, instead attachments that are flagged as “Big File” get stored in the local file system and needs to be backed up separately. In case if you are wondering, like me, the locally saved Big Files can be found under the data/attachments folder, this folder should be under the folder where you unzipped bugzilla (/var/www/html/
)
General comments
- For starting apache just use “/usr/sbin/apachectl” command.
- For starting MySql just use “/etc/init.d/mysqld” command
- You can run chkconfig to start and stop the two services (“apache – httpd” and “mysql -- mysqld”) automatically on startup and shutdown of OS.
In terms of end-user training for using bugzilla, use the http://www.bugzilla.org/ website documentation, it’s pretty straight forward to setup and use bugzilla. They even have a test web-site - http://landfill.bugzilla.org/ for you to play with. Just remember the logical hierarchy
- Define Classification (if this option is enabled by the administrator, its just a way to categories related Products, many are fine using just Products)
- Define Products (Define it on a per project basis)
- Define Components (Remember the more granular you get the harder it is to keep track of bugs, try defining components at a higher level of abstraction, I am assuming that you do not wish to use bugzilla for unit testing and tracking bugs but rather wish to use it during System/Integration testing and UAT testing)
- Define groups/users
- Define identified Bugs for individual components
All aspects of bugzilla can be configured and/or changed. Unless you have been assigned task to create a customized version of bugzilla that can be used across projects, try to use what you get out of the box because remember it’s a tool to facilitate testing not another sub-project for your main project. And if this is the first time you are using bugzilla, I would suggest using the product features “as is” and then define another project for customizing bugzilla based on lessons learned in your first project that used bugzilla.