RTC – Project Planning


Next up on my look at RTC is Project Planning.

This will include how RTC supports the process of planning iterations and releases, task boards, estimation and tracking, backlog management.

Again I will use Jira + GreenHopper as a reference since that is what I use at home, there is other similar tools out there, one example is Mingle from Thoughtworks.

Again this is both subjective (my opinions) and based solely on my experiences from home and work, and I might criticize either for things that is merely a setting you could switch on and of. Un-fortunately It won’t be compared based on the exact same processes, I don’t feel quite the same need for tracking on a spare time project as we do where I work, properly because I don’t believe so much in tracking and estimation using hours and minutes, and I would rather track based on “items”, one of the huge advantages of working without a budget.

Planning Iterations and Releases

Both solutions has a good support for planning iterations and releases, at least to my interpretation.

In JIRA the concept is extremely simple, on the very basic level all you have to work with is “Versions”, in JIRA alone Versions is just a name and a release date, the same concept exists in RTC and is called Releases.

On top of the JIRA versions, GreenHopper adds structure where Versions can be organized in a tree structure, but they are still individually a very simple version, in RTC we add the concept of Timelines and Iterations or Plans which i think is a umbrella term for those and maybe more.

But that is the “data concept” under it all, the more interesting thing is how we can use it, and here things begin to go wrong for RTC.

First of all, what seems to be the “planning tool” is really poor compared to GreenHoppers planning board, and items not assigned to a “plan” seems to get lost which is really bad, one of the reasons here is that your view of this board seems to be bound to a Plan, so the “RTC Planning Board” can only be viewed from the perspective of a Iteration.

Below is a screenshot of the view.

RTC_Planning

Don’t mind the “Estimate, effective estimate” and so on, those are a bit fucked up for us atm. I guess what is really wrong here is that they try to do to much in one view instead of making things more simple. I won’t go into the details, but you can drag and drop items from E.g. the “Release 0.1” iteration and down to one of the sprints as the screenshot shows, you can also select multiple items and do that.

Sprints can be “folded up” and you have some indicators of weather or not a sprint is full, or at least i think. And some progress indicators and so on. And I do think it is also sorted by rank (priority).

GreenHopper takes a different approach, the planning board gives you an overview of all the unreleased planned versions and then all unscheduled issues as displayed as if it was a “unscheduled version”, this makes it really cool and easy to use. Below a screenshot where I also are about do drag an item from unscheduled issues to the planned version 0.1.0.0

JIRA_Planning

The first thing one can see is that it view is much more simple, one could argue that RTC holds the advantage that you can see the items in both the one you drag from and the one you drag to, well fair enough it can in a rare case maybe be an advantage, but if you have prioritized your “backlog” properly, then all you should need to do is drag items from the top until the iteration is released and that should be it.

It also means you don’t need the “parent-child” relation at all, and I actually prefer not to use it although I have added one in the screenshot above just to show how that is displayed.

The only conceptual downside I could think of with GreenHopper is that you can’t have iterations that isn’t also a release, so they all needs to be “released”, but I actually prefer it like that since it forces a version mark for each completed iteration which only makes sense to me, no one is saying that the “release” part means you skip it to the customer.

Task board

The task board is what you use for daily planning, for some that is the scrum meeting, for others something else.

I personally prefer an analog approach to this because it often becomes a million times simpler and does not give issues, but if your working in a distributed team then the analog version won’t work so we have adopted the RTC task board for that. And at home I actually use the GreenHopper task board for item transmissions because it is so easy to use, so even though I prefer the analog version, I have used both systems allot when it comes to this subject.

And ones more RTC disappoints. At first glance it actually seemed to have a really good task board, granted that it is a little more rough in the design (like it was quickly hacked together), and besides the smaller details there is a few major ones which are:

- Task Transitions is broken.
- Spent time is not logged but rather set, and it can’t be set higher than the estimate (or we get a save conflict).

Both things that work excellent in GreenHopper, but lets first take a look at the boards first.

First screenshot is from RTC, and I am in progress of dragging an item.

RTC_Taskboard

The board it self looks ok, the story column is completely unnecessary, but can properly be removed by configuration, the default configuration clearly has it though, and that's not the worst thing, stories is actually placed in that column and can’t be dragged, so It is effectively a column with no real use what so ever. Every item on this board should be an item you can do progress on and close, and in that sense move from left to right.

Drag and drop is completely free, and you can drop an item anywhere you want, be aware however if you drop an item onto another we have experienced it becomes a “sub item” to that one, why anyone would want that to happen on this board eludes me.

A funny detail is that items are arranged a bit random on the board in other browsers (e.g. Chrome) but I did not take a screenshot from that browser as RTC shows it as unsupported, and I think it is silly anyways, like they are trying to mimic the “chaos” that we can have on a analog scrum board.

GreenHopper looks very much like it as the next screenshot shows.

JIRA_Taskboard

there isn’t that annoying column, and drag and drop is somewhat more locked (Items are only dragged in a straight line across), a clear indication of where you are about to drop the item is added.

Column Capacity

I actually randomly discovered this in GreenHopper, it actually also might be possible in RTC, but at least I couldn’t figure it out.

But as this screenshot shows, one can have entire columns colored under certain circumstances.

JIRA_CollumnConstraints

Now why would you want that?

Well the top one (Red) is when a column exceeds a capacity, and on our project that would fit very much into our “closing mentality”, the idea is that we are a number of people on the project, and each person can at max do one task and has to close that before he/she opens the next one and so on, obviously that is very strict.

However our “rule” allowed for a bit of “overhead”, so as an example 6 members mean that we was allowed to have 6 tasks open at once, and because we use pair programming that actually allows for 3 more tasks than needed.

That means that if we at any time had say 7 tasks open, that was in indication of to much “context switching” which generated overhead as well as not focusing on completing tasks, so adding this rule/mentality to the project really helped with the flow.

