A structured approach to embedded software source control - Embedded.com

A structured approach to embedded software source control

New standards such as ISO26262 and IEC61508 continue to emerge to bring more standardization in the embedded system development. There is a pressing need to follow a disciplined software development approach to adhere to these standards — and help improve software quality. Effective usage of a source control system can support this cause and this article highlights some best practices for deployment with GIT source control.

Some of the best practices that we employ in our embedded software development include the following:

  1. Modularized GIT commit comments
  2. GIT ignore feature to avoid unnecessary/debug/test data in release package
  3. ‘Inline patch review’ for quicker code-review process without needing a separate tool

Git is a distributed version control system with good speed. It supports distributed non-linear workflows. It is one of the most widely adopted version control systems used for software development. You can refer to Getting-Started-Git-Basics to get a basic understanding of the GIT version control system.

Modularized GIT commit comments
When working with legacy code containing many MISRA-C violations, tracking code changes made to fix them becomes difficult especially when there are multiple contributors. Furthermore, it can become more unmanageable due to added factors including:

  • Different contributors may use different tools for static code analysis like Klocwork, LDRA etc. Reports from various tools may be inconsistent at times on account of being evolved independently i.e. one MISRAC violation under LDRA may not come from Klocwork and vice-versa.
  • Multiple contributors may work on same modules addressing the same MISRA-C violations independent of each other, leading to a cumbersome integration.

Here we show some simple examples using GIT commands and structured GIT commit messages which we have used to easily manage MISRA-C fixes in our products. Some of these approaches have been incorporated as guidelines in our configuration management.

The figure below shows our recommended GIT commit message format that can be used for the git code commits related to MISRA-C fixes.

Using such commit messages for every code commit made for fixing the MISRA-C violations enables effective tracking of the code changes. Once every developer starts adapting such methodology it reduces confusion and enables developers to effectively manage and fix the MISRA errors.

Next page >

The benefit of a structured approach include:

Easy Tracking
Using git log and shortlog with grep option can provide very useful information on code changes, i.e. to find out Who/Which/How aspect of it – Who made MISRAC fixes, how many were made, and which tool was used to find a particular rule violation.

List all Fixes with commit ids
The abilityto get a full list of MISRAC fixes and see details of a particular fixcomes in handy during code-review process when only a particular type ofpatches are in scope e.g., MISRA-C fixes.The command shown above printsout all the commits with their commit IDs and one-line informationabout them. To find more detail of that commit, one can run git show .

Reverting Changes
At times there may be aneed to undo code changes introduced by a commit. One can quickly find acommit and revert that. For example, one can undo code changes done in acommit spread across several files for fixing a TOOL rule 139S.

Automation scope
A script (combination ofthe git commands demonstrated above) can be created to provide anexhaustive report with tabular presentation at the level of theindividual rule and modified file. Such reports can give insight aboutdifferent kind of fixes getting pushed to repository.

Commit trends/Planning
A periodicexhaustive report on different kind of fixes on a repository provides anoverall commit trends and also reflects code-development progress inaddressing those violations. This helps in planning future codedevelopment with minimal MISRAC defects.

Use of gitignore and submodule feature of GIT
Embeddedsoftware development involves a good number of test runs so as to testthe various features of the end system. A lot of binary data getsgenerated in form of test reports, debug directories with object filesso on. Most of such files need not be committed and stored in thedevelopment repositories. Such files may even bloat the size ofrepositories. In our experience it is better to have smaller sized GITrepositories and use GIT submodulesto create a bigger repository linking various GIT repositories insteadof having a single big repository. Use of gitignore avoids inclusion ofunintended files. A gitignore file specifies intentionally untrackedfiles that Git should ignore. Files already tracked by Git are notaffected. You can have a .gitignore in every single directory of yourproject. However, the best practice is to have onesingle .gitignore file on the project root directory and place all filesthat you want to ignore in it. The listing below shows the contents ofsuch a file:

Inline patch review
GIT can help significantly inpeer code review process. Using a separate tool to review a change-setis often an overhead to the main tasks and may slow down peer review.Using GIT commands, one can quickly create a change-set (patch) and sendit via email as inline text instead of attachment.

GIT is a flexible source control tool.When used effectively it can cater to embedded software development in agood way. A structured approach to git commit messaging not only easesexecution/managing/tracking activities but also leads the way for betterplanning for the next product with a similar codebase. Inline patchreviews can be used for quick and easy code reviews Use of the.gitignore feature can help in keeping unwanted files out of accidentalcommits and help reduce the size of git repositories.

4 thoughts on “A structured approach to embedded software source control

  1. “Inline patch review is a very good tool.nnDoes anyone make use of diff tool using an external editor? Does it work well or is better to use sourcetree?”

    Log in to Reply
  2. “I used sourcetree when I started using git, but when I switched to cli, I never wanted to go back. On my machine running windows 7 it was very slow, and the interface is not that good. My opinion.”

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.