Achieving ALM Using Atlassian Products

Posted on October 18, 2009

0


Atlassian has spruced up their ALM offering with the major 4.0 release of JIRA. With this release, they have made JIRA as the single point of integration of their products – at least from a UI perspective !! I got interested in trying out the new release and also their other products. The main reason being that I have been using Confluence & JIRA for the past 2 years and I also got interested in easing the pain of Application Lifecycle Management (ALM) especially after seeing people maintaining legacy application and business processes, in the last 3 years for a major US Telco!!!

To put all the ‘different pieces of the ALM puzzle’ in perspective, let us start with the following diagram which pictorially shows where the Atlassian tools (in bold) and their plug-ins fit:
ALM and the Atlassian Products

ALM and the Atlassian Products

I have used the OpenUP process and the roles people play in carrying out the activities in the 4 major phases.

  1. During the inception phase , Project Manager (PM), Business Analyst (BA) and Architects (Archs) in consultation with the Stake-holders (SHs) come up the scope of the project and the initial architecture, which the SHs are willing to fund. Relevant Tools: As the scope is more or less defined using high-level functional & architectural requirements, the main tool support required is requirements tracking. Couple of extension – synapseRT for JIRA & Teamwork for Confluence seem to do this, but their features are not evaluated in this post.
  2. Initial modeling & prototyping is done by the Architects and Design Engineers (DEs) during the Elaboration Phase. This is done as proof-of-concept of initial architecture & design. Relevant Tools: This phase requires software design modelling using UML or other domain-specific notations. Gliffy extension & open source Graphviz extensions for Confluence. These features will be evaluated in a separate post.
  3. Construction phase involves the  implementation of working software which realizes the requirements & design set in the previous phases. This phase becomes iterative since the requirements are refined through periodic feedback from SHs. Relevant Tools: Construction phase is most done thru’ mainly an IDE. Atlassian has connectors for Eclipse & IDE and the features available in them are not elaborated in this post.
  4. Transition phase encompass the V&V of the produced software through user acceptance test cases definitions and final deployment in the production environment. Testers, build & release engineers play their part in this phase. Relevant Tools: As part of requirements validation activity, SQAs require test case definition, capture & traceability of test cases to requirements. These features are available in Teamwork extension to Confluence but not evaluated in this post.

Evaluating Jira 4.0 & other 5 products – Jira Greenhopper plug-in, Crowd, Confluence, Fisheye+Crucible & Bamboo meant installation & configuration of these products to make them work together. Fortunately there is detailed documentation available as part of Dragon Slayers contest !!

In pursuit of the [open call for the installing & integration configuration of the six Atlassian products – Crowd, JIRA, Greenhopper, Confluence, Bamboo, Fisheye+Crucible|http://confluence.atlassian.com/display/ATLAS/Here+Be+Dragons] , I embarked on trying it out. The main reason being that I have been using Confluence & JIRA for the past 2 years and I also got interested in easing the pain of Application Lifecycle Management (ALM) especially after seeing people maintaining legacy application and business processes, in the last 3 years for a major US Telco!!!
Points to remember – Atlassian Products Installation:
# “Crowd versions 1.1 and later include CrowdID. Installing Crowd, as described below, will also install CrowdID.”
Taken from [here|http://confluence.atlassian.com/display/CROWD/Installing+Crowd+and+CrowdID]
# While stopping & re-starting JBoss, I got ‘lock present in JIRA home dir’ everytime. This is because my JBoss is not undelpoying the JIRA application at all, which should hopefully clean-up the lock file.
To get rid of this, the .lock file has to be removed, before starting JBoss again.
JIRA is not getting undeployed – just like conflunce – from server.log file
Points to remember – while configuring the products for integration:
# While importing users & groups from JIRA into Crowd, the group memberships were NOT imported !! It does matter because without the logging user being part of confluence-users group, he/whe will get the “Not permitted” message & won’t be able to see any wiki page. The same with Jira.
#

I was already running JIRA & Confluence on JBoss since I was using $5 for 5 users license since April. So I had to only upgrade them to the latest versions. I used Tomcat for running the other component products – Crowd, Bamboo.Fisheye+Crucible run in their own packed container. But all products used MySQL for backend DB.

Some points to remember during the upgrade or new installation:

  1. “Crowd versions 1.1 and later include CrowdID. Installing Crowd, as described below, will also install CrowdID.”, which is mentioned here
  2. While upgrading JIRA make sure to remove the Javascript/JSP page cache in the Jboss/Tomcat container work directory: server/default/work
  3. While importing users & groups from JIRA into Crowd, the group memberships were NOT imported !! It does matter because without the logging user being part of confluence-users group, he/whe will get the “Not permitted” message & won’t be able to see any wiki page. The same with Jira.
  4. Make sure to add the connector attribute URIEncoding=”UTF-8″ , otherwise the spaces in install path of Tomcat will create problem while defining JIRA Server in Bamboo configuration.

Some points for improvement:

  1. Integ. Crowd requires copying of crowd client jar files & editing properties & xml files. But the implementation in Fisheye avoids some of these manual config files editing and this should be replicated in other product components.
  2. Administering the 6 different products in separate web pages will be tedious. If the products are configured for ALM, one should be able to avoid many manual steps by providing a ‘Unified Admin Interface’.

Conclusion:

If a customer is willing to buy all the products for their ALM usage, Atlassian would serve the customers better by offering an integrated ‘ALM product’ which simplifies everything – right from installation, administration & usage by a user in a specific role in the SDP. Of course, the offering of OpenSocial gadgets in JIRA is a good starting point for this ultimate goal !!

Advertisements
Posted in: Atlassian