Tag Archives: JIRA - Page 2

How can a development environment looks like

What do I mean with development environment? Not only the developer workstation with Eclipse and the common tools like JDK, Maven, Ant and so on, but the environment you need for producing high quality software.
The following article is a kind of proposal for such an environment. I think every organization has its own needs but overall this could be a starting point, if you want to build it for your organization.

Structure of a development environment
Structure of a development environment

Which roles are involved?

There are developers (in figure 1 in the top left corner), the QA (in the bottom right corner) and – of course - the customer (not shown). Of course there a many more roles in a software project – you know them as stakeholders, too.
But you know the ditch between developers and the QA-Guys? You can work well with the QA if the software they test has a good quality. But for this you need some components.

What components do you need?

Component Description
Ticketing System This is a must have. This component you need to track your tickets during development.

Revision Control System This component you need for versioning your source files. The is a great number of such systems:

Wiki You need something as documentation storage. Something that is agile enough not to block the development process.
A Wiki can help you. But remember not every wiki is a good wiki :)
Continuous Integration To produce high quality you need an automatically build and tests. Only with this you can verify your changes not breaking
already existing features. With a CI-System you can achieve this. Some of this CI-Systems are:

Artifact Repository You need always a repository where you can deploy the artifacts you build. The meaning of artifact in this context are archives like
JARs, WARs, EARs but DLLs, too. Of cource you can deploy them to your Revision Control System. But it is always an good idea to
have a mechanism you can resolve dependencies you have automatically. With Maven and Ivy you have Buildtools that do this for you.

An Artifact Repository is a simple (or not so) storage for deployable artifacts. You can choose between 3 well-known OpenSource Products:

And now…

Every component must communicate with every other component. But let’s us begin with the developers. Developers working directly with the Ticketing and the Revision Control System. They need the Ticketing System to manage the development orders (or tasks or Sprint Backlog Items if you are familary with Scrum). Changes at the sources of the project will be committed to the Revision Control System. If you have a full featured Ticketing System you can log this commits and show the relevant commits in the tickets. So you can track all changes needed for the resolving of a ticket.

The Continuous Integration System (CI) is polling the Revision Control System to get notified for changes. If there are one or more changes the automatically build will be started. After the – hopefully – successful build all tests are executed – and hopefully green – and the artifacts can be deployed to the Artifact Repository. At the same time the revision (in Subversion) or the commit (in Git) can be tagged. So you have a marker for the sources the CI used to build and create the artifacts. With this tag it is every time reproducable. If you add the Ticket-ID in the commit messages the CI can add a comment to the ticket, so you can see if the buidl was successfully or not.

After some time the developer can resolve a ticket. At this time the CI should create a QA-Release. This is a special release because if the QA-Process is green this build should use for a release. The QA-Team gets notification for a testable build from the Ticket System. After the test the QA mark the ticket as tested or reopen the ticket. In the second case the developer should fix the errors or problems.

Conclusion

This was a quick view of a possible solution to build a development environment. Such an environment you need to use Scrum successfully. I am very interested in your opionion. Please leave a comment…

Translate JIRA Transitions

If you are using the famous Issue tracker JIRA by Atlassian you are able to change the workflow. Workflows are used to define the status an issue can get. Between the 2 statuses there are a transition. In JIRA you can translate the statuses (Administration | Status | Translate).

Translate statuses in JIRA
Translate statuses in JIRA

But for transitions there is not such a dialog. But there is an solution for this. You can modify the language property file. If you use an script you can do this automatically. But one step after another :)

1. Locate the language library

In JIRA all language files are bundled in a library. This library you find in WEB-INF/lib in your JIRA installation.For the german translation the library is named language_de_DE.jar.

2. Extract the JAR and edit the JiraWebActionSupport_de_DE.properties

The JiraWebActionSupport_de_DE.properties is in the package com/atlassian/jira/web/action. You can edit this file with a simple editor. For every transititon you must add one or two properties:

  • for the title
  • for the submit button, if you transition needs a dialog (e.g. the reopen issue has a dialog where you can leave a comment)

For instance you have a transition Test Issue. This transition doesn’t need a dialog. So you need only one property:

testissue.title=Testen

As an exteded example you have a transition named Issue tested. For this you need a dialog the user can leave a comment. In this case you need 2 properties:

issuetested.title=Getested
issuetested.submit=Test abschliessen

After you finished the modification you can repackage the JAR.

3. Restart JIRA

This you should really do before you start with the next steps.

4. Add the needed properties to the transitions

The next step is to create a relation between JIRA and the properties. This can be done in the panel for modifying transitions (Administration | Workflows | Steps (of the workflow you want to change) |  Click on the transition | Properties of the transition). In the page loaded then you can add the needed properties.

Add properties to transitions
Add properties to transitions

What you need to add is a key-value pair. The key is for JIRA. With this key JIRA knows what kind of i18n text this property represents. The both relevant key are:

  • jira.i18n.title (for the title)
  • jira.i18n.submit (for the submit button)

As value you can add the properties you add to the language file (JiraWebActionSupport_de_DE.properties). After you are done you can close every dialog and activate the workflow.

As a result you see something similar to this:

Translated Transition
Translated Transition

Hmm…there are many steps…is there a chance to simplify this?

Yes, of course. You can create a script to do this automatically. For example I have one written in Groovy doing all steps automatically:

//Points to the language_de_DE.jar
def langPack = new File("...")

//Points to the folder the modified JAR should be copied to
def targetDir = new File("...")

//Points to the folder the langPack should be extracted to
def tempDir = new File(System.properties["java.io.tmpdir"]+"/language_pack")

def langFile = new File(tempDir, "com/atlassian/jira/web/action/JiraWebActionSupport_de_DE.properties")

//Create the antbuild for some common tasks
def ant = new AntBuilder()

if (tempDir.exists()){
    ant.delete(dir:tempDir)
}

ant.mkdir(dir:tempDir)
ant.unzip(src:langPack, dest:tempDir)

//Using Groovy's multiline strings
def t = """
issuetested.title=Getested
issuetested.submit=Getested
"""

//Append the existing content with our extended properties
langFile.text = langFile.text + t
ant.zip(basedir:tempDir, destfile:new File(targetDir, "language_de_DE.jar"))
ant.delete(dir:tempDir)

//Build JIRA
"cd /opt/jira".execute()
"build.bat".execute()

//Restart Tomcat
"cd /opt/tomcat/bin".execute()
"catalina.sh start".execute()

With this simple script you can do all steps automatically. One thing isn’t really nice. The properties you append to the original languagge file are saved in the script. This should be changed if there are more than a handful properties.