So back to the board, this feature can help us here since we would have been able to configure the “max capacity” as 6 tasks, and we would have a board that told us when we was in the before mentioned situation.

The bottom one (Yellow) is an indicator for when you go below the minimum capacity, I guess this could be useful in a more “kanban” style board where if the first column suddenly didn’t have many tasks left that was ready to start on, then it would warn about that.

Personally I don’t use any of those at home.

Transitions

So what was this about transitions being broken in RTC?

For both solutions each column in the task board displays items in one or more specific states, so one column can actually contain more than one states.
- So wait, how does the system know what state to put an item into when we move it?

In GreenHopper there is a few ways, the implicit one would be a workflow transition, so the “To Do” column holds 2 states, Open and Reopened but when dragging an item from Closed or Resolved it can only transition into Reopened, so that is the simple implicit one.

But for Open, Reopened and In Progress items going to the 3rd column which holds both Closed and Resolved issues, a Open, Reopened or In Progress item is allowed to transition to both those states, so what do we do?

JIRA_Transition

A “Small” dialog asking what transition you would like, now this may seem a bit annoying if you would use it for your daily scrum or something like that, but when it comes to RTC, well for now stories transition into “deferred” as default, which means you then have to go in and correct their state after.

A Better solution would maybe be to have “drag to areas” that denoted the state you wanted to transition into, but at least GreenHopper has a solution, where it seems RTC falls short, again this can be a configuration bug, if RTC has anyway of doing the same little trick by all means let me know so I can kick the ones managing it!

That said, I don’t use the 2 states in JIRA, so my GreenHopper does only have one state to display in the 3rd column and so the above dialog does not appear in my configuration.

Time Tracking

The next one was time tracking, RTC has a little field below the estimate on its items, we haven’t gotten it to work yet but it seems you have to add up the hours your self as you go along, and it acts as a combo-box where you have a set of predefined values, and finally you can apparently not “use” more time than what you estimated.

So the question is, what is the RTC model even useful for? But might again be one of those things where the Default template from IBM is just inadequate, or maybe our RTC management team that has configured it poorly.

Here you can see the simple one for RTC on the left, and the whole log work thing for JIRA/GreenHopper on the right.

RTC_Spenttime JIRA_Logwork

What happens in JIRA/GreenHopper is far more intrusive, but in the same time that much more useful.

What you get is a menu or a “field button” on your issue, and when you click that you get the dialog shown where you enter in the time you spent and what's left where you have the option to let JIRA/GreenHopper adjust it automatically for you.

The hours is “accumulated” and so everyday you just log the previous days work and it will add it up for you and ultimately show if the issue has gone over time or not. (the little red flag indicates that I am over estimate on this issue)

Estimation and Tracking

Last subject for today, this is not about the Time tracking thing, but rather all the indicators we can get from the different systems.

Below is a series of common graphs you may want to keep tack of, all of them are taken from the “Gadgets” instead of the full size ones… (because I don’t know where to find those in RTC)

The first set is a graph indicating how many Issues/Tasks has been opened vs how many that has been Closed/Resolved over a period of time, the left/top one is from JIRA and the right/bottom one form RTC.

Evidently the JIRA one is much somewhat more useful, at least I think that is obvious. The RTC one simply does not scale with the gadget size, which makes it really small. Also the color area in the JIRA graph gives one a clear indication of weather we are resolving more issues than is created or the other way around, you can see that for most parts I have added more issues than I have resolved.

The graph from JIRA is cumulative while the RTC is not, but they are not exactly the same, just the closest fit I could seem to find. This means that the JIRA one tells us something about the flow in Issues where the RTC just tells us a “number” for that day. I don’t think there is an exact match in RTC to the JIRA one, and when working with Defects the JIRA one can be most valuable, I use it for everything and still find it usefull.

JIRA_CreatedVSResolved RTC_OpenVsClosed

The next ones are a classic, the Burndowns, a simple graph that shows you how your iteration progresses, since I don’t use hourly estimates at home I used an Issue Burndown from JIRA vs. an Hourly from RTC, again the RTC one does not fill the area like the JIRA one does.

Another thing to notice is that they contain different indicators, they both have the “remaining” which is the blue bit dots in RTC and the green line in JIRA, you can se that I tend to add more during an iteration, again an effect of my work style at home, on the RTC one you can se that we are a little bit behind the Ideal line, this line is shown in Red (JIRA) and Brown (RTC).

The blue line in JIRA is hoe many Issues that was created on a specific day, you can se that it adds up quite well to where my “remaining” goes up. RTC has another line which is gray and shows when items are added or pulled from the iteration, you can se we have added a bit about 25% into the sprint.

The green line in RTC is at best comparable to the Brown one in JIRA, well the Brown line in JIRA shows how many Issues I need to close daily to complete, in my situation that is constant at one, that is because there is more days left than there is issues, and one is the minimum it will display. The Green line in RTC shows somewhat the same thing when we look at its angle, but we don’t get a clear indication and it really just draws a line from the number of open hours to the planned complete, so it could be left out and we could still se the same thing.

JIRA has one last little detail, the “remaining” line continues as a dotted line, this is a prediction on how the iteration will end with the current flow, as you can see it predicts that I will have more issues than when I started, this is really just a straight line from the starting point and then through the current remaining work.

JIRA_Burndown RTC_Burndown 

Conclusion

Again, I don’t mean to be harsh at RTC, but there is still a long way for IBM with RTC before they even get remotely close to at least JIRA, and I suspect other solutions out there as well.

And this is just the tip of the ice, and I did not even want to get into the “configuration” interface which from the short time I looked into it looked really horrible from RTC where it is a bit more inviting in JIRA/GreenHopper.

I can’t say that RTC isn’t more flexible, or adds allot of neat stuff, I just haven’t seen anything yet in this part of RTC that is not either as good or better in JIRA/GreenHopper.

author: Jens Melgaard | posted @ Wednesday, April 06, 2011 3:20 PM | Feedback (0)

RTC – Task Management


