Zend is ‘the PHP Company.’ It says it right there on their homepage; in fact, it’s a part of their logo. I can’t think of any other time where I had the opportunity to talk with anyone else that said they were the anything.
Zend sprouted and has grown out of the development of PHP. You can’t get far in reading about one before crossing the other. With such a rich past, I was excited to learn how pioneers of such a valuable scripting language used Atlassian’s products.
I got in touch with Zeev Suraski and Alex Haiut, co-founder of Zend Technologies and Director of the Zend server product line respectively. Zend is an infrastructure software company centered on the development of all things PHP-based. Founded in Tel Aviv, Israel, they couldn’t pass up on opening headquarters in the heart of Silicon Valley at Cupertino, CA. Zend is quite content using JIRA for issue tracking with GreenHopper for agile project management.
Tell me about Zend
Zend was started by Andi Gutmans and me, and we’re two of the original contributors to PHP. That was back 13 years ago. We were the ones who wrote the infrastructure for what became PHP 3 and PHP 4 and also led some of the most important aspects of developing PHP 5. We founded Zend roughly two and a half years after starting on PHP with the mandate to provide backing and solutions for companies using PHP, and also to help proliferate the usage of PHP around the world.
Today we’re doing a lot of different things. We are active in several Open Source projects while still very active in PHP itself. Many, if not most, of the key contributions to the Zend Engine (the brain of PHP) are done by Zend. We are leading the Zend Framework project, which also uses Atlassian tools. This project has been active for several years. We’re the main contributors to the Eclipse PDT project: a set of tools for developing PHP on top of Eclipse.
On the commercial side we have two key lines of products. In the realm of development tools, Zend Studio builds on top of PDT to provide a commercial Eclipse-based IDE solution. On the runtime side, we have our flagship product Zend Server. You can think of it as an application server for PHP that provides you with a pre-built and tested version of PHP with hotfixes and updates as necessary, and in turn also provides a lot of value-add functionality; anything from improving the performance of PHP through managing PHP clusters, gaining insight on what’s happening on individual PHP clusters, all the way to new language features like the ability to run asynchronous jobs, etc.
How do you use JIRA?
We use JIRA as a bug tracking system for all our software development projects and basically for all products we develop. This is what the system (JIRA) was designed for – an internal bug tracking system. It is used by all parties within the company (development, QA, product management, support, etc.), but the instance is not exposed to our customers. However, this is something we are thinking about.
We originally used Mantis before migrating to JIRA. In general, our individual migration experiences were very, very positive. In terms of the clarity we have the ability to get information out of the system, it is much better than what we had in Mantis. It was a relatively easy and intuitive setup for us and the migration went fairly smooth; we are now running full speed with JIRA. We have already released a few products based on JIRA and they are moving okay now. GreenHopper still needs to be tweaked, but the overall experience with the agile project management tool so far is very positive. What we love about JIRA is the ability to get a complete picture of our inventory. Not only can we track a single bug or issue filed in JIRA, but we also have the ability to slice the entire bug database by various parameters and get a clear picture of what’s going on with the specific project’s milestone or velocity, and so on.
JIRA is currently configured with five to seven different projects that include major product lines and a couple of internal projects. We configured the instance on a per project basis; each project has its own workflows and settings. Most are basic JIRA workflows with minor changes. We also have some custom workflows. We have a few add-ons and various graphs and charts, but nothing exceptional. The basics work extremely well for our usage. The FishEye plugin, or integration with JIRA, is also very beneficial to us. We do not use it for day-to-day browsing of repositories, instead we use it as a connector to the source code from JIRA tickets.
How did you decide to migrate to Atlassian’s issue tracker?
We had a Mantis bug tracking system that went through various evolution cycles. It was a few years old, heavily modified, and included all kinds of issues. It was written in PHP, so we could easily tweak it towards our needs. We had reached a stage where we needed a clean start. We decided a major change was needed in our bug tracking system to reflect development processes. We analyzed a few alternatives starting close to home with a newer version of Mantis. Another was JIRA which was added to our bug tracker “list” because of its overall popularity in the community. We’d received very good references about JIRA’s reliability and overall power. It also had strength from the accompanying tools, not just one or two, but a whole suite. We looked at a few other alternatives like Bugzilla and a couple I don’t remember now. We analyzed what we’d gain from each, like power and ability to integrate with other systems. Based on these main factors, JIRA was the clear winner here.
Regarding the migration, it obviously was a change, and nobody likes change at the beginning. Migrating to JIRA felt fairly intuitive and our teams adopted it very quickly. There were a few skeptics, like QA who said “How will it change my life. It’s just going to give us headaches and downtime, yada, yada, yada.” The bottom line today is that QA is one of the biggest supporters of JIRA and they are very happy about the change. In general most people don’t like change; they’re happy with the status quo. Once we migrated, just a week later, people started seeing the benefits. Overall, I would say our people are happy about the move.
I would also add that our CEO was a big fan of Atlassian and was the one who pushed the Zend Framework projects to use Atlassian tools. He definitely recommended we do the same within other parts of the organization. JIRA, unlike Mantis, also supports implementing a workflow around the issue opening and resolution. We find this feature very valuable.
What is the biggest difference from Mantis to JIRA?
I would say two things. First, you can implement a custom workflow and require processes to happen in certain ways much more powerfully than Mantis. We like the flexibility and power of JIRA – the ability to get workflows correctly implemented in an easy way. We found our development process fairly close to the default workflows in JIRA; basic workflows in the bug tracking software already function similar to the way we work at Zend, so JIRA was a natural choice. Second, in terms of giving access to data, JIRA does an excellent job. There are many options for reporting and the ability to slice and dice data to essentially create new data is something Mantis almost completely lacks. Dashboard reporting in JIRA is excellent. We did not have this functionality in our older version of Mantis. For me, these reasons are the key advantages of why we moved to JIRA.
There’s another thing which is fundamentally different from what we did with Mantis. Some teams use JIRA as a way to bake deliverables into tasks – every small subtask goes into JIRA as an issue that has a guarantee of getting resolved. We track work, not just issues or bugs. This is definitely something that is very, very different from the way we’re using JIRA as opposed to Mantis. Over time we’ll extend that more and more.
How will you push JIRA moving forward?
Over the next few months, I would like to figure out how to squeeze more data out of the system that’s already in JIRA. In general, we’re happy with what it’s doing for us now as an issue tracking system and a source of information about the development workflow and quality process we have at Zend. We’ll most likely use GreenHopper, not just in the main context of JIRA bug tracking system, but also to further influence the workflow and help us with the development cycle and the testing cycle.
What advice would you give someone considering JIRA?
First of all, I definitely recommend JIRA. I would seriously consider using your project tracking software from the get-go and not a lesser issue tracking system. It’s worth it. The amount of data that you can get out of it, the clarity, and the workflow that you can enforce are very, very powerful. You could also adjust JIRA to be as aggressive and as painful as you’d like it to be. You can configure it for a small company, but if you want to enforce a certain complex flow, it is also possible. I would advise a small company to use a good tool and not settle for something less powerful because the features are tailored for a small company. I think it’s important for a small company to have clarity about the quality of your product.
Can you comment on a PHP shop using Java-based tools?
Interesting question! We are known as ‘the PHP company,’ but inside the organization we actually use a very wide range tools. For PDT and Studio, we use Java. We are no strangers to Java at Zend. The PHP team develops the UI for Zend Server and C++ develops the engine, or the brain of the product. I would say we are biased towards a PHP-based system because of the synergy and experience we have with PHP. That was one of the advantages of Mantis – it is based on PHP and we could easily tweak and configure it. However, we came to the conclusion that developing an issue tracker is not our business. We don’t want to tweak, configure, and start implementing patches. If there was an issue tracker based on PHP, I would probably prefer it to the Java version, but the most important criteria by far was based on how great the system is and not what language it is built on. I haven’t heard anyone bashing us for using a Java-based system. However, I did hear some concerns about resource utilization, but we prepared ahead of time and purchased JIRA as a powerful system with lots of memory. So, we’re happy.
Thanks Zeev and Alex!
For more Atlassian case studies, please go here.