JIRA Agile and Workflows

Workflows

After my post yesterday on JIRA Agile and Hipchat using post functions on workflow transitions, I played around with modifying the default JIRA workflow to include a ‘testing’ stage – as currently it goes from “Open”, “In Progress” to “Resolved” or “Closed” – with no mention of testing.

This is easy enough to add – you simply modify the workflow, and add a new stage, as per below:

Screen Shot 2014-08-14 at 14.03.43

Here I added a new status, ‘In Testing’, and linked it from ‘In Progress’ with a  ‘QA’ transition. This is really cool, because you go from having a default view of an ‘in progress’ story of:

sample_Start

 

To one that has a new button, “QA”, the developer has finished with the story:

_TP-10__Subtask_testing_-_JIRA

 

When the developer clicks ‘QA’ (Or ‘Assign to QA’, whatever you call it!) the buttons will change, along with the status of the story / task, as per the image below:

_TP-10__Subtask_testing_-_JIRA2

Obviously, you might want to link the ‘In testing’ status to ‘In Progress’ again, if the testing fails for example – this is just a quick setup :) The problem we have with the above workflow however, is that the same workflow is not applicable to all types!

So what do i mean by this? Well, you might want to use a different workflow for tasks or bugs, compared to user stories – i.e. in a user story, you will generally have ‘developer’ tasks and QA tasks, therefore having a developer task go to ‘In testing’ makes no sense – you might want just ‘open’,’in progress’ and ‘closed’ for example – whereas bugs might be ‘open’, ‘in progress’ and ‘fixed’, etc. Luckily, there is a way in JIRA that you can create seperate workflows for specific items – hidden in plain sight at ‘Workflow’ under your project:

Project_Test_Project_-_Workflows_-_JIRA

In my example above – I have 2 workflows – one for ‘tasks’, and one for ‘everything else’. In tasks I have forgone the QA element – just to diffentiate between them, as per above.

Im not going to go through adding a workflow, as its really simple – you basically click ‘Add workflow’, choose the one you want (i.e. JIRA default), associate that with the issue types you want, and then click OK/Submit. Then, edit away – add new statuses/transitions, rename labels, add new post functions, and more. Then, publish – and your changes are applied!

Task in progress

_TP-21__A_sub_task__-_JIRA

Bug in progress

_TP-10__Subtask_testing_-_JIRA

Conclusion

Basically, using workflows and post functions, you can pretty much customise everything you want in JIRA Agile. For example, I played around with ‘Slack’ last night on the recommendation of a friend, and whilst it wasnt as advanced as the Hipchat integration – it is remarkably easy to setup – just configure it as a Webhook, and again – select a post function on a transition, ‘Type: Webhook’ and voila, your configured! Its really simple but incredibly powerful.

 

 

Integrating JIRA Agile and Hipchat

Recently, I came across Hipchat as a user had created a way to send Opsview notifications into it – and i had no idea what *it* was. After having a brief google, it looks like a very interesting tool – a sort of chatroom meets dev tool blend, whereby development teams can chat and ask questions in amongst messages from other tools including GitHub, JIRA Agile and more.

So, naturally – as JIRA Agile users, and with HipChat being free, I wanted to integrate it so i could test it out. Unfortunately this is a bit difficult if you arent an Atlassian employee, so below are some simple steps to get you from 2 seperate systems, to an integrated setup where messages are sent from JIRA Agile into your Hipchat room of choice.

1. Link them together

In order to link JIRA Agile and Hipchat together, you first need an API key from Hipchat. To do this, navigate to https://*.hipchat.com/admin/api where * is your Hipchat domain. On this page, you will be able to click ‘Create’ new token which will generate an API key for you:

Screen Shot 2014-08-13 at 16.02.19

After creating your token, you will be left with an API – like so:

obfuscatedapitoken

Copy and paste that bad boy, as you’ll be needing it in a moment. Now, login to your JIRA Agile instance - in my case, we are using JIRA On-demand, so if you are using the on-prem version this may slightly differ for you.

Within JIRA Agile, navigate to ‘System’ via the gear cog as below:

Screen Shot 2014-08-13 at 16.07.56

And once in here, go to ‘Mail’ and then ‘HipChat configuration’ on the left hand side:

Screen Shot 2014-08-13 at 16.17.01

In here..well, you know what im going to say next :) Paste in that API Badboy you copied earlier, and click save. For those using Hipchat ‘on premise’ (if thats even a thing), you might need to modify your URL here – but for me and most other users, just leave it as default:

HipChat_Configuration_-_JIRA

2. Configure JIRA Agile

Ok, thats the easy part out of the way. JIRA Agile is now setup to talk to Hipchat (trust me, it is!). Now we need to tell JIRA Agile what to tell Hipchat about – to do this, we must edit our JIRA Workflow (scary!). The workflows can be found via the left hand menu under your JIRA Agile project:

Project_Test_Project_-_JIRA

Click on ‘Workflows’, and you will be presented with your workflow (or default one, if you’ve never changed it!). Now, we want to edit the workflow in order to tell JIRA Agile when to alert us – so to do this, click the little ‘pencil’ icon on the right hand side:

Project_Test_Project_-_Workflows_-_JIRA

This will load up your workflow edit view. This is basically the ‘flow’ that your user stories, tasks and whatnot follow – and is comprised of 2 items:

  1. Statuses – Statuses are states that a user story or task can ‘be’, for example – a story can be ‘Open’, ‘In Progress’, or ‘Closed’.
  2. Transitions – Transitions are what happens when a user or developer changes the status of a user story, i.e. changing from ‘Open’ to ‘In Progess’ has a transition by default of ‘Start progress’.

The item above that we are interested in is ‘Transitions’.

What we therefore need to do, is edit a transition and set what Atlassian refer to as a ‘Post function’, i.e. something that happens when a transition is triggered. By default, the post functions are mainly ‘Send an email to annoy everyone’, or ‘Alert the boss’ – what we are going to do is add another rule, ‘Send a message to HipChat Room X’. (There is a very dandy and technical link here for anyone who wants to learn more).

Configure the post function

So, that sounds all very fancy and technical – how do we actually do it? Well I am glad you asked. Firstly, click on the LINE (the line being the transition), and you will notice a series of options appear on the right hand side, like below:

Edit_—_Test_Project_Workflow_-_JIRA

After clicking on ‘Post functions’, you will see a list like so:

Transition__Start_Progress_-_JIRA

This is ‘the list’ of things that are supposed to happen when the ‘Start progess’ transition is invoked, i.e. someone changes a user story from ‘Open’ to ‘In progress’. What we need to do next, is click ‘Add post function’ which is hidden in the middle right of that above screenshot. Clicking this will give you a a lovely list of options, one of which is, you guessed it, “Notify HipChat”:

Add_Post_Function_To_Transition_-_JIRA

Select this line and click ‘Add’, and you will get the edit screen for that particular post function:

Add_Workflow_Transition_Function_-_JIRA

This is where you can now specify the parameters – what gets sent, and where to. Use JQL to specify only certain projects to certain rooms, only certain epics, etc etc. In my example i left JQL blank but i ticked ‘All members, Ehertz and Private members room’ rooms (just a few examples I made up), along with the client-side notification – as I am running the dedicated OS X client which is rather nice. After clicking add, that is the configuration done!

Next, and finally, we need to publish our workflow. You’ll notice after clicking add that:

A) Your workflow now has another post function – your HipChat line

B) You have this new ‘Publish’ bar at the top

publish your workflow

Go ahead and click ‘Publish draft’, and then save a backup (if you want), and voila – your changes have been made – prepare yourself for the HipChat storm!

So what does it look like?

So now we’ve configured it – what does it look like? Well, this being a sample project and a sample HipChat room its not very interesting, but below is a screenshot of the hipchat client and the messages received when i created a new user story and changed it from ‘Open’ to ‘In progress’:

HipChat_-_All_members_and_Inbox

Cool eh! Now, imagine if you had a room for each development team, and their specific JIRA changes going into the room, along with the GitHub/Bitbucket updates and OTHER items – it would be awesome!

Now, go forth and configure!

MDADM – cannot open /dev/*: Device or resource busy

Screen Shot 2014-08-08 at 13.21.35

So, what a faff.. I recently had a RAID card fail in my server, causing 2 of my 3 disks in an array to dissappear, which MDADM didnt take too kindly too. After deducing it was this and not a double disk failure, I got them back online (Confirmed by BIOS) but now came the problem of trying to recover my RAID 5 array – which was a ROYAL faff..

So, here are my notes!

After getting an error around – ‘cannot open /dev/sdc: Device or resource busy’ and ‘mdadm exited with non-zero exit status 2: (udisks-error-quark, 0)’ via the disks-utility on Ubuntu, the following steps worked for me:

1. Stop the array – this will free up the disks from being ‘resource busy’. Bit daft given they arent actually running, but anyway:

2. Next, run a forced assemble (be sure to get the disks right!):

And there you have it, your back up and running. Hopefully this helps if your stuck in the mire of syslog, lsof, etc trying to figure out what is keeping your disk open!

lm_sensors – Rename sensors

Screen Shot 2014-08-08 at 13.28.14

So recently I had temperature issues with my server; long story short – my fan controller molex fell out and thus my server got rather warm rather quickly – oops!

Problem rectified easily, however i wanted to add some more depth to my monitoring of my server temperatures with Opsview. To do this, i used lm_sensors to get the temperatures, which i can then turn into service checks (check the site for a blog on how to do this).

The problem i had however, was that there were 2 ‘temp1′ sensors, and it wasnt obvious what these were:

It turns out renaming these sensors is rather easy! Firstly, copy the name of the chip that the sensors are running on – in my case, i wanted to rename ‘temp1 and temp2′ from it8718-isa-0290 to ‘DIMM1′ and ‘DIMM2′ – so to do this, i added a new file in /etc/sensors.d/ called ‘mobo’ (you can call it anything you like), and in here i added the following lines:

Now, when I run ‘sensors’ i get the correct output:

And thats that – now when i run my checks via Opsview i can be sure im getting the temperatures from my DIMM’s and not from a northbridge sensor or something else:

Cool eh..