So back to talking about something that actually interest me a little bit more than simple regular Source Control systems, task management. Note that I will only talk about the web interface for RTC, because from my point of view, this is the only correct interface for these systems, it is light-weight and so on.

Integrating this into either Eclipse or Visual Studio is a huge mistake both IBM and Atlassian insist on doing, but as a developer I don’t want to have this system floating around in my IDE since I won’t use it as much, it’s not like I write 2 classes, then adds a few work items, then writes some more code, creating tasks and implementing stories etc. is for me, different processes, and adding support for both in the same interface just adds noise.

In RTC stories, defects, epics etc. is know as work items, in JIRA it is all referred to as issues and other systems properly have other names, that is not important however, what is important is what we can use these systems for and how well they support that on various levels.

Some primary functions today for me is:

  • Defect/Issue tracking
  • Project Planning
  • Traceability

And so in the next couple of posts ill start talking about the following topics of my own setup vs. RTC

This one will be primarily about Task Management and touch the outer edge of Traceability as I defined it here.

  Home Work
Task Management Atlassian – Jira RTC – Work Items
Planning Atlassian – GreenHopper RTC – Plans
Traceability Atlassian – FishEye RTC – Source Control

So, I added RTC – Source Control, which my last post was about, or well not really.

The thing is that in RTC, the part I will discuss here, seems very tightly integrated into the same part of the RTC system, so here ill talk about how change sets is traced to work items, how change sets is displayed in the web interface and so on.

Just before I get on with this, I just want to add a disclaimer, obviously RTC is highly customizable, so some of the things I will mention might be due to how it is configured where I work, others won’t, and just as well my JIRA experience will be out from a specific configuration (99% the default one), although on JIRA’s side I have access to all the “configuration” since I host my own solution.

It is also important to note that this is not a comparison of features as in the usual way, this is a comparison based on experience, and therefore there will be areas of the system that won’t be discussed in detail if not at all.

The Dash Board and Basic interface

Just a brief note on what meets you in both systems, the dashboard and the whole interface you use to navigate.

Overall I must give JIRA the upper hand here, I just feel much more comfortable here from the very beginning, where in RTC’s I got highly confused since it is a huge mess really, it boils down to the design actually, because JIRA is just so extremely simple in design, which let’s your eyes rest where in RTC there all these small shadows, rounded edges, borders in borders, icons, menus, functions and so on and so on…

You could think they was inspired by JIRA, then wanted to make the design more neat, so they took the gadget boxes as an example, added small rounded edges, some shadow a gradient feel etc. so the gadget box in it self looks better, but when you then put 5 of those boxes side by side it suddenly have the direct opposite effect.

And the default dashboard is filled with all sorts of gadgets you at that point really don’t have a clue in what to to with. There is one single positive thing, and that is a personal little side bar (the Mini Dashboard) where you can add gadgets which will remain there when you navigate your self through the system.

The basic functionality of the dashboard is different and yet the same. In JIRA the main dashboard is kind of a “house wide” dashboard, so you might see multiple projects etc. while in RTC your directed directly into a “Project Dashboard”, normally this wouldn't matter since your most likely to only be on one project at a time, in fact then RTC would be the better approach, but if your not then RTC seem to lack that extra level

JIRA does have sort of a Project “dashboard” as well, but this seems to be “locked” so you can’t edit it’s layout etc, you could have a regular JIRA dashboard for each project though. I can’t really decide what is the best approach overall.

Taken the customers perspective however, I could never imagine you exposing your customers to the RTC interface so they could report bug’s etc. directly because of how it is put together, in JIRA, it seems only natural to do this if you can engage your customers/users in using it, so with that in mind JIRA.

Overall the JIRA one just looks much better and the whole interface is easier to navigate from the beginning.

Task Management

So lets start here, with task management.

In JIRA these things are all managed as Issues, because JIRA started out with being a basic Issue/Bug tracking system I assume, and has since then evolved, but today this is just an umbrella above all kinds of tasks as Defects/Issues, Stories, Features/Epics and so on. In RTC this is know as a Work Item, but they serve the same purpose.

And hands down, so far there is almost no single thing that RTC does better that JIRA in this area, on the contrary. It has many of the same basic concepts about workflows ect. which is the good parts, but yet again RTC has managed to provide us with a non-intuitive and really bad interface to manage these things in.

The very few good parts is that the search displays results as you type, and the easy shortcut to create work items doesn’t require you to select from a dropdown which JIRA does, although you can hear how minor these advantages are.

The Work item and Issue Page

There is so many things to say here and I just don’t know where to start or end.

But lets start with a couple of screenshots of the entry page of an Issue (Left) or a Work Item (Right), I have chosen to begin the process of adding a comment in both.

 JIRA_Issue RTC_WorkItem

One huge advantage of JIRA here is clearly the “lightly” presentation if you ask me, of coarse part of this is because you can edit a Work item on the same page as you view it in RTC, causing some very odd workflows, but ask your self this, should you really be editing all these fields all that often that they should be directly editable from here?

Some of the fields you might defend this workflow with would be the Work Item State and Time Remaining etc. But these are all changed as part of workflows in JIRA/GreenHopper and not by “editing” the Issue, which is a way better way to work with the few fields, to some extend at least, RTC also allows you to edit these through workflows.

both systems has a range of tabs, in JIRA these are placed bellow all the essential information about an Issue and allows you to navigate between them and still see the essential information, in RTC they are at the top and you won’t be able to view the essential stuff when navigating away from the Overview tab.

Links, Tracing, Builds ect.

These things are also handled quite different.

Links in JIRA only relates to other Issues and allows you to link between duplicates, create story/feature relationships and so on, in RTC a link is much more generic than that, tracking to code is also done through links and I assume that builds and so on is the same deal, this also means that tracking to source seems weaker in RTC or leaves the user to navigate more to get the same information.

In JIRA the source tabs provide you with tracking to the source code, it does however require FishEye to work, but then rather than giving you a link to a change set, it gives you much more information as well as some basic functions which makes it faster to track your code changes.

