One key reason of the success of the eXo Platform is based on its team structure and management. With two remote development offices in Vietnam and Ukrain, it is important to use light and flexible work processes inherited from agile methodologies used in many Open Source projects.
A. Team Organization
Hence, we first have split the technical work in two different topics:
- implementing the embeddable products: needs more low level programming competencies
- implementing the end user products: needs ergonomics, artwork and web language knowledge to design User Interfaces
The Ukrainian office manages (1) while the Vietnam office manages (2).
Then each office has been split into several teams in order to industrialize and distribute the production process.
The Ukrainian office is composed of 6 teams:
- Implementation of eXo JCR core
- Implementation of eXo JCR extensions (protocol supports and clients like Microsoft Office plugin implementations)
- Implementation of eXo PC
- Implementation of the Web Service layer to open our platform to third parties developers
- QA team to test and validate the product on several Application servers and Operating Systems
- Admin System team to manage all our servers (hosted on Amazon EC2)
The Vietnam office is composed of 7 teams:
- Specification and Documentation
- Web Design
- Implementing eXo Portal
- Implementing eXo ECM
- Implementing eXo CS
The first 4 teams are transverse ones as they can work with dedicated product teams.
Testers and doc writers have no technical background.
As end users products use the embeddable ones there is a tight collaboration between Ukrainian and Vietnamese teams. This is done thanks to a heavy use of collaborative and agile development tools:
- Bug Tracker
- Continuous Integration
- Source Control Tree (SVN)
- Mailing Lists
- Instant Messenger
Thanks to this team organization, we have been able to sustain our employment growth in order to foster our product portfolio extension.
B. QA Processes
To ensure Quality, we release – every 2 weeks – a new version of the community build on OW2 Forge
So far 3 Open Source Application Servers (AS) are distributed bundled with eXo: Tomcat 6, JOnAS and JBoss. If you would like other Open Source AS to be distributed too (GlassFish or Geronimo), please contact us. Commercial AS support like Weblogic or Websphere, that we can not freely distribute, are available through our subscription offering.
When the release day comes:
- The nightly build version of each AS is used to start the test phase
- On each version, a Sniff Test is made by the Test Team and a Release Note for each AS is written. The release note also points to a JIRA query that display all the issues that were resolved since the last date release
- The Release Manager uploads the files to the forge
A Sniff Test is a set of Test Cases that will unsure a minimum quality for each community release. A Test Case is a functional integration test that tests a user behavior while browsing the Portal. Every 6 months, a subscription version is released with much more Test Case implied in the QA process.
The structure of a Test Case is quite simple, here is a Test Case Sample. As you can see, it references the other Test Case needed to run that one, some screenshots, a detail process on what have to be tested, a flash movie showing the correct test manipulation and a link to the JIRA issues that point or refer to this test. Wiki pages and JIRA issues should also reference the Test Case. Finally, test cases can also be used as quick tutorials.
This describes our current methodology and internal organization, it is not a final one nor the first one we used…we continuously improve the process!
Thanks, very interesting !
Concerning QA process, you don’t use any tool to automate functional tests ?
No we are not outside the scope of large customers project. I say large because basically it means they have purchased a tool like LoadRunner which is quite expensive 🙂
There exist several tools to automate the user navigation behavior like Selenium which is a Firefox plugin but it is not yet able to simulate several at the same time and hence also provide stress tests
For low level API we have used JMeter and OpenSTA too