EaglePicher Technologies is a leading manufacturer of battery systems for diverse industries like defense, aviation, space or medical.
As they operate in highly regulated industries, keeping a clear and traceable software code change history is just as important as complying with hardware specifications and safety requirements.
Kalen Brown, Associate Electrical and Computer Engineer, shared how they are using Commit Policy Plugin in managing source code changes in their Subversion repositories.
Tell us a bit about your role at EaglePicher!
I started here out of college in the beginning of 2015 and essentially dove into the project I am in now.
We are now working on a Lithium-Ion Iron Phosphate (LFP) commercial aircraft battery that uses a safer and more robust chemistry.
The cells in this battery may be much safer than ordinary Lithium-Ion batteries, due to the Iron Phosphate mixture, but we still want to be as safe as possible so we have hardware and software working together to keep the battery happy.
What triggered your need for a strictly controlled repository?
The Code of Federal Regulations (CFRs), the collection of rules created by federal agencies, says the equipment, systems, and installations whose functioning is required by the airplane must be designed to ensure that they perform their intended functions under any foreseeable operating condition.
The Federal Aviation Administration (FAA), the U.S. national authority that regulates all aspects of civil aviation, gives one example of an acceptable means of compliance to demonstrate that requirement as RTCA DO-178C Software Considerations in Airborne Systems and Equipment Certification, which is the framework authorities (such as FAA, EASA and Transport Canada) use to regulate commercial, software-based aerospace systems.
It clearly specifies requirements to define the intended functions around the software aspects of airborne systems and equipment, and the tests to prove them.
Boeing had serious problems with batteries bursting up in flames on 787 Dreamliners
It’s also important to note that these guidelines are not there just to make us create more documentation.
For example, some of the rigor that we need to go through is because of the battery fires on Boeing 787 Dreamliners in 2013.
So we need to be able to prove how exactly each requirement is fulfilled and by what part of the source code.
This calls for tools that make it easy to manage our work items towards each requirement and control what is committed to our Subversion repositories in a proactive way.
These requirements drove us to use Jira, Subversion, and subsequently Commit Policy Plugin for change control assistance.
How does Commit Policy Plugin help developers stay compliant?
Commit Policy Plugin helps ensure process compliance where essentially the reason why you are changing something in Subversion must be documented in Jira.
It does this by verifying all commits sent to the Subversion repository against pre-defined rules, and reminds the developer if something is not right.
It’s impossible to send in a non-compliant commit, so at code review we can just focus on what the software does and leave it to Commit Policy Plugin to check if the right conditions and references are in place.
This way, easy traceability is maintained where someone can look at the Subversion revision history containing the commit messages and find the documentation (Jira issue key the policy made us type in).
We also introduced the (more passive) Subversion ALM app, so looking at a Jira issue a reviewer can find where the change occurred in the code, as the Subversion commit message appears in an Subversion tab in the Jira issue.
What are the benefits of using commit policies in your Subversion repositories?
While we could write a regex anytime to detect if something that resembles a Jira ticket pattern is entered into the commit message, the commit policy’s JQL condition ensures that the ticket mentioned actually exists.
To give an example: you can put DEMO-72 into a commit message and it looks like a Jira issue key.
However, the commit policy can tell that, while it matches the required pattern, DEMO-72 does not exist because we are only up to DEMO-5.
Or, it exists, but it’s assigned to someone else in a different Jira project.
It saves you from creating incorrect or broken links.
It also saves you sometimes from simply typing the issue key in wrong.
Say, DEMO-893 was intended but I typed DEMO-839, the commit policy rejects my commit, saying that the issue mentioned is not in a status that I should be committing on.
So, in addition to keeping our developers on track with compliant code changes, it kind of acts as a spell checker, too.
As with most standards, the goal of DO-178C is to formalize a process where what is being done is easily reviewable and follows a common sense due diligence.
However, this results in 99% of the work generating documentation (well beyond what is discussed here) and 1% editing source code, so we apply the same rules to documents as we do to source code.
Thankfully the tools like Subversion help automate some of the documentation required to keep track of things, and Commit Policy Plugin reminds us to document what we are doing or that we need to have other people look at it before we dive into changing things.
What would be your message to someone hesitating introducing commit policies to their repositories?
When there is a process to be followed, then this is the tool to get.
It saves having a dedicated person babysit every transfer or document why the process was not followed.
If people follow the process at hand, then they should never even encounter the commit policy and it will be seamless.
You can scope it down to specific folders like the "tags" folder, or apply a rule to the whole repository that commit messages just can't be blank and not even use any Jira features like JQL.
The most difficult aspect is conveying to others what process you want them to follow, so with the commit policy in place it can be a trial by fire where your hard work does not get burned.
Top comments (0)