JIRA_SourceLinkRTC_SourceLink  

I Hope it’s fairly easy to see the value of all that extra information your given right there, if not you properly have never been in a situation where you needed it. It also gives you an extra bunch of functions.

Not only is it presented better here, and there is shortcuts here, but when going into FishEye it is also better in many ways although RTC does give you quite some of the same things to work with, but ill do that comparison more in depth in a later post.

For builds I won’t be able to give you an example since we don’t use it in RTC and nor do i use Atlassians build engine (Bamboo).

History / Activity

JIRA views almost anything as a change it needs to record, that be edited fields, change sets from source control, builds, history, work log etc. that means you can get a very clear view of what has happened on the issue, the tabs is actually merely filters on the entire sets of activities.

In RTC history seems to be more concerned about what has happened directly on the work order, and anything else you can find somewhere else, obviously leaving more digging for you.

Again, JIRA also has a better design that makes these changes easier to read where in RTC this is in slightly visible tables which confuses the eye.

There isn’t much more to say about that, and I don’t feel a need to show a screen shot on this part.

Conclusion

Now at the end of the day this is a subjective review taking the systems from my perspective, but I personally do like JIRA way better than RTC, and the above is just a scratch on the surface, I could go on and on about small details, workflows and so on, but this post would be a mile long if i did.

Many of you might say that I should use the Eclipse client instead of the Web interface because it is designed better, but if that is the case then that's just another failure to add to it all, this should work in web, it is the perfect client for making these systems if you ask me, and Atlassian has so far done a bang of a job showing us that a web interface can work.

And judging from screenshots from other products in this area, it seems like they understand that web is the thing as well. And as long as IBM insist on weighted it’s Eclipse client over all, then they will never succeed with this in my eyes, and I am guessing they won’t since they even base there installers on Eclipse which is a shocking fact, never have I seen anyone succeed in overcomplicated the task of installing something as IBM has.

Even Microsoft's Horrific SQL Server installers are much more simple, and here we are talking server software where you to some extend can forgive Microsoft for making it complicated. RTC for me is a Client for a Source control, sure the installer for the RTC Server may be requiring allot of settings, but the client?…

Only one thing to say about that… Really IBM?… Really?… I mean… Really?

It’s only a good contribution to the software industry in terms of “Let us show you what you should never ever do”.

author: Jens Melgaard | posted @ Tuesday, March 08, 2011 4:12 PM | Feedback (0)

RTC - Source Control


Back on my original team, and I am now using RTC/Jazz (I will use the term RTC-SC for it’s source control part) on a daily basis, and let me first say that it is a major relief compared to CC/CQ.

Anyways, this post will be about the Source Control in RTC, specifically the Visual Studio 2008/2010 integration.

The basics, The model

Lets first talk a little about the model for the Source Control and it’s basics.

First of all, we have a full-blown change-set based source control, not change sets as they are emulated in SVN but sets you can easily remove, mix, add and so on, and the commits are atomic so if a commit fails midway, it won’t affect anything, you can just redo it as in any other decent Source Control system.

This also means that updates etc. is rather quick, since we no longer need to go through the entire “repository” of files that all the change sets put together create. Streams which is the basic concept many knows as Branches, puts together lists of change sets, also any stream can change flow targets which is the concept of where changes in one stream are delivered do, much like merging two streams.

In the way it’s all put together, it may seem like they have taken much inspiration from the distributed source control model, there is just an exception to that, RTC-SC is not distributed. There is so many small things that may indicate it is and could be, but RTC-SC is a Distributed model wrapped inside a Server in a Client – Server model, which just seems like a really odd choice.

RTC-SC Servers can be at dispersed locations, and work together, creating a distribution of the source repository, but your still dependable on having a server to access, where as in a real distributed model, you are your own server.

It does however not matter so much, it just means that RTC-SC is not ideal for the part of the Open Source world where thousands of developers goes in their own desired directions, still allowing others to pull their changes. In a business/corporate sense, this isn’t a desirable model, many might say that they use a fully distributed source control, and that is what they needed, my bet is that they still use it just as if it was a Client Server model.

So all in all the RTC-SC model serves us well, some cases the ability to freely change flow targets etc. makes sense, in others it doesn’t, the important part is that it’s there without being forced on you, at least as far as I'm aware.

Workspaces and Sandboxes

One of the thing that makes RTC-SC so obviously a client server solution is the way sandboxes relates to workspaces which exists on the server, a Workspace is essential a backed up version of your sandbox, so the server is fully aware of your sandbox more or less, depending on the tools you use and their settings, changes is either automatically committed to your workspace, or kept in your sandbox until you choose to commit them to your workspace, essentially keeping your changes under backup on the server.

A workspace is essentially a light weight stream as such, each commit to your workspace won’t create a change set, only when you deliver changes from your workspace to a targeted stream will one or more change set be created, this is also where RTC-SC gets a little bloated or over-engineered. The way you can manage your change sets prior to a delivery just seems like an implementation which has given me a bunch of unnecessary choices.

At the end of the day, when you locally creates a bunch of changes, how can you separate them up in smaller pieces that ensures the quality? Short answer is that you can’t and is why I am against it. A longer answer reveals that it is possible, if you suspend the change sets, only having one of them active at a time and performs full tests on them independent of each other, question is, why would you even consider doing that? Well some might say that they work on two different parts of a system that is unrelated, then my question is why are you doing that? It is highly counter productive to have a high amount of context switching during a day of work, so you shouldn’t work on different things unless you really have to, and in this case it would be enough to “suspend” your current work, and then fix whatever impediment was in the way, and then resume, having multiple active change sets seems irrelevant again.

The good thing is that this doesn’t give any obstructions if you don’t wish to use it, the feature is there for you to leave it alone. And the feature might be there because you can “suspend” change sets, yet they are still there, so if that's what they had to do to implement that, then ok i can live with it, so it is merely a theoretical annoyance.

