Wednesday, April 3, 2013

OpenShift Process Tools (for humans)

Making Sausage: It ain't for the faint of stomach

Otto von Bismark is known (among other things) for his observations on law and sausage.  The observation could apply to software as well, but there are lots of us with cast-iron stomachs needed to produce some really wonderful stuff.  If you're one undaunted, read on.

I give a lot of attention to the parts running under an OpenShift service. I want people to be able to run their own service, to understand, configure, tune and diagnose problems with it. But I REALLY want people to understand that, if there's something they want it to do, that it doesn't yet, they don't have to wait for Red Hat to do it for them.

I have a bit of a different position from most people with respect to OpenShift development.  It came about by serendipity, but it suits me well and the management seem happy with it for now.  I'm not actually in the product development hierarchy.  I work on things mostly from the outside.  I work to experience installing and configuring OpenShift as someone from the community, and I comment and report using the same channels the community members have. (I talk about that some in a blog interview with Gordon Haff)

Red Hat has a vested interest in the success of OpenShift, but it defines that interest in terms that go beyond market penetration and adoption rates.  Most of the developers currently work at Red Hat, but they are going out of their way to allow people to see not just the inner workings of the code, but of the process, and to form a community of contributors who help steer and shape what OpenShift becomes.

Building a community is itself a process and there are learning steps so it's not all there yet, but you're invited already.

Where's the Beef?


When I started at Red Hat and began coding, one of the first things I asked was "where do I put my code".  Coming from a background at proprietary software companies I was asking "where's the internal code repository?".  I got a quizzical look for a second and then a reply: "Umm.  Github?" like I'd just asked "Where's the bathroom" while standing at the mirror washing my hands. (Some people use bitbucket or sourceforge or a number of others)

OpenShift has been on Github for quite a while.  It was one of the first big moves to bring OpenShift to the community (the fact that it made life easier for our folks was a warmly anticipated beneficial side effect).  The hottest newest stuff is out there.  It's not always pretty.  If you look at the wiki and blog posts (especially from me) you'll find a number that are out of date because they contained hacks around warts and things have been changed or fixed (it's a good idea to check on the #openshift-dev channel on freenode if you're ever wondering about something).  It's embarrassing sometimes to find something's gone stale, but the alternative is waiting or hiding things, and we're not doing that. (There are people working on the Official Documentation, but that's for Official Releases.  We're talking bleeding edge here)

All of the developers (and by this, I include you) work by forking the repository, making changes on a branch and then submitting a pull request to bring those changes back into the master repository.  The pull requests get review and commentary and then get run through automated tests (discussed next), and when they're ready are merged.

Have it your way.


 The newest move is the switch to using Trello for planning.  OpenShift has always done development using an Agile process based on the Scrum framework.   The project is now hosted on Trello and you're invited to look and contribute.

The OpenShift Origin Broker Scrum Board


Trello is free in the same way that Github is. To contribute, get an account and join the OpenShift organization.  It's a web based scrum task board system.  New features are added to the board as "cards".  The cards are used to define and track the tasks needed to complete the feature.  They're moved along the board from inception to completion as the tasks are defined, filled in, assigned (or assumed) and completed.  All of the planning and work happen in plain sight. 

If you're new to Agile or Scrum you want to take some time to look up what they are and how they work. Scrum is known as a "framework" for a reason.  It's a set of priorities and guidelines, not rules.  Each team has it's own conventions and etiquette.  You'll get the best response from people if you observe a bit and dip your toe in slowly.

Check out Trello's Help site and take the tour for some idea of what Trello itself is and does, and how it works. Take a look too at the first card in the Broker board.  It describes how the OpenShift team is expected to use Trello. Take a look at the story template card.  It show the skeleton of the questions a card should ask (and answer).

A card, still capturing requirements.


The Trello site is a place for  contributors.  It's not a forum or question and answer session.  Those are better served on the OpenShift fora, on IRC or on the mailing lists.  Reasonable suggestions are encouraged. See this one requesting feedback on an update to the PHP cartridge as an example.

Welcome to the kitchen


Well it's hot in here.  The stainless steel doors with the windows in them so the servers don't crash into each other are flapping on their springs behind you.  The knife rack and the prep counter are in front of you.  You know your way around an industrial fridge? All of us bus dishes now and then.  You're a bit overdressed, but get to work we've got some hungry folks out there waiting.  Check that card over your head and start cooking.

Resources









Posted by at 1 comment:
Labels: , , , , , ,
Subscribe to: Posts (Atom)