Fuze™ Build and Deliver Overview

Fuze™ is the smarter way to build, test, and deliver embedded software.

Here is how Fuze™ fits into your overall development workflow:

This guide is for Fuze™ Build and Fuze™ Deliver. Fuze™ Test can be found here.

What is Fuze™ Build?

Fuze Build is an enterprise level tool for automating build, packaging, and release with universal automated configuration management for embedded software systems 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

What is Fuze™ Deliver?

Fuze Deliver is an enterprise level tool for delivering software, source code, documentation, or any digital asset. It ensures an auditable, structured delivery process, enforces governance, and provides full visibility across software and any digital asset releases.

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:

• Determine and track all associated metadata, including:

  • Who

  • When

  • What build command

  • Source commitID’s (and if the commitID’s are deleted, Fuze saves the diff patches)

  • Toolchain

  • Environment

  • Configuration metadata

  • Dependencies

  • Build package contents

  • Release status

  • Delivery status

• Fully recreate the environment for that FuzeID on his/her local system, including the source code, package repo, dependencies, configuration data, and toolchain that were used to generate that FuzeID (ie, a build)

• 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

How Do I Use Fuze?

Fuze has 3 UI’s:

1. Command line (CLI) - Windows, Linux, MacOS

2. FuzeUI (Web-based UI)

3. SlackUI (Slack command line application)

Command line

All Fuze functionality except Deliver is available from the command line. The CLI 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

• Events can be posted to Slack channels

Fuze as the Build and Packaging Tool

Although Fuze Build is a universal configuration management tool with many generic applications, its main purpose is to automate the configuration management of software build, package, and release. 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

• Hardware Description Languages for FGPA’s and IC’s.

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 GitHub, 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 Build 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 build maps are JSON format.

• FuzeUI requires a standard web browser.

• 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 (container repo) 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 delivered via email or to other custom endpoints (ie, FTP, Jira, etc).

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

Where Do I Start?

Start with the Getting Started Guide.