Tuesday, December 23, 2014

Read the Freaking Documentation to Couchbase!

Just wanted to point out a pretty awesome product with pretty awesome documentation:

Couchbase.

We're using it for a pretty specific use case and for that, it's handling things extremely well.  However, we noticed that it was using a ton of swap space to the point I was thinking we were on Windows boxes.

Buuuut lo and behold we didn't read all the documentation on how our nodes should be set up and here it is for v2.2 that we're using.

http://docs.couchbase.com/couchbase-manual-2.2/#swap-space


Actually that screenshot is further down in the issues section, complete with impact and JIRA issues!

It's actually pretty awesome to be able to track something down this easily.  Obviously, other people have encountered this that has lead to issues but it's great to see the trail and the resulting recommendation.

Sunday, December 07, 2014

Searching Pull Requests in Stash - You Don't

A pretty popular JIRA Issue for the Stash project is this guy, STASH-3856:


Specifically, the only reason why I'm searching for a pull request after the fact is to see if there were any conversation regarding a particular design decision or if there were any explicit things that were abstained from for later work.

Also, it's a super quick way to see when a given feature was merged into a particular branch like Master.

With that said, chances are, you're using JIRA alongside Stash.  Let's be honest, the only reason to use Stash over other solutions is for its JIRA integrations.  If your issues are directly associated with your Pull Requests, you should then be able to easily search your JIRA issues using its robust search features.

JIRA Development Panel
So unfortunately, if you're eagerly awaiting STASH-3856 to be implemented, I highly doubt that they're going to accomplish this any time soon.  There are definitely some Stash specific searches that would be nice, such as when a pull request's been merged or dismissed and when it's been updated.  However, until then searching for the JIRA issue can resolve the vast majority of people's use cases.

Tuesday, December 02, 2014

JIRA - Old School Greenhopper and Milestone Management with Versions

I wouldn't be surprised if there are still a lot of organizations that are still using the Classic Boards in JIRA Agile to manage their medium to long term plans in JIRA.  I want to just go over really quickly how one can manage these in the Classic Board before I talk about a much more complex scenario in a future post and I also want to go over the limitations of this approach.



First, you'd establish Versions in your Project that represented different Milestones with dates associated with them.  From there, you'd have your actual release Versions that are directly associated with the releases that you're cutting.
With the Classic Planning Board, using the SubVersion feature, you can readily see which Release versions that build up to Milestones that build up to broader Milestones.  You'd associate stories to your release versions and from there, you can track the progress of your Parent Milestone versions.


I wanted to work this particular feature in here as I still find it to be extremely useful today that few people pay attention to.  That is the Merge Version feature.  Essentially, if you already established a Patch release and realized that this guy isn't going to be released until the next Minor version, you just merge the Version into that Minor version.  From a Git Flow perspective, this would be comparable to the idea that you had a Release Branch prepared but never merged it to Master, but rather, just merged changes (if any) back to Develop.


So anyway, the biggest limitation to this approach are the following:

  • FixVersion in JIRA suddenly becomes an overloaded Term.
  • This method is limited for a Single JIRA Project.
Specifically, Atlassian realized that using FixVersion for so many different things, especially sprints, was not going to be a good fit for organizations that require some flexibility.  That is one of the core reasons why the Sprint field is a new core field for JIRA Agile.  Also, when a field starts to mean multiple things, 

Organizations can establish JIRA projects in a variety of ways for a variety of reasons.  However, when you have two projects gearing towards a common milestone, a lot of organizations start getting into the habit of having versions of the same name in multiple projects and identify them as the same milestone.

This can lead to a lot of confusion and inflexibility in how a new project can be established.  Also, you're shoehorning an association between two fields that the system doesn't natively support, you're probably using that field wrong.

Soapbox Time:  It's pretty hilarious how we, as developers of software for others to use, really suck at using the tools as they are originally intended.  Shoehorning functionality that doesn't exist "just because we want it that way" either means that we're just using the wrong tool or we honest don't know how we want our processes to function.  

Anyway, if you are still using Versions in this manner in JIRA Agile, I'd be very interested in what you like or don't like about using this method.  Next time, I'm going to cover the more recent JIRA Agile functionality that's be introduced circa 2011 that provide some more flexibility, but still have a lot of limitations.


Tracking Multiple Sprint Teams with a Common Goal

... or rather, a goal that YOU have that you're depending on other teams to accomplish for you...

So one thing I feel that people using JIRA Agile should get used to is the notion of building and breaking down Agile boards for targeted efforts to allow them to track something very specific and eventually just get rid of the board when they're done with it.

Here's a query:

"Epic Link" in (EPIC-1, EPIC-2, EPIC-3, EPIC-4) OR issue in (EPIC-1, EPIC-2, EPIC-3, EPIC-4) OR labels = myEffortLabel ORDER BY Rank ASC


What this query essentially means is "Give me these Epics, give me the Issues in these Epics, and give me any issue that I happen to label it.


This gives you a quick and hopefully, targeted view of a set of milestones in the form of Epics that you and other teams are driving towards. My personal observation is that the majority of teams pretty much ignore epics and epic links anyway, so establishing this linkage to the actual stories that they are working on should have minimal impact.

At the very least, you can keep an eye on the general progress of a concerted effort.

Just remember to clean up after yourself and delete the agile board when it's all said and done!