Pending Changes and Change Notifications

This is one of those totally un-necessary features that you just kind of grow to like, well apart from the extremely annoying “pop-up” I get down in the corner, which I am sure that can be disabled, however I’m just to stupid to find out where. Change notifications is very neat, I mostly don’t have to concern my self with the question “is there new changes I should get?” since I man directly notified about them in my RTC-SC Visual Studio Pending Changes view, where I can choose to accept them all at once or one at a time.

So that is kind of cool, sadly local changes aren’t discovered quite as well, and unless I make a change in Visual Studio, getting RTC to notice a change becomes a bit of a pain really, Tortoise SVN just pick those things right up with no hassle, I am not sure why the new “IN!” for many source control integrations is that you see all you need from your IDE, the world has never and will never be like that, there are tons of files we still manage directly in explorer.

After all, a software project is much more than just code, and one should hope IBM knows that, otherwise it gets very understandable why their applications normally is completely unusable, and I have no clue how they then managed to make RTC/Jazz to stand out.

Another thing is that RTC-SC sometimes displays some dialogs warning me that accepting incoming changes might overwrite some of my changes in my local sandbox, this is actually a pretty huge deal when you think about it, It must NEVER delete any local changes, it may register it as a conflict and then offer me the option to merge it, but overwrite the files would be an extremely bad thing, and I hope they get this fixed although it haven’t proven to be an issue yet, which is just pure luck. Also there is a really easy workaround, just commit changes before accepting incoming change sets, some times I have thought about enabling the “auto commit” feature doe to this, but it wouldn’t work for files outside my IDE, so not sure it would help.

Task Tracking Integration

They way you have to associate work items becomes a bit of an awkward task compared to both TFS and AnkhSVN’s Issue Tab, but the amount of steps isn't that different. It also allows you to associate several work items with a change set.

The comment field is poorly choosen to be a “Node” in the tree though, and this easily becomes a big annoyance ones a “one liner” comment isn’t enough anymore, or if you want your comments to naturally bind to the “work item”, they way I do that in AnkhSVN combined with Jira is so easy and it lets me write the association as a part of the text.

I Also often add “bullets” (dashes) to my commit comments into SVN/Jira, and I can even write comments using the confluence Wiki markup if I wish, that is a little over the top for me, but actually I could write my bullets to have a better formatting that way, although a very small thing. But since RTC-SC only doesn’t allow you to put in multiple lines this is in fact impossible, I wouldn't be able to replicate that usage (If that is wrong, oh please tell my how I add multiple lines!).

And while I can add the comments to the work items, this is an annoying workaround and won’t even be as helpful in many cases when back tracking changes in case you have several commits within a single work item which I don’t see as unusual, on the contrary I commit as often as I can at home ones I am sure it doesn’t have an impact. (Continuous Integration remember?)

But that said, for all intend it works.

The smaller stuff

There is plenty of small annoyances, small bugs, some of the fun ones is dialogs that claims then are 236% complete with a chunk of work, well ok… but why are you still hanging there blocking me then? But this is merely just fun to see, since it doesn’t really matter, it doesn’t break your code, it doesn’t delete your files.

Conclusion

At the end of the day, there is plenty of things one can criticize about RTC-SC, but in ones daily work, it won’t get in the way of your tasks, so all in all it is a solution I can accept, and it even gives a few advantages over E.g. TFS and SVN, but not to neglect that it also brings disadvantages.

But for any solution there is Advantages and Disadvantages, and it is hard not to admit that ClearCase has something to do with the acceptance of RTC as well, after all when you have tried ClearCase, you would accept about anything, even CVS becomes a dear friend.

Another disclaimer! and this is important, I mention things as Atomic Commits, Change Sets, Fast Updates ect. as “Positive things” about RTC, but lets REMEMBER! that for those of us that has used SVN, TFS, Git, Mercurial etc. These things are something we have been taking for granted in ANY SC, so these are not revolutionary, on the contrary, it is shameful that it has taken IBM so long to get there, so they have nothing to be proud about with those.

author: Jens Melgaard | posted @ Wednesday, February 09, 2011 3:39 PM | Feedback (0)

Rational Team Concert – Sneak Peak


So been working with my own “ALM” setup at home, talked about that in my previous post and I really enjoy this suite, at work we used ClearCase/ClearQuest and I have tried TFS as well, and CVS+obscure tools, CVS only covers the source control part, had Census and others for Issues, Excel and others for Product backlog, Access databases for Risk management, you name it, tried a lot before that.

But IBM admitted as well as our organization that CC/CQ didn’t really fit our needs as an agile company, so we started looking for a replacement, I have already blogged about this previously, and that I didn’t think that other products under review got a fair chance, surprisingly enough I meet more and more people within the company that would have loved moving to a SVN/Jira etc. based suite, so why we went with RTC becomes a bigger mystery to me every day.

But then again, someone choose CC/CQ, and having invested countless licenses in that made IBM give us a good offer, so I guess this is all about being able to say that the CC/CQ Licenses wasn’t a complete waste and that it was still a good choice, from the bottom line there is no damn difference, someone screwed up and they are just trying to put a few flowers in the shit to make it look better.

But anyways. RTC it is.

The Silver Bullet?

IBM sure seems to think so, but I don’t. And some of there employees etc. have an intolerable arrogant attitude towards it, especially when these things are not matter of cold facts but opinions.

I have to put a disclaimer out there for this post, I am not currently using RTC daily, since I am currently helping another project, once I get back to my own team I will be fully engulfed in it.

So our project are beginning to move to RTC as some of the first ones, maintaining CCNet as build server for many projects however, the built in just seems extremely limited so far, besides we have far to much time invested in CCNet already to re-implement it all in an IBM world, and I don’t want to move everything into it either, ultimately locking us self completely to IBM.

With any background in ClearCase/ClearQuest, RTC is a revolution, and some times I tend to think that some people are unaware about a world outside that product, at least when they speak about how wonderful RTC is.

