Builds

A build is a snapshot of a specific project version, packaged and prepared for deployment to a runtime environment. The concept of builds plays a crucial role in ensuring that the correct version of a project, with all its configurations and dependencies, runs consistently across different environments (for example, Dev, UAT, Production).

​

Key concepts

1. Project Version vs. Build
   • Project Version is the editable snapshot of a project’s state at a specific point in time. It contains all the resources (like processes, integrations, templates, etc.) and configurations grouped within the project.
   • A Build is the deployable package of a project version. It is the compiled and immutable state that contains all the project resources transformed into executable components for the runtime environment.
2. Single Version Rule
   • A build can only represent a single version of a project. If you have multiple versions of a project, each one can have a unique build. This ensures that you can clearly manage which version of the project is running in a specific environment without conflicts.
3. Consistency and Deployment
   • Builds ensure that when you deploy a project to a different environment (like moving from Dev to UAT), the exact configuration, processes, templates, integrations, and all associated resources remain consistent.
   • Builds are immutable—once created, a build cannot be altered. Any updates require creating a new version of the project and generating a new build.

​

Creating a build

To create a build from a committed project version:

​

Build immutability

Once a build is created, it becomes immutable—you cannot modify its contents. This ensures:

• Consistency: The same build behaves identically across all environments
• Traceability: You can always identify exactly which project version is running
• Stability: Prevents accidental changes that could affect production systems

To incorporate changes into a build:

1. Make your changes in the project (creating a new draft version)
2. Commit the changes to create a new project version
3. Create a new build from the updated committed version

​

Key features

1. Checksum and Integrity
   • Each build includes a checksum or identifier to verify its integrity. This ensures that the deployed build matches the expected configuration and no changes have been made post-build.
2. Runtime Dependency
   • The runtime environment relies on builds to determine the active project configuration. This means the runtime does not directly interact with the editable project versions but uses builds to maintain stability and reliability.
3. Version Control
   • Builds are version-controlled, and each build corresponds to a specific project version. This means you can trace exactly which project configuration is active in a particular environment at any time.

​

Benefits

• Consistency Across Environments: Builds ensure that the same version of an project runs in different environments, avoiding discrepancies between development and production.
• Reduced Errors: Immutable builds reduce the risk of runtime errors caused by unexpected changes.
• Simplified Rollbacks: If an issue is detected with a current build, previous builds can be deployed quickly, providing an efficient rollback strategy.
• Simplified Deployment: Builds allow for a straightforward deployment process, reducing the complexity of transferring configurations and resources between environments.

​

Managing builds

The Builds section provides a centralized interface for viewing and managing all builds for your project. Access this section by navigating to your project, switching to Runtime mode, and selecting Builds from the navigation menu.

​

Builds list

The builds list displays all builds created for the project, showing:

• Build name and version: Displays the build name and tag version (for example, Update_process_variables 1.0.0)
• Build actions: Each build entry provides quick access to:
  • Play/Run: Test the build with options to:
    • Test build - run a process from the build
    • Test endpoint - call a REST data source endpoint
    • Test workflow - run an integration workflow
    • Test operation - run a FlowX Database or unmanaged MongoDB operation; see Testing data sources from Runtime
    • Test SOAP operation - run a SOAP system operation; see SOAP system
    • Test query - run an Oracle or PostgreSQL query; see Testing data sources from Runtime
    • Test knowledge base - test knowledge base operations; see Testing a knowledge base
  
  • Export: Export the build for transfer to other environments or workspaces
  • More options: Additional actions via the context menu:
  
  • View contents
  • Workflow test instances
  • Audit log
  • Apply indexes
  • Drop indexes

​

Apply indexes

Indexes defined on FlowX Database collections during config time are not automatically applied to the actual MongoDB database. To apply them, use the Apply Indexes action from the build’s context menu (More options → Apply Indexes). Indexes are applied from the build’s snapshot, not from your current configuration. If you add or change indexes, create a new build to capture them and run Apply Indexes on that build. If the indexes are unchanged, you don’t need to re-apply them for every new build — once applied, they stay on the database until you change them or use Drop Indexes.

​

Workflow test instances

When you run an integration workflow from a build using the Test workflow action, each run is recorded as a test instance. To review the history of these runs, use the Workflow test instances action from the build’s context menu (More options → Workflow test instances). The action opens a list of workflow test runs for that build, with the following details: Select an instance to drill into that run’s details. If no workflows have been run from the build yet, the list is empty.

​

Searching builds

Use the Search by build tag field to quickly find specific builds by their version tag or name. This is particularly useful when managing multiple builds for the same project.

​

Exporting builds

You can export builds directly from the Builds section. This is useful when you want to transfer a specific build (rather than a version) between environments or workspaces.

​

Technical details

1. Manifest and Metadata
   • Each build contains a manifest that lists all the resources included, their version IDs, and their resource definitions.
   • Metadata helps identify which project version the build is derived from, providing traceability.
2. Separation of Design and Runtime
   • Builds serve as a bridge between the design (config) view and the runtime view. The config view is where changes are made and managed, while the runtime view uses builds to execute stable, tested versions of projects.
3. Storage
   • Builds are stored in a dedicated storage system to ensure they are separate from the editable project versions. This storage supports easy retrieval and deployment of builds.

​

Example use case

Imagine you have a project for customer onboarding with multiple processes, templates, and integrations. After completing development and final testing, you:

• Submit changes to create Version 1.0 of the project.
• Create a build for Version 1.0.
• Deploy this build to the UAT environment for final stakeholder review.
• If any adjustments are needed, you go back to the project, make changes, and submit them as Version 1.1.
• Create a new build for Version 1.1, ensuring that the changes are encapsulated separately from the previous version.

Once everything is approved, you can publish Version 1.1 Build to the Production environment, ensuring all environments are aligned without manual reconfiguration.

​

Conclusion

The Build feature is essential for managing projects across multiple environments. It provides a clear and organized pathway from development to deployment, ensuring consistency, integrity, and stability throughout the project’s lifecycle.