HQ: Cupertino, CA
Offices: Israel, France, Ireland, Germany
Products: JIRA, GreenHopper, FishEye
Zend is no stranger to Atlassian. In fact, Zend was our first Voice of the Customer guest in 2010. We have also blogged about them and supported Zend Studio which leverages the Eclipse Mylyn project to connect with Atlassian developer tools.
With a close connection and support of open source projects, Atlassian has embraced Zend with open arms. Zend was founded by Zeev Suraski and Andi Gutmans who rewrote the PHP parser in 1997 – back when ‘PHP’ stood for ‘Personal Home Page Tools.’ This rewrite formed the base of PHP 3. Next, Zeev and Andi started to do another complete rewrite which produced what they called the Zend Engine. The two knew they were on to something and subsequently founded Zend Technologies, or The PHP Company.
In short, Zend Technologies revolves around the development of products relating to the development, deployment and management of PHP-based web applications. We jumped on the chance to speak with Zeev and Andi Gutmans, Director of the Zend Server product line, about how Zend uses Atlassian’s development tools. Enjoy!
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. There were just a handful of contributors to PHP – Andi and I included. We were the ones who wrote the infrastructure for what became PHP3 and PHP4 and also led some of the most important aspects of developing PHP5. 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 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. 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 software development tools. This project has been active for several years. We’re the main contributors to the Eclipse PTD project: a set of tools for developing PHP on top of Eclipse.
On the commercial side we have two key products. Zend Studio, which again builds on top of PTD, provides a commercial IT solution on top of Eclipse. We also have Zend Server which is our flagship product. Think of it essentially as an application server for PHP that provides you with a pre-built and tested version of PHP with hotfixes and updates as necessary. We also provide a lot of value add; 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 synchronous 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 and 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 set up 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 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.
We set up JIRA based on projects and products. 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 customized certain 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 do use it as a connector to the source code from JIRA tickets.
How did you decide to migrate to JIRA?
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 tweaked it heavily 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 software 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 “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 da, da, da, da.” 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 I think he was the one who pushed the Zend Framework projects to use Atlassian tools. He definitely recommended we do the same within the new 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, JIRA can implement workflows and require processes to happen in certain ways much more powerfully than Mantis. Secondly, in terms of giving access to inside 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. 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.
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 implemented in JIRA, so in many senses we did not stray far from that concept. Basic workflows in JIRA already function similar to the way we work at Zend, so JIRA was a natural choice. Also, dashboard reporting in JIRA is excellent. We did not have this functionality in our older version of Mantis.
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 JIRA 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 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 building on 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 PTD and Studio, we use Java. People 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 people 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 configuring an issue tracker is not our business. We don’t want to tweak and configure and start implementing patches to a system. If there was a JIRA version 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 praising 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.