It definitely has it’s pitfalls as well, from huge to small ones. The major mistake can be cooked down to:

”Over Engineered”

That sounds harsh, but it is not in RTC’s case, but this is mostly IBM’s history.

However, there is plenty of good stuff as well, so don’t worry, it won’t all be “RTC Sucks”, for now this is it from me, the following couple of weeks/months I will cover various aspects of RTC and my experience with it, highlighting the things I think is good and bad about it, but It is far to much to cover in a single post, so I will divide it into several posts.

There will be 4 main subjects:

  • Source Control – Compared against TFS/SVN and Mercurial.
  • Issue Tracking – Compared against Jira and FishEye.
  • Project Planning – Compared against GreenHopper for Jira.
  • Cost – Maintenance and Initial compared to an Jira/Svn ect. counterpart.

If each subject will get a single post or several posts covering minor parts of the subject is uncertain at this point.

author: Jens Melgaard | posted @ Wednesday, January 19, 2011 12:58 PM | Feedback (0)

New “ALM” Server Setup


Just a little about my own “ALM” suite of Jira/GreenHopper/FishEye/SVN/CCnet, since I moved it all over to run on my ESXi server instead of my old ATOM based server since it couldn't really handle the load.

Vault: The Subversion Server

SVN runs on CentOS 5.5 using CollabNets Edge distribution.

It is SVN made easier to manage, but they have some work to do still. They are going in the right direction, just seems like they didn’t have time to make it all super sweet right from the start, I don’t necessarily like that they somewhat make a very tight integration to their own Issue Tracking and SVN browser, your not forced to use it but it is "visible” in the SVN configuration interface, so a minor annoying thing.

In the long run I could hope for some “REST” interfaces so we can one-shot the entire process of creating a project, much like you do in TFS and RTC, but it’s not like it takes more than 5 minutes to put up a new repository and another 5 minutes to add users, ok depending on how many users and other factors as well obviously.

(To my knowledge there is no REST API’s for it, but correct me if I am wrong, I would love to know about them)

Aurora: Jira, GreenHopper, FishEye and Confluence

Jira (and GreenHopper), Conflience, FishEye runs on a Windows 2008 server and all but FishEye uses a SQL Server 2008 Database, Datacenter edition. FishEye runs on PostgreSQL, all in the same virtual instance.

Could have hosted all the Atlassian products on a Linux based platform as well to save that license, but I am more familiar with Windows servers when all comes down to it.

Build servers (Currently Un-named): CruiseControl.NET 1.5

3 x Windows 2008 Servers, the idea is to make an attempt of develop some sort of “shared” resources or remote agents if you will for CCNet, lets see if I ever get that far, idea is to be able to scale out, instead of just focusing on the iron, we have several projects using CCNet at work, and some of them has build timings that just doesn’t support CI, I wanted to see if I can make a more “Generic solution” to solve this.

I have already had the pleasure working with a solution to scale-out parts of CCNet out, but it is a very limited solution which doesn’t even use CCNet as base server for the nodes.

I Know there is many other CI-Servers out there, but there is more important things now than moving to one of those and implementing allot of other stuff into them.

Missing Stuff

You might notice that the “media server” is missing from my ATOM based setup if you read that post, well my QNAP NAS has a built in UPnP/DLNA server which is more than enough for my needs.

Conclusion

There is no doubt that my setup is overkill for my needs, but it has given me loads of experience in managing ESXi along the side, and Virtualization is really fun to play around with. This is something I can use at work as well so that is the main drive behind it all.

author: Jens Melgaard | posted @ Wednesday, January 19, 2011 12:42 PM | Feedback (0)

Going Virtual - Pictures


As promised, a few more pictures:

IMG_0050_sIMG_0048_sIMG_0060_s

IMG_0046_sIMG_0043_sIMG_0044_s

The old pictures:

   

 

 

author: Jens Melgaard | posted @ Thursday, December 02, 2010 10:23 AM | Feedback (0)

Going Virtual - Starting on a new world.


So finally the final pieces for the server arrived and I got started on this new world, playing with my new toy, because lets face it, it is what it is, a very expensive toy for me, but it is not that bad really, something someone on the ESXi forums got me thinking about, so lets evaluate:

Hardware Price

(Final) server configuration:

Total price: ~ $5,400

Dell PowerEdge T610 Similar configuration (As close as I could get, yet lesser): ~ $9,700
- And added to that would be some modifications which would lower the noise a standard Dell system produces.

Installation Price

That is not said “Go out build your own system” because there is very obvious drawbacks to that, first of all the time it would cost to install the system your self would in a company easily eat up a major part of that difference, that “cost” is just not relevant to me since this is a spare time thing and I like to play around with hardware, and even here you NEED to know what your doing, if you have NEVER put a server together before or maybe even worse, a computer, then you risk making things much more expensive as well. I had tried both, although it has been some time since I put a server together, actually that dates back to my Dual PIII 1GHz machine (which I still have, although not running anymore).

There is also the the fact that Dell machines has been tested ect. so as you get the system you can be fairly sure it “runs”, where is I could have been unlucky and getting a broken component I would have to return for replacement. The base delivery time is somewhat the same though

Warranty

The person from the “VMware” forum also though he would be smart to mention all the different “warranty” agreement's you agree to, but that is not really an issue here when you can buy all pieces from the same retailer since they will manage that for the first 2 years, from that point on you would be better set with dell for an additional year, they are also kind enough to pick it up and bring it back to you.

But on the other side I have 5 or more years warranty on some of the components, the memory modules even have Lifetime Warranty, ok that is to be taken a little lightly because we all know that in 10 years this server will properly be long gone, besides for some vendors Lifetime warranty is not really what you would think it was, but at least it is more than 3 years, and after those 3 years I am fairly sure Dell won’t help you, but I can’t be sure that you can’t get parts replaced after that.

Total Cost

