Enhance your Salesforce development lifecycle with Flxbl (“DX@Scale”) and Hutte

In the challenging world of the Salesforce development lifecycle, achieving efficiency and reliability is vital.

Enhance your Salesforce development lifecycle with Flxbl (“DX@Scale”) and Hutte
Table of contents

Combining an open-source application lifecycle management (ALM) toolkit – Flxbl (formerly “DX@Scale”) – with the user-friendly UI of Hutte can reshape ALM in the Salesforce ecosystem.

Flxbl provides a wealth of practices and tools to improve the development lifecycle and automate CI/CD while empowering a modular architecture in the application. On the other hand, Hutte offers a unique UI to help improve collaboration and empower non-technical team members. 

This article showcases how modern DevOps practices are leveraged to streamline processes and benefit Salesforce Developers, Admins, and QA professionals by integrating these two cutting-edge tools.

For starters, let’s find out what Flxbl is.

What is Flxbl?

Image Source: Medium

Flxbl enhances the effectiveness of the Salesforce "Well-Architected Framework" by offering a tailored roadmap for implementation, curated explicitly for Salesforce development teams. While the framework outlines fundamental principles and best practices for constructing resilient, streamlined, and secure Salesforce solutions, Flxbl equips teams with the required tools and methodologies to translate these principles into action.

This platform acts as a bridge between theoretical guidelines and practical implementation, empowering teams to understand and master the essentials of a well-architected Salesforce solution. It provides them with the necessary resources to achieve it through streamlined DevOps practices and collaborative workflows.

In other words, it provides the processes and tools to handle the ALM of Salesforce programs, such as:

  • Org management
  • Release management/CICD automations
  • The collection of best practices around Salesforce with an emphasis on modular architecture.

Flxbl's main tool

Image Source: Flxbl

Flxbl's primary tool is called "sfp." It's a CLI that abstracts the end-user from all the complex and tricky operations behind the above-mentioned points, making following them simpler. The "sfp" tool, all the documentation, GitHub Actions, and any other artifacts are open-source. Therefore, the community can freely use it and contribute to it.

While Flxbl can be applied to any project, there are some important recommendations on when to apply it. For example, it's not advisable to implement Flxbl in a team whose members are new to DevOps in Salesforce and need to be made aware of most of the concepts as it may be overwhelming.

However, it's important to note that this collection of processes, best practices, and tools does not mean implementing Flxbl includes all these elements. Instead, it's an incremental process.

Why use Hutte with Flxbl?

Watch our demo🎞️

A pull request can be created from Hutte. It will automatically validate the updated data package against the next org.

While Hutte is an excellent tool for many stages of the ALM process (such as building and tracking changes with a simple UI), Hutte does not provide a fixed tool or strategy for handling the entire ALM process, such as release management tools and the strategy or processes to take the changes deployed up to production.

Instead, Hutte was created to allow our customers to have absolute control and flexibility over release management and other parts of the ALM process.

Hutte provides a superior product for:

  • Scratch org and sandbox org management
  • Org pools
  • Changes retrieval and tracking.

On the other hand, Flxbl provides a great tool and practices for the release management side of ALM. However, not all members of a team will have the skills (such as Git and SFDX CLI skills) to work with Flxbl, therefore requiring a UI like Hutte for org management, changes tracking, etc.

Automated validations on a pull request.

Connecting and pairing Hutte and Flxbl is a match made in heaven, as both follow modern DevOps practices and have been designed and created in a way that completely aligns.

These modern DevOps concepts are also supported by other authorities in the DevOps Salesforce world, reflected in the DevOps Manifesto, which includes:

  1. "Just-in-time" environments over long-living sandboxes.
  2. Source-driven deployments over org-based deployments.
  3. Simple branching strategies over org-based branching.
  4. Modular applications over monoliths.
  5. Automated deployments over deployment checklists.

For Flxbl users, this is exciting news as Hutte has a UI that removes the most challenging part of the process for Developers – change and org management. Using Hutte, Flxbl projects are not a challenge for non-Developers, such as Admin and QA roles that may not be used to Git tooling and the use of the terminal.

Where to start when integrating Hutte and Flxbl

Build, publish, and deploy packages on the merged pull request.

There are two scenarios:

  1. A Hutte team looking for an enterprise, scalable ALM framework
  2. A Flxbl team looking for a tool that enables Admins and low-code engineers to easily contribute.

No matter the scenario, both require the first step, which is to include the necessary changes in the Git repository.

An existing Hutte user would be required to:

  • Have a modular architecture for the metadata, or willingness/knowledge to incrementally have it
  • Add the required GitHub Actions that use the CLI of Flxbl ("sfp") to the repository.

An existing Flxbl user would be required to:

  • Incorporate the usage of "Hutte.yml"
  • Incorporate the usage of Hutte's CLI for GitHub Actions
  • Use data seeding with Hutte custom buttons
  • Optionally switch to using Hutte Pools.
Deployment is automatically performed to SIT and UAT.

Hutte’s recipe is here to help

Release to production (and others).

While the integration may seem complex, Hutte is here to support you! We've created a comprehensive recipe with a baseline implementation combining Hutte and Flxbl.

Give it a try

To find out more – including viewing screenshots – have a look at our "README.md" file.