Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[alf-dev] Real-world use cases for Source Code Management

All,

 

I’ve been following the mail on this subject for a bit, and Tim asked me to weigh in with some use cases from actual customers. I’ve got two that illustrate a pattern that has emerged from several other customer discussions.

 

Use case 1: A manufacturer of election and gambling equipment has very strict requirements from various government agencies about building software in a clean-room environment. No human hand is allowed to get between the automated build process and the ultimate delivery of the software to the external audit agency.

 

There are numerous touch-points for source code management in the use case. No code can be changed without a CR. No code can be checked in without engineering and impact analysis documents. All code must go through peer review and scanning. But, and this is important, most of them *are not ALF touch points.* Anything that is real-time, while the developer is sitting in the IDE, is not an ALF touch point. While it might be interesting to have services for this part of the use case, it is not imperative for ALF.

 

So where would ALF play in this use case? During build and during audit.

 

Establish a clean-room into which the various source assets will be placed.

Get the source code associated with some label or other logical name.

…Scan the code. Do the build. Run automated tests… Not Source Code Management problems.

When the build is complete, check the resulting build targets into a secure repository. (Not the same repository from which the code was retrieved.)

Provide a list of all source code changes between two labels or other logical names. Verify that every source code change is associated with a CR. Provide a variance report.

Provide a list of every file, with version number that is associated with a label or other logical name. (This may be a build BoM function rather than a version control function.)

Give a logical name to a set of files with their associated version numbers. At any time in the future an auditor should be able to ask, “Exactly what files and what versions went into your embedded module X’s version a.b.c?” If the company can’t answer that question, then they could be asked to pull every single piece of hardware with X version a.b.c.

 

Use case 2: A bank wants a unified release process to make sure all assets associated with a release get deployed together. The code comes from several different repositories to be used in different development and build environments. As with the example above, the interactive touch-points are not ALF-ish and I’ve left them out. Again, build and audit are the times when ALF comes into play.

 

Get the source code associated with some label or other logical name. The code will probably be dropped into several different build locations and the request for the code may go to several different repositories.

…Scan. Build. Test…

Provide a diff report of every change to every code asset associated with the logical name.

Associate a logical name with a set of source assets.

BoM. Again, this may be build rather than source control.

…Deploy…Not a source code problem.

 

I have other examples, but they all end up looking very similar, with small variations. Populate a build area with a pre-defined set of source-assets. If the build is successful, label the source assets that were part of the build. Audit the source assets.

 

There is one other use case that comes from within Serena rather than from an external customer. I have not had an *external* customer ask for this.

 

A software vendor wants to be able to automate the project creation process. When a project gets approved, a new source code branch for the project gets created. This is true for release projects, patches, maintenance releases, etc.

For patch, when the patch is complete, merge the source code with other identified code branches and provide a report. If not possible, provide a variance report.

 

 

I hope this helps.

 

Regards,

 

shaw

 



**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

Back to the top