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