Fuze Overview ¶

Table of Contents

Fuze Overview

What is Fuze?¶

Fuze is an enterprise level tool for automating build, release, and configuration management of embedded software builds and all related digital assets, including (but not limited to):

Software/Firmware/Tools (source and object code)
Digital Files (ie, documentation, schematics, PCB files, RTL, etc)
Test Results

Fuze is a Painkiller and Lubricator ¶

Fuze is a painkiller and lubricator that solves three big embedded software challenges:

Solving Build Inconsisitencies and Toolchain Configuration Management ¶

An age-old problem for embedded software developers is maintenance of the cross-compile toolchain. Windows or linux? Local build versus production server? My build versus your build? How do we make this work at 11pm on Friday night?

Fuze solves this problem with the Common Build Enviornment, which guarantees that all local and cloud builders use the exact same build machine.

Solving The “Who Gets What?” and “Who Has What?” problem ¶

Embedded software occupies an unique space in the paradigm of software versioning and delivery. You have multiple versions of your code spread out across multiple product lines and customers, usually in multiple stages of development.

You need a way to track who has what, who gets what, and what version you sent. Fuze solves that problem by fully automating the configuration mangement of your code, starting with the build and continuing through delivery.

Solving The “I need to recreate the release from 4 months ago” Problem ¶

Once you’ve launched a version into the wild, you naturally move on. Your code base moves on, your feature-set moves on, and your toolchain might move on.

But then the customer comes back and says they need a point-release to address a specific bug in a specific module. No, they cannot take your latest HEAD because that will reset the test and certification process. Just fix this bug on this line of code, please.

Fuze solves that problem through automated configuration management of the entire build and package process, including the toolchain and all build dependencies. Tell Fuze to recreate the workspace from that build, and you’ll have it within a few seconds. You can now create a binary-identical build.

Questions Answered by Fuze ¶

Fuze answers the following questions:

What did we send to Customer A?
How do I build version X?
It builds for me locally, why doesn’t it build for you?
How can I recreate and debug version Y?
How do I release the code I’ve tested?
How do I promote our release through various stages of testing?
How do we release particular version Z to Customer A?
What is the current status of build X?
What were the test results for build X?

One ID to Rule Them All ¶

Fuze is built around the concept of automated universal configuration management, which is realized via a unique FuzeID. Fuze automatically generates and assigns a FuzeID for all builds, and some other operations, that occur within a Fuze workspace.

Knowing this unique FuzeID allows a user to:

Fully recreate the environment for that FuzeID on his/her local system, including the source code, package repo, and common build environment commitID’s that were used to generate that FuzeID
Easily obtain all packages that are associated with that FuzeID
Trace a deliverable
Promote a build to another level of testing or to a release
Uniquely version and identify any digital asset

Who Should Use Fuze?¶

Fuze should be used by the following:

software developers
documentation developers
any engineer or developer creating digital assets
release managers
QA
AE
FAE
Sales engineers

What Does Fuze Do For Me?¶

We’ve loosely defined 4 user groups for Fuze.

Developer ¶

Build with production env locally (no local tools necessary)
All local and cloud builds can be release candidates
Recreate source tree for a particular build
Dependency download without build
Share and integrate easily
Recreate prior release or build
Easily get other builds
Customize package contents
Customize build workflow
Search for previous builds/releases

Verification, Validation, and Quality Assurance ¶

Search for release/builds
Easily get release packages
Easily get test builds
Fully automated release testing

Product Manager ¶

Automated release with full configuration management
Define and automate release packages
Deliver to customer or vendor
Search for releases/deliveries
Deploy to manufacturing
Security

Customer Interface ¶

Share/Deliver to customer automatically
Prototype or demo with full config managements
Recreate delivery in < 60 seconds
Search for previous deliveries
Security

How Do I Use Fuze?¶

Fuze has 3 UI’s:

Command line (Windows, Linux, MacOS)
FuzeUI (Web-based UI)
SlackUI (Slack command line application)

Command line ¶

All Fuze functionality except Delivery is available from the command line. The command line UI is required for:

Building and packaging
Creating and getting workspaces
Adding packages to existing FuzeID

FuzeUI ¶

The following functions are available in the FuzeUI:

Searching
Getting packages
Determining and getting dependencies
Seeing all metadata associated with a FuzeID
Adding files to existing FuzeID
Creating and promoting releases (including kicking off release automations)
Delivering releases
Downloading the “Containerized Fuze” command script to work locally
Execute a wizard to generate a workspace.ini file.

SlackUI ¶

The SlackUI can be used for the following actions:

