| Builder Features |
|
Builder supplies an organized integration between the Source
and Change Management of Sablime and the build capabilities of
nmake. Build Management - not just builds.
Introduction Builder performs the processes associated with a project's builds. In that sense, builder is a general purpose build script. Unlike most build scripts, though, builder is highly flexible and does not mandate any particular process. It captures the process that your project wishes to use, and executes it reliably, all without modifications to the software itself. It is a low-tech, high usability solution to a common problem: getting consistent and reliable builds. Builder is highly portable, and it requires little maintenance and no specialized training or knowledge to operate.
Not all builds are for the same purpose. A project may
have nightly builds to keep the development staff up to date with
current changes; the may have occasional builds for delivery to
a test organization; and they may have builds intended to produce
releasable product.
Each of these may build a different set of code and may have other
different requirements. For example, the development build
may want to have symbol tables preserved for debugging purposes,
while the delivery build may not. There are endless variations
of what might go into a particular build; how to build it; and
what to do with it afterwards.
Builder allows you to capture the "build scenarios"
that your project uses. You can re-call the scenario according
to your project's schedules and practices with confidence that
the process is consistent.
back to top
Even within your well defined build scenarios, you may wish
to have variations controllable from the command line. If, for
example, you have reason to believe that the build node has been
corrupted, you may wish to have a standard build scenario "clean"
out the build node before launching nmake.
In another case, you may wish to add a particular MR to the build
source even though that MR is not part of the scenario's definition.
Builder allows nearly all of its configurable parameters to be
set from the command line.
On the other hand, you may not wish to allow certain nodes
to be "cleaned". Or you may not want arbitrary
MRs being put onto your source nodes.
Builder allows you to specify which parameters are to be sensitive
to command line settings and which Viewpath nodes are to be affected.
back to top
Builder captures the process that goes into setting up a build.
Once captured, it can be repeatedly executed with confidence that
the setup is consistent and complete. This avoids the all-too-common
problem of schedules and deliveries being missed because a critical
build failed due to improper setup.
Since a builder scenario is usually completely self contained,
builder builds are often launched from "cron".
This further isolates the build from the vagaries of shell environments.
back to top
The effective use of nmake generally means the use of "Viewpathing".
This allows source code to be shared among multiple builds - maybe
even on different platforms. It allows subsets of source
code to be used independently. It allows one build to make
use of the product of another - increasing build avoidance and
decreasing build times.
To have effective Build Management in such an environment, you
must have control of various actions on each and every node of
your Viewpath. Does this node need to have "setnode"
run? Should it be cleaned out? What source (if any)
should be placed onto the node? Do I want to duplicate (copy)
the node before I update it?
Builder allows you to specify all the actions that should be taken
against each Viewpath node in preparation for a build. You
can extract source code onto one or more nodes (even from different
generics), and you can perform any of the other indicated operations.
Each of these may be configured to be sensitive to command line
options, so that choices can be left until run-time.
back to top
Builder uses Sablime's getversion command (via Sablime's "node_update" utility) to perform the source node updates. Builder also has a few value-add capabilities over basic Sablime. These include:
Builder searches the output file generated by nmake, and reports
on errors and warnings. Post build operations such as MR
promotions and Node duplications can be made dependent on the
success of the build (where success is defined by the number of
errors).
back to top
Builder generates a fully customizable report of all the build
process operations. It also maintains a time-indexed log
of all the significant sub-processes that make up a build scenario.
The Report, which is emailed to the specified users, can contain,
for example, the MR name and abstract of each MR that is present
on each source node; anywhere from a brief summary to the complete
output of the "nmake" operation; output from the several
configurable "hooks" to user defined code; etc.
back to top
Builder can be configured to copy (using cpio) one or more
viewpath nodes to another location, before or after the build.
The copy can be made dependent on the number of errors found in
the build. Using the builder utility "copy-gate",
the copy can be prohibited or mandated for a particular instance,
and then revert to its normal condition later.
The copy can be set so that it only copies changed files, and
can be told to clean out the target node before the copy.
back to top
As part of your build process, you may want to have MRs that
were successfully built promoted to a higher Sablime MR state.
Builder automates this process, allowing you to set the target
MRG state for promotions. Any MRs that are on the node and
are in the previous state are candidates for promotion.
The promotion may be may dependent on the number of errors found
in the build.
Furthermore, using the "prom-gate" builder utility,
the promotion can be prohibited or mandated for a particular build,
and then revert to its normal condition afterwards.
back to top
Sometimes, when the environment is already set, or to work
through a build problem, it is desirable to just launch a build
as described by a build scenario, without the overhead of all
the node preparations.
Builder permits you to launch a build according to a particular
scenario, but to bypass all the node preparation and post build
node operations. Just launch a "Simple Build",
using the "-S" command line option. Builder does
it basic setup, then goes to the first Viewpath node and launches
nmake.
back to top
Builder, due to its use of the "node_update" utility,
can update source nodes to reflect the rejection of an MR.
That is, only the files whose content were changed by that MR
get updated or removed. Similarly, if an MR gets approved, the
changes associated with the MR may no longer be appropriate for
a particular source node. Node_update can update source
nodes to reflect this as well.
back to top
Builder can not have built in handling of every build circumstance.
Projects have unique methods and requirements - builder recognizes
that need for localization. Each build scenario can
be configured to "dot" setup scripts, and to execute
specified external programs at certain points during its operation.
In addition to these configurable hooks, builder will execute
user code at certain other points - for example immediately
before and after the source updates on each node. Builder
establishes and exports quite a few environment variables for
the benefit of the external code.
back to top
All the local customizations - the build scenarios - are stored
in external configuration files. When the builder software
gets updated, no local customizations get lost. There is
no need for local modifications to the builder code itself..
back to top
Builder is written in Korn Shell for easy portability and maintenance.
There are a handful of "C" modules as well, that need
to be compiled on the local platform, but the source is part of
the distribution, and compilation takes seconds.
back to top
Builder offers two different source update modes. "Fast
Incremental" for quick updates to a node, "Desired State"
for full validation of a node's contents. Both modes result in
incremental updates to the contents of a node. "Fast Incremental"
only adds MR (either new or re-submitted) changes. "Desired
State", in addition to updating the files of new and newly
submitted MRs, can fix corrupted files and remove spurious files;
update files due to rejected or approved MRs; and make updates
to reflect file name/directory changes made with the "source"
command.
back to top