10,000 Foot Developer

I think I’ve finally found the nicest balance of smaller scale support servers since XPlanner.   It’s taken almost 10 years. XPlanner was the old php-based X-treme project manament web tool used almost exclusively by developers (IMHExperience). It had sprints in it, and even pair tracking.

You might think management has taken over all the Agile/Lean roles and the toolsets behind them. But it hasn’t gone that way completely because someone has to have a need for them — development — and someone has to develop them — development. Across the industry you’ll find every team has an in-team method of tracking software tasks, code, build jobs that fits the dev team’s needs. This will interface with the organization’s decisions on how to manage software at a higher level.

A good example of this are localized kanban boards. While web software like Version One, Greenhopper, Redmine, Trello — etc. — have come on the scene, something happens when you move the scope of the data to the department or organization level — it becomes less useful to the task people. So there are still the old school post-it boards everywhere, with columns ranging from 3 (backlog, in progress, complete) to several that may indicate such things as the path of software through BA’s, DEV, QA’s to release or even environment deployments as well as story and bug status.

My concern is with development.

Usually I have two scopes that are often not met by organizational software:

1. Tracking my own work for myself.  (We all work and problem solve differently.)
2. Having a team-level tool that is not under the purveyance of management.

A Team Support stack will include these:

• Repository
• Tech Wiki
• Versioned Shared Document server
• Defect Tracker
• Project Tracker
• CI Server for building and deploying

I have built these in stacks — tried them on Amazon servers, made VMWare stacks –etc.  I’m looking right now at something called Docker from Opensource — to deploy applications and recreate these stacks.  But dang it the targets move so fast now-a-days.  Even my Fedora development box askes me to update almost every other day.  No easy task — so a decision now has to be for the future too with a team.  I’ve worked with SharePoint, VersionOne, Rally, Jira, Greenhopper, Confluence, MediaWiki, Drupal, WordPress, JSPWiki,  Team Viewer, most of the Rational products, Git, SVN, CVS, Hg, Darcs, TFS, VSS — even that old proprietary repo IBM used to bundle with VisualAge.  I’ve been on teams where we built our own CI servers straight up to now with Jenkins — and would have to look at my CV to even remember half the things I’ve had to use in this space.

Yes,  anyone who things management of software development is cut and dried has probably been at only one company.  But I can’t imagine even now everyone isn’t dumping SVN for Git, or grabbing an Agile project tool.

Finding a perfect stack for team support servers is not an easy task. In my most recent use case, we had off-site developers who finished up their job and were off the project. We needed to reproduce their Git repository and Hudson builds, but no accommodation had been made for the SVN and Jenkins used at our organizational level. So I built a server that had Git, added an electronic Kanban board called Kanboard, and initially a Jenkins server to transfer build jobs (but since we had a git-svn migration procedure eventually did not need this). Running on a Fedora 20 server someone set up for us rather quickly,

Therefore I currently  and *highly* suggest a team setup of:

• GitBlit
• Kanboard
• Jenkins

This will give you repository, build, and tracking capability.

For my own local I run the following. These are not team requirements and I’ve done mentoring to get other team members here as well.  And I’ve learned a lot from others too:

• Fossil
• Kanboard
• Git-SVN in front of all our SVN repositories.

Yes, my OWN local.  Don’t you manage your own work?

Fossil is a really cool tool built by the guy who invented SQLite. It has my own wiki and a bug tracker in it. It also has repository capability — I am trying it out, alone, a good solution for a small project now. Honestly though the lightweight wiki is the best part.

I use Kanboard to track my other stuff because the HTML5 gui is awesome. Now that I’ve gotten better at Git (I love Hg too — there is a bit of an overhead to learn to use these and its advantageous to work with people who know the recipes that work) — I just use Git, its too damn easy to use.

GitBlit gives your team immediate web repository centralization and presence, and is as easy as pie out of the box to use.

And these days, a rudimentary setup of Jenkins (or Hudson) is very simple.

Ease of setup is key for these smaller scale setups. I am not as concerned with infallibility or security. But every level of detail needed (security setups, build complexity, people to maintain etc.) adds another factor or complexity to maintain — which is why departmental stacks like this need build masters.

But at the heart of it all, Java developers *are* the build masters, because we develop the builds. Configuration is half of my job. These tools make it easier and multiply my output and let me get down to some real fun stuff. Of course, sometimes doing all this IS the fun stuff. 🙂

—

XPlanner still seems to be under development, at least from viewing on Codehaus and Sourceforge — it looks like the last update for that project was April 17, 2013.

Tags: ci, continuous integration, fossil, git, gitblit, hudson, jenkins, kanban, kanboard, repository, svn, wiki, xplanner