Merge Merge Revolution!
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;
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):
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.
- A ticket is raised in the ticket system (in our case rally).
- The ticket is accepted into a sprint.
- A branch is created, and the work is done
- The branch is peer-reviewed and feedback is given
- The branch is accepted by the business*
- The branch is merged back into master
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.