Tag: JetBrains

Posted on
by

TLDR; Upgrading YouTrack to 7.0 and getting a “Failed to execute refactoring for entity type: Event” memory error in the Hub upgrade? Add more physical RAM, then add some more, with maybe a little more on top. YT 7.0 upgrade process is memory hungry.

If you’ve read the previous posts on this site, scrolled through my Twitter feed, or spoken to me about issue management, continuous integration, delivery or deployment, then you’ll have probably heard me talk about the Jetbrains product, YouTrack. Heck, I even used it to ticket-manage my wedding back in 2014!

YouTrack is, in a nutshell:

Easy-to-use, fully customisable issue tracking and agile project management tool your development team will love.

(Those are Jetbrain’s words) – and they’re right. It is easy to use and your dev team will love it. Especially if you’ve made them use other management tools, especially that one beginning with a ‘J’. Ouch.

Anyhow, We’ve been running YouTrack 6.5 as a standalone JAR instance, on a linux box, for quite some time. The recent announcement of YouTrack 7.0 with it’s enhanced agile boards and other wonderful improvements meant I was quite looking forward to updating. Along comes the fateful day and having taken another backup (never hurts to have multiple backups) we took the service down and started the upgrade.

Continue reading →

Posted on
by

Before the blog starts to whitter on about new tech, new application purchases, features and functionality found and how use of tech has helped or hindered me it’s probably useful to get a baseline written of what tech I currently have and what I use day to day.

First off, desktop computers.

  • At home it’s a 27″ Apple Mac.
  • At work, a Dell Optiplex running Windows 7

The Mac also runs Parallels, which through the use of a Watchguard VPN allows me to connect Outlook to my work mailbox. My own personal mail is collected in Mail on the Mac. At work I’m a Development Director for a software company so most of my time is spent in Visual Studio 2010 and now 2012, Outlook and YouTrack, our bug tracking/ticket software from JetBrains.

Continue reading →

Posted on
by

As almost all developers will know, in a commercial development team, work is handed out in the form of tickets. Each ticket, in my view, represents a single piece of work and no ticket should cross the streams (or subsystems.) ie; the ticket shouldn’t contain requirements for changes to both the code and the database, as this is, in my opinion, two separate tickets that are related to each other (or, the code ticket depends on the database ticket – see the logic?)

Up until recently we’ve been assigning tickets to devs and discussing with them which tickets are next on their list, going by priority, ticket-type etc. Whilst this worked in some cases, in others it didn’t as the priority wasn’t clear enough and developers tended to cherry pick the best tickets first, as opposed to the most important, or they hadn’t written them down or something else came up that was more important and the list was thrown out the window.

Continue reading →

Posted on
by

I love Build Radiators. The ability to pass information to a team of developers easily and immediately is far and above one of the most important things any CI method needs to do. (Apart from manage the whole Continuous Integration model)

Ever since we plugged in the Continuous Integration tool that is TeamCity I have been totally immersed in the world of Build Radiators, otherwise known as Build Status Screens or Build Notifiers (or the big red light that flashes whenever a build fails).

Continue reading →

Posted on
by

The speed at which a rewrite project goes is often a very big factor in deciding whether or not it will be successful, and it’s often one of the most overlooked elements of a rewrite project.

Speed influences so many factors of a rewrite project it’s difficult to list them all in one article so for now we’ll approach them one at a time. In this post I’m going to look at the speed at which a rewrite might adopt new tools into their overall build process, but the same core message applies to almost every aspect of a rewrite, and I’m hoping that the title of this post indicates what I’m trying to get to…

Developers on a rewrite project should do it slowly.

Continue reading →