Tea and Cake

At work we use Git for managing our source and Buildbot for tracking our tests, be they unit, functional, acceptance, or simply lint-like tests such as pyflakes. The development life-cycle I have implemented which is serving us well is modelled on the Ultimate Quality Development System, Basically;

1. A ticket is raised in the ticket system (in our case rally).
2. The ticket is accepted into a sprint.
3. A branch is created, and the work is done
4. The branch is peer-reviewed and feedback is given
5. The branch is accepted by the business*
6. The branch is merged back into master

..Fairly straight forward, *I grouped QA/AT/etc into ‘accepted by the business’, being a large organisation we have some extra hoops to jump through which I won’t bore you with.

As part of the peer review process we have our Definition of Done which includes items such as unit test coverage, functional test coverage, coding standard compliance, code lint and in the future scalability regression testing and other stuff.

Now the idea of the peer review is to communicate the change to another developer, to get some new eyes onto the change and be critically reviewed. Yet ensuring the DoD is met has become the focus of the exercise for us, detracting from what should really be going on in a peer review which is sad, especially given much of these tasks should really be automated anyway.

Ontop of this (and I won’t go into my opinions on off-shoring here) our management have seen fit to bring in some ‘programmers for hire’, who will be working from an entirely different location (and timezone), and doing their own peer review, so I decided it was time to both take away the mundane tasks from the peer review sessions and also ensure that our DoD would be met, irrespective of who was making the change.



Merge Merge Revolution! took about three days to glue together. The tools I used were Flask (Yes I know I have my own werkzeug/jina2/etc framework but I’m not sharing that with work at this moment as it is yet to be licenced c_c), Sqlite, My very own pomke.js, and jQuery.

MMR combines Git via the commandline and Buildbot via it’s json API to provide a (hopefully intuitive) interface which automatically populates buildbot with all –no-merged branches off master and a mechanism to merge those branches only when buildbot passes.

Combined these things provide a form of continuous integration, from the one location a developer can quickly identify if their branch is passing (you can click a build for a breakdown of steps, see above), force a build (the steps/eta/% done of which are updated in realtime on the screen), or attempt a merge, all the while with the assurance that nothing can be merged back into master unless the DoD is complete which means all forms of tests are passing; adequate coverage exists for the changed code, all forms of code checking have been run.

Further to this, we have a build-step which checks if the branch needs to be merged-forward, that is, another branch has been committed to master since the current branch was last pulled.

Here is a basic list of what I would like to see run before MMR allows a merge (we have about 80% of these steps already):

• Unit tests
• Functional tests
• Code lint
• Test coverage
• i18n string coverage
• Scalability regression tests
• Branch tracking master

I still need to get approval to release this tool on GitHub under BSD license as I built it on work’s time, but once that minor bit of red-tape is out of the way I’d like to make MMR a bit more modular, providing a basic interface so it can be used with any SCM and release it into the wild.

Would this be useful to you at all? Please let me know.

Lots of Love, Pomke Nohkan.

Raffe and I had a planning meeting yesterday, he made homemade burgers and I made tea. Hmm burgers and tea with a chocolate royal for desert, not the heights of grastronomic elegance but it filled our tummies ^_^

When it comes to project planning I like to be pragmatic, we’re a team of two and a formal scrum process would be over the top. However the idea of a backlog and sprints/increments/iterations (or whatever you’d like to call them) is fairly well ingrained in my psyche these days and I find it a logical way to plan out a project.

I found a pad of yellow sticky-notes on Raffe’s desk, (buried under a pile of books, scraps of paper and gadgets), and quickly went to work converting the glass-tile window in his apartment into a project planner.



Each vertical column represents two weeks;

The first row at the top has months, Nov, Dec, Jan, Feb. The second row holds my tasks; As I am building the web application, from the left we have tagging, basic gallery features, journal etc, planned out till Christmas (our proposed Alpha date).
The third row has milestones and milestone related tasks; in December we have ‘register a company’ and ‘alpha release?’, while at the end of February we have ‘We need a production server!’ and ‘Beta!’
The fourth row contains Raffe’s tasks, he is building the desktop application so from the left you will find: investigate skia, port current app to skia, deferred rendering etc..
And finally..The last column is our high level backlog, grouped up but in no particular order.

If you’re a PM you’re probably cringing in horror right now at our laissez-faire approach to project planning. Yet this works for us, we’re a team of two after all, we’re small enough to be a productive hive-mind.

And I think this is the advantage of small teams, low overhead on just about everything, the ability to think, and to act without weeks of discussion. Our project planning for the next few months literally happened in two hours.. and much of that was making burgers!