In an embedded project there are generally a handful of key deliverables (requirements, code, documentation, traceability, tests, etc…). These are often developed by different people in completely separate databases. They are basically never all in sync. This complicates almost every step in the development process.
I was recently inspired by this Github blog post and I think pull requests could enable a nearly ideal workflow for embedded projects.
The basic idea is that rather than keep all of these artifacts in separate databases, store them all in a text (diff-able) format in a git repository. For each feature or issue, a pull request is created. All changes for that feature/issue (requirements, code, documentation, tests, etc) get implemented in the pull request. Since pull requests are essentially branches, if we need to merge in changes from other pull requests we can do that trivially. Once the feature/issue is finished, you merge it into master. This way every change related to that feature is captured and coordinated in a single place. Everything always stays in sync. The commit history of the master branch would show an incremental lock-step addition of features and issue fixes. You could instantly see how each piece of each deliverable was affected by a given change. That alone is worth its imaginary weight in precious metals.
Another major advantage is that you can easily keep the master branch in a ready-to-release state. You can test and review each pull request independently. You can run your metrics (test coverage, lint, traceability coverage) on your pull requests and only merge to master once all of the deliverables for that feature are complete (full traceability, 100% test coverage, etc). In fact, with tools like Travis CI you could run all of your tests and metrics on the pull request as if it was merged with master. This would also make reviews much less painful. Rather than trying to review all the disparate changes in the separate databases made at different times to make sure they all match and are correct, you can review the changes in the pull request as a single unit. And you could have all your test results and metrics from your pull request available to help with the review.
Unfortunately this workflow is not fully realizable…yet. I’m not sure Travis CI would be (or should try to be) a good fit for embedded (we use a lot of really crappy proprietary compilers and tools), but I’m sure that other CI tools will soon follow Travis’s lead and start supporting pull requests as well. There is also a need for a good requirement tracking tool that stores requirements in simple text files. But I’m hopeful that someday soon I’ll get to try this workflow on a real project :)