So there is significant drawbacks to what I choose if you’re a company that is about to invest, and in that case I would aslo recommend Dell, IBM or another vendor that delivers complete systems, because the time spent within those bounds will be more expensive.

As a private person, I would evaluate if I had the guts and wanted to use the time on it. At the end of the day in the most common cases I would properly still say Dell etc.

Installing the Server

I Will post some final pictures with the new Raid controller and extra memory modules another day, but for now lets talk a little about installing VMware ESXi.

Here I must give you a reference to: http://www.vladan.fr/how-to-install-esxi-40-on-usb-memory-key/

This is a guide on how you install ESXi 4.0 on a USB key from another OS before you start your server, many says that it is just as easy to “install” it on a USB key using a CD, but first of all I did not have a DVD-Rom drive for my server that would work for me, our of 3 drives I had lying around only one of them would actually let me boot from a CD but it was not compatible with ESXi 4.1.

You might need a way to format your USB key as someone mentions in the comments, the one he links however is not compatible with a 64 bit OS, I used this one which is just a newer version: http://www.x-drivers.com/catalog/benchmarking/hdd_ssd_flash/companies/hp/models/usb_disk_storage/19919.html.

Also note, as some says in the comments, you need to unpack and use the “imagedd.bz2” file from the new installer ISO image rather than the one he describes in his post.

But besides that, it takes quite some time to load it all from a CD when starting the first time, in time it actually turns out to be much faster to follow the instructions in the link I posted, that took about 15 minutes and then I could successfully boot ESXi 4.1 on my server and instantly start using it.

This is important for me to mention since in comparison to my Microsoft Hyper-V Server experience this was really easy, understatement of the year actually. This felt like plug and play somehow, I could never have dreamt setting up any kind of server would be just that easy.

After that you can enter the server using the computer name or its IP address in a simple browser and that should get you started.

Adding virtual Machines

This is really easy with VMware and there is several ways of doing it, and properly more than I know of.

I Guess the most general way is to use the “New Virtual Machine…” wizard accessed from the file menu, this lets you configure a new empty Virtual Machine where you can install an OS as you normally would during first time boot of a computer, this is the only way I could figure out adding virtual machines using the Hyper-V Manager for Microsoft Hyper-V Server which had the limitation that the physical server had to have direct access to the iso image.

This is not true for VMware, you can during configuration of the VM choose this option, but you can also choose to boot from a client mounted iso really easy, meaning you can install your VM having all the necessary data on your local machine where you manages your ESXi server from, In a huge consolidated environment where you have several ESX servers backed up by a SAN it will make sense having images stored along side of that.

For smaller installations I would say the above approach is more desirable, and certainly for my private setup even though I have a NAS that I could use as a iSCSI target for the ESXi server.

I don’t prefer to use the above approach however, instead I like to use VMware Player to create my Images, this feels a bit faster to me and it lets you “silently” install the OS on your image without requiring input from you, I guess the speed of it is mostly to do with my workstation which is packed with 480GB of SSD drives.

After that I use the VMware vCenter Converter to load the images into the ESXi, this also means I have a clean backup of the images right away, something I would have to do the reverse way with a direct installation.

One thing that was REALLY nice was that I could directly convert my old server which was a physical machine using this tool, that took over 8 hours however, but I was still impressed about just how easy that was, point out it’s IP address or host name, enter the username to run under and make sure the firewall don’t block anything, and that is it! almost anyways… Make sure not to have any mapped network drives though because it seems like VMware want’s to convert those as well, and if your server points out a 14 Terabyte drive (My NAS), then VMware will complain.

Back to it all

Anyways, Ill get back to installing a number of virtual machines, so far the plan is:

  • 1 x Windows Server 2008 Standard (SQL Server 2008)
  • 3 x Windows Server 2008 Standard (Build Server Nodes, CCNet)
  • 1 x Windows Server 2008 Standard (Master Build Server, CCNet)
  • 1 x Zentyal Server 2.0.2, Ubuntu Lucid 10.04 (Domain Controller, Open LDAP Server)
  • 1 x CentOS 5.5 (CollabNet Subversion Edge Server)
  • 2 x Windows 7 (Test machines)
  • 1 x Windows Vista (Old server, only during Transition)

So I have enough to look at.

And yes, that is CRAZY as hell for a private setup.

author: Jens Melgaard | posted @ Thursday, November 25, 2010 9:54 PM | Feedback (5)

Going Virtual - (Update) Raid Controller Hunt


So ASUS could not supply the PIKE card, which is a real shame since it would save up allot of space, but now I have to run with a more regular solution, ordering a LSI MegaRAID SAS 9260-8i kit (Raid card with connectors for 8 SATA drives), rather expensive but according to people on the the VMware forums that is the “safe” bet rather than a much less expensive Adaptec RAID 2805 card.

So the new specs are:

author: Jens Melgaard | posted @ Thursday, November 11, 2010 10:48 AM | Feedback (0)

Going Virtual - Microsoft Hyper-V Server vs. VMware ESXi


In a bit of a crazed moment I ended up deciding to “GO VIRTUAL” at home as a replacement for my small ATOM server, at the end of the day it simply had a hard time handling what I threw at it which was:

  • Build Server
  • Jira
  • Confluence
  • FishEye
  • Crowd
  • Database Server (MSSQL Server)
  • SVN Server
  • Media Server

Somewhere I guess that is fair enough, that is after all quite a load for such a small computer and it wasn’t meant for it. One major advantage id hat though was it’s low power consumption, it wasn’t that low compared to what you can do today, even with a small Intel i3 system, however it was still low.

My new server has little less emphasis on this particular view.

New Dual Xeon Server

So the new server currently consists of the following hardware:

(Final) server configuration:

Note that the Datasheet from the chassis page is incorrect, it is a different chassis, and for me it was worth noting that it was actually not only nearly 50 cm’s long, but 70 cm.

