Buzilla is easy to use and provides basic functionality to use as a bug tracking tool. If big size attachments are allowed it would have been great. Also with Bugzilla home->Test management area is improved by allowing multiple sections it would be awesome!
K8s should be avoided - If your application works well without being converted into microservices-based architecture & fits correctly in a VM, needs less scaling, have a fixed traffic pattern then it is better to keep away from Kubernetes. Otherwise, the operational challenges & technical expertise will add a lot to the OPEX. Also, if you're the one who thinks that containers consume fewer resources as compared to VMs then this is not true. As soon as you convert your application to a microservice-based architecture, a lot of components will add up, shooting your resource consumption even higher than VMs so, please beware. Kubernetes is a good choice - When the application needs quick scaling, is already in microservice-based architecture, has no fixed traffic pattern, most of the employees already have desired skills.
Open source! No license fee involved, no limit to the number of licenses.
Easy to install and maintain. Installation is very easy and hardly needs any maintenance efforts, except when migrating from one version to other. Each project can have its own group of users.
Includes all the core features/fields that are needed to log a software bug/issue.
Multiple attachments are possible, supports various formats.
Good for reporting. Filtering mechanism lets you query bugs by various parameters.
Cloud Based. I'd like to see bugzilla be cloud based. The company I currently work with made a final decision to change db's for this specific reason. Due to the frequency of travel in this company, they need access to bugzilla from differing national / international locations.
Larger File Attachments. I believe the limit of a bugzilla content upload is 4 megabytes. For many of our video'd issues, this file size is simply impractical without the additional effort exertion on video compressor applications.
Local development, Kubernetes does tend to be a bit complicated and unnecessary in environments where all development is done locally.
The need for add-ons, Helm is almost required when running Kubernetes. This brings a whole new tool to manage and learn before a developer can really start to use Kubernetes effectively.
Finicy configmap schemes. Kubernetes configmaps often have environment breaking hangups. The fail safes surrounding configmaps are sadly lacking.
For future projects I will look at something that is hosted in the cloud that I don't have to manage. I would also like something that has a more modern feel to allow my customers to use it as well as my employees.
The Kubernetes is going to be highly likely renewed as the technologies that will be placed on top of it are long term as of planning. There shouldn't be any last minute changes in the adoption and I do not anticipate sudden change of the core underlying technology. It is just that the slow process of technology adoption that makes it hard to switch to something else.
This is a pretty straightforward system. You put in the bug details, a ticket is created, the team is notified. The user interface reflects this very simple and straightforward flow. It's certainly much easier than trying to track bugs with using Excel and email.
It is an eminently usable platform. However, its popularity is overshadowed by its complexity. To properly leverage the capabilities and possibilities of Kubernetes as a platform, you need to have excellent understanding of your use case, even better understanding of whether you even need Kubernetes, and if yes - be ready to invest in good engineering support for the platform itself
Since it is open source, it doesn't have customer service. However, the amount of information on forums is vast. If you can wade through it, you'll get what you need
Implementation was pretty simple. Particularly because the product cannot be customized so there is not much to do apart from getting it up and running.
We migrated away from the whole suite of Rational tools because of their massive complexity around administration and inflexibility regarding workflows. In addition, the suite was insanely expensive, and users hated the usability of the tools. We evaluated, and liked JIRA, but because the organization was looking for cost savings, we ended up going with Bugzilla and it's FOSS model so as to avoid ongoing costs.
Most of the required features for any orchestration tool or framework, which is provided by Kubernetes. After understanding all modules and features of the K8S, it is the best fit for us as compared with others out there.
It has made the SDLC process more efficient. Bugs were logged and tracked in emails or in Excel sheets leading to slow communication and at time version issues with multiple files. Being an online tool, Bugzilla solved those issues, improved communication, instant status updates and improved efficiency.
We have used Bugzilla with a lot of federal goverment agencies (DHS, CMS, SAMHSA, CDC, HHS etc). Project Directors adn Principle Investigators were at times given access to Bugzilla which provided a snapshot of open vs closed issues.
Some groups would resist using Bugzilla with the email reminders being the main reason. Turning off or reminding them of features where we can 'control' email notification helped a lot.