Searching
Getting packages
Notification and viewing of builds and releases - All Fuze builds and release events are posted to Slack channels (fuze-builds and fuze-releases)

Fuze as the Build and Packaging Tool ¶

Although Fuze is a universal configuration management tool with many generic applications, its main purpose is to automate the configuration management of software. Software can refer to any digital asset that is created through a “build” process, such as:

Embedded and host-side software applications
Software source packages
Rendered documentation from a markup source language
Applications and executables from tools such as matlab

When you build with Fuze, the Fuze ecosystem creates and retains all interesting metadata associated with the source and the build itself.

The following sections describe Fuze’s place in both the cloud build and local development environments.

Fuze’s Place in the Cloud Build Ecosystem ¶

Fuze is not a CI/CD tool. It is meant to sit between the Cloud CI/CD tool (such as Bamboo, Jenkins, etc) and the underlying build tools and scripts. It adds the configuration management layer that is missing from both the CI/CD and the Build layers.

The following shows where Fuze exists in the CI/CD build ecosystem:

The CI/CD tools invokes the build with Fuze, and Fuze performs the underlying build by calling the low-level build system. Fuze also contains an interface in which it can call the CI/CD tool as well, which leads to further automation possibilities, such as automated testing and release workflows.

The line between Fuze and the Build Tools is slightly fuzzy, because Fuze presents a generic, low-level command interface for build commands. Therefore, Fuze could function as a “make” replacement and call the compiler and linker directly. Fuze could also be completely abstracted away from the low-level build commands and call a script or build framework that does everything related to build.

Guidance on how to design the interface between Fuze and the underlying build system is provided in the [build reference guide].

Fuze’s Place in the Developer’s Local Build Ecosystem ¶

Speed and quality are our ultimate goals as an organization.

One pillar of helping a development organization go faster is to break down the barriers of formality in process. Another pillar is to reduce the number of places in a workflow where errors, and hence delays, can occur. Fuze helps both of these.

Traditionally, development and release process is put in place in order to ensure the quality of a given release. When used by the development team as part of their daily activity, Fuze helps break down the barriers of the formal release process by ensuring that ALL developer builds are potentially suitable for integration and release. Since Fuze guarantees the traceability and configuration management of all builds, and promotes the socialization.

The developer’s local environment is a sacred and highly customized space. Building locally with Fuze is not required nor meant to violate that space. But when Fuze is used to build locally during the development and debug cycle, then all of the benefits of socialization, traceability, reproducibility, and configuration management come naturally.

Typical Development Through Release Workflow ¶

In a traditional development workflow, a developer builds on his/her host machine with some tool such as make, an IDE, or some set of build scripts or framework. The development cycle continues until he/she thinks the code base is ready for integration (if necessary) or formal testing.

For either integration or formal testing, a new build must be produced in the respective environment (ie, another developer’s local environment, or cloud production environment, etc). Each point in the process that requires a new build is a place for potential failure , required debugging , and the slowing down of the process .

The developer or product manager creates a release package just before or just after formal testing. This package must be placed under configuration management in order to ensure it’s traceability and availability. Even with rock solid configuration management, there is still the very real risk that a particular release cannot be reproduced locally if a future need arises.

Development Through Release Workflow With Developers Building Locally With Fuze ¶

If Fuze is used as part of the normal workflow of the developers, the yellow boxes in the above typical workflow diagram can be eliminated. Building with Fuze ensures the build is production ready, and puts all packages under configuration management at all times (when directed).

Fuze allows the developers and the organization to be “always ready” to release any given build.

All Fuze builds takes place in the production environment, which eliminates the scenario whereby a product builds locally for a particular developer, but won’t build on another developer’s system or the production environment. It also guarantees that any build (even local builds) can be 100% reproduced in the future.

Fuze Technologies and Concepts ¶

Fuze utilizes the following technologies and concepts:

Fuze is written in Python (v3) and build maps are JSON format for cross platform portability.
FuzeUI is written in Javascript
All build commands (from the build map) are performed in a Common Build Environment (CBE). CBE’s are docker containers, which ensure a fully managed, reproducible, and cross-platform build environment for all Fuze builds.
Source repositories (git), object/package repositories, and CBE repositories (docker hub) are utilized to ensure versioning and traceability.
Unique FuzeID’s are generated with a combination of fields to satisfy both human readable and uniqueness aspects.
Fuze can be used without internet connectivity, with a few pre-requisites.
Packages can be deployed to customer portals or via email.

The following provides a high level view of the Fuze technology ecosystem:

Where Do I Start?¶

Start with the Getting Started Guide.