I had to order a hardware raid controller as well, I will talk about why later in the post but for now I can say that is the ASUS Pike 1078E, it is meant for SAS raids, but it supports SATA as well which is what I am going to use it for, the storage is mostly “Temporary” until SSD disks will drop to a decent price/GB level late this year or early next year when Intel and others should throw their next generation SSD disks on market.

I Must say that I like the design ASUS went with on the controller add in, it is small and out of the way, an all the ports is then on the motherboard. I Like that but how it compares to other Raid controllers performance wide I don’t know.

Small surprises

Ones I finally got the Chassis a small surprise was waiting for me, the Intel SC5600 Chassis come with a EEB SSI 24 pin connector for the system panel, the ASUS Z8PE-D12X does not come with such a connector, instead it has normal System panel connector (as most ATX boards) and a Auxiliary Panel connector.

Here is a small “diagram” over the difference between the two where one can easily se the problem.

Connector

So I had to make a little adapter my self, this wasn’t to difficult, however I haven’t connected all of the functions, just what the most obvious and what I needed most, so it is worth mentioning if anyone should invest in a similar setup, you should maybe find another Case or another Board.

Here is a little picture from one end, couldn’t get a proper picture of all the little connectors going to the motherboard, so this will have to do.

IMG_0037

And yes it works…

Hardware Conclusion

Besides that little surprise, the Chassis is very well constructed, the board could maybe have a better layout when talking airflow, but the processors is nearly kept at room temperature, thanks to the large coolers and low TDP.

Here is a few more pictures.

Outside look:

Inside Look:

Software – Virtualization

The idea was now to Install VMware ESXi, mostly because I am familiar with ESX from work, so that seemed like the obvious choice, ESXi can be downloaded free, there is some limits to the free edition however, but for a personal perspective, none that really matters.

At work we only have the licensed version in order to automate deployment etc. of software on images, this kind of automation is not supported in the free edition, I will use it for running a number of Linux/Windows servers, so having to use the GUI for all tasks is ok.

VMware ESXi and problems

Things can never go smooth can they, and so I ran in to problems installing ESXi, and this is where we get back to the “Why Hardware RAID” from the top, the thing is, ESX and ESXi does not have driver support for Raid controllers using Software RAID, in most cases that is ok since normally you wouldn't want to use your primary CPU’s for supporting the raid, instead you want to use as much of those for the VM’s, however for a little private setup, that would be ok.

But on ESXi this is a solid no no, the alternative was to use the disks separately, but I wanted a Raid 1+0 setup for reliability.

So basically ESXi was “no-go” for now.

The alternative – Microsoft Hyper-V Server 2008

the Hyper-V server from Microsoft is also free, you need licenses for the better “management” solutions but I could get started at the same price as ESXi, 0$ so that sounded really good, and from what I could read it was becoming a good competitor to VMware ESXi and it supported my software RAID.

The installation went well and after an hour or so I was in the OS and ready to configure, and here is where it gets a bit annoying because you have to configure the Windows Firewall mostly your self, there is some shortcuts to enabling the Remote Management, but they don’t do the trick entirely, I ended up disabling the firewall completely.

http://msmvps.com/blogs/russel/archive/2008/10/22/configuring-hyper-v-server-for-remote-management.aspx

This posts says that is a “bad” idea, but why is that? lets face it, my internal network is already behind a firewall, having one in the here just seemed redundant. And if you think about this in a larger context, then in a company network you are most definitely behind a firewall, so WHY is that a bad idea? I don’t really se the point in redundant firewalls doing the same if your network is secure, and if one manages to breach the first firewall in such a network, I highly doubt that the windows built in firewall will stop or even slow him/her down.

Anyways, if you can get the above to work instead I guess you should go with that.

Remote Management

This is where things get even worse, compared to vSphere Client and vCenter converter the Hyper-V Manager is just really lacking in my honest opinion. This may obviously be because I am so use to the vSphere Client.

Anyways, after loads of trying I managed to get a Virtual Machine up and running, but by now I had already made the decision to go back to ESXi and so I ordered the ASUS PIKE Raid controller that ESXi should work with (at least I have seen people on the VMware forum getting it work).

So this is where my Virtualization adventure ends for now, waiting for the Raid controller to arrive, which will be up to 14 days according to the only place I could find it in DK, so this is it for now. Ones the controller arrives and I can get some VM’s running I will most likely make another post.

NOTE! Any sort of bashing at Microsoft Hyper-V Server is from a personal perspective and is therefore not an objective conclusion, I urge you to realize this before posting all your “But Hyper-V Server works really well, and your just not doing it right”… Hyper-V Server can be the right solution for some, but it is not the one for me, period!.

author: Jens Melgaard | posted @ Wednesday, November 03, 2010 11:08 AM | Feedback (0)

Moving – From Renter to Owner


Ones again I have been silent here on my blog.

Well this time it has it’s reasons, a little over a month ago I bought a new Apartment, so I have been moving and moving… and… moving a little more. I can tell you this, I will NEVER move my stuff by my self again, next time I will pay people to do it!…

An empty apartment

But one thing is packing, moving and then unpacking, another thing is living without furniture's! Yes that’s right, I don’t have a couch, a desk, shelves and so on, all I have is my old bed, an old dinner table (which is used as my desk now), and then my new dinner table.

So with 100m2, my apartment is rather empty!… but that is how things is for now and another month.

The reason is not that I could not afford new stuff, or that I didn’t have anything before, I had a couch, I had a desk etc. but it just didn’t fit in, so I went to an interior designer to get help with new furniture's etc. But the thing is, it takes 8 weeks to manufacture and deliver, so that is the real reason. I am just waiting for all my new furniture's to arrive.

Anyways, I didn’t have much else to write about just now, so I wanted to add a post.

Pictures

 

More under: http://www.dotjem.com/gallery/26.aspx

author: Jens Melgaard | posted @ Thursday, September 09, 2010 9:40 AM | Feedback (0)

Copyright © 2009 Jens Melgaard. Except where otherwise noted, this work is licensed under the Creative Commons Attribution 3.0 License.
This blog is based on Subtext 2.1