Upgrading Bugzilla to 3.0.2 is not all that difficult with the right approach, even with Windows 2003 and ActiveState Perl.
This blog post is about upgrading customized (in some cases, extreamly customized) versions of Bugzilla from 2.x to 3.x
If you are upgrading a vanilla release of 2.x to vanilla 3.x, you should use the vanilla instructions, standard Bugzilla upgrading instructions.
The short answer is:
- Backup your installation folder,
- Replace it with the new download
- Backup your database and run checksetup.pl.
For my customized upgrades, I still use the "Tarball" upgrade and a copy of my MySQL database and the process is similar.
Setup
- Back Up Your Database
- mysqldump --opt -u bugs -p bugs > bugs.sql
- Replace Bugzilla 2.x with 3.x
- Copy your localconfig file
- Copy your data directory
- Delete 'templates'
- Run checksetup.pl
- Install all required modules
- Allow checksetup to create tables
- Cntr+C Before it does UTF-8
- Run contrib/recode.pl
- I used --charset=latin1 in Windows
- Windows does not support Encode::Detect (sad!)
- Run checksetup.pl again
- Allow UTF-8 Scripts
- Allow other database changes
The majority of the changes to the Bugzilla database will be performed by checksetup.pl
If you have made changes to the database, for example:
- Adding New Tables
- Adding New Columns To Bugzilla Tables
- Adding Relationships Between Bugzilla Tables and New Tables
- Changed Column Types on Bugzilla Tables
- Written Stored Procedures Referencing Bugzilla Tables
- Review the Bugzilla Schema changes for your upgrade
- Bugzilla Upgrade Schema Differencing Tool to see what fields and columns have changed
- I find that having a clean copy of the Bugzilla 3.x database around is helpful for some reason, so for my upgrades I use the following databases:
- 'bugs' -- Bugzilla 2.1.16 Database
- 'bugs3' -- Clean Install of Bugzilla 3.0.2
- 'bugs3up' -- My Bugzilla 2.1.16 Copy, Upgrading to Bugzilla 3.0.2
- Sometimes, I dropped the 'attachments' table from my 'bugs3up' database for testing, to speed things up
- Backing Up (With MySQLDump -- be careful!) your custom tables and dropping them before running checksetup.pl
- Remove any non-standard referential integrity constraints that you have added. These are also backed up with MySQLDump
- Use the referenced Bugzilla Upgrade Schema differencing tool to try to restore your Bugzilla 2.x database to as much of a vanilla 2.x state as possible. In some cases, I was able to restore my column types or original relationships to 2.x standards and the checksetup.pl was able to finish.
These changes will break your customized Bugzilla code, reporting systems, hook scripts or whatever else -- but they will unbreak the wonderful checksetup.pl
3 comments:
These instructions are incorrect.
People should be following the standard Bugzilla upgrading instructions.
Anybody using the instructions in this blog post is likely to end up with a Bugzilla that is broken in strange and mysterious ways.
-Max
People should be following the standard Bugzilla upgrading instructions, if they worked.
Anyone using the instructions on the link in the comment above is likely to end up with a Bugzilla that is broken in strange and mysterious ways, unless they have not made any customizations.
The Standard Bugzilla Upgrade instructions work very well for vanilla installations of Bugzilla.
Unfortunately, for most organizations, the vanilla installation of Bugzilla does not work well enough (or look good enough) to have broad acceptance.
I quote from the standard instructions:
If you have modified the code or templates of your Bugzilla, then upgrading requires a bit more thought and effort. A discussion of the various methods of updating compared with degree and methods of local customization can be found in Section 6.2.2.
The larger the jump you are trying to make, the more difficult it is going to be to upgrade if you have made local customizations. Upgrading from 3.0 to 3.0.1 should be fairly painless even if you are heavily customized, but going from 2.18 to 3.0 is going to mean a fair bit of work re-writing your local changes to use the new files, logic, templates, etc. If you have done no local changes at all, however, then upgrading should be approximately the same amount of work regardless of how long it has been since your version was released.
They forget the all important modification to the Bugzilla database, as well, and make no mention of what you'll have to do to make that work (see original post.)
If you have managed to use Bugzilla without making extensive customizations, you are lucky. I envy you and your users the simplicity of an un-customized Bugzilla.
I do wish you had all the helpful automation, functionality and AJAX wiz-bang coolness that I have been able to provide my users, clients and organizations. However, you do have a simple upgrade path in that scenario and would be best served with the standard bugzilla upgrade instructions
The way that customizers should be modifying the database is the way described in the Bugzilla Developer's Guide (see the Bugzilla::DB::Schema and checksetup.pl POD for a little extra info). For the most part, if you do it that way, you shouldn't have any trouble when you upgrade. There could be a few things you have to deal with, though, and probably the best way to do that is to further modify Bugzilla::Install::DB (or use the install-update_db hook described in Bugzilla::Hook).
-Max
Post a Comment