-
The most widely deployed mobile virtualization solution
Data Sheets
Open Kernel Labs Blog
January 26, 2010
Branching Out into Our Development Process
One thing that is perhaps rare, but not unique across software companies is our approach to tracking all project development through a single branch management process. We branch to contain changes made to our product in one nice bundle. This approach isn't always easy, but using the right tool makes it easy. We use Mercurial for revision control, so branching is very natural.
There are three inherent features of this process. Firstly, every change is performed within a branch off a single repository, regardless of what it is - if it changes the product in anyway, it has to be done in a branch. This means the history of all changes are logged and audible at any time in the future. Secondly, all changes are scrutinised via a review process. The reviews come in different forms and there are many reviews. This includes, but is not limited to, style checking, unit testing, performance testing, and peer code reviews. All are fully automated, except for the peer reviews. They assure our high software quality. Finally, only software that passes our reviews is merged back into our main software repository.
We don't restrict ourselves to how this approach is applied with a specific software methodology. Sometimes agile approaches are used to iterate over the development of a project. Sometimes it looks more like waterfall. Either approach works and is independent of how we manage our changes in branches.
Development.
The development process follows a similar workflow to the branch management process used during the project's design phase. Once development of the new feature or change is complete, code and documentation peer reviews are conducted by our senior architects who scrutinise every change. They focus on ensuring code quality and consistency, that the design, requirements and extensive testing have been addressed. With our extensive use of tools, which I'll talk about later, these reviews take anywhere between minutes to around half an hour, depending on the complexity of the change. This process also motivates teams to pass the review first go so quite often they conduct their own peer reviews dung the course of development.
Other than the code reviews, we run extensive automated regression testing, code coverage and performance analysis. All of this is automated and repeatable. During testing all existing and new tests are run against each development tree. These must pass before the new software can be considered part of a release candidate.
All of these come together to form a very nimble process. For a simple software change, this process, with all the checks and balances and no compromises, can be turned around within the day. We can have a solution to a customer issue before they arrive at work in the following morning. For more complex software changes, this process ensures our high standards are maintained and customers are kept happy.
So, how do we keep this all together? Tools.
Posted by Daniel Potts on January 26 at 02:30 AM
blog comments powered by Disqus
About Daniel Potts:
Dr. Daniel Potts, Director of Engineering at OK Labs, heads up the engineering team and oversees the development our products. Dan enjoys working closely with his team, and ensuring that they have everything they need to focus on producing high quality products. When not working, you'll find Dan at the beach or swimming laps at the pool.