The Veloce team works hard to develop solutions that simply work and require no coding for the customer’s admin team. We take care of the CPQ development, so our customers can take care of business. However, for Systems Integrators and developers who would benefit from insight into our development tool, I’m providing a glimpse of the tool our team uses behind the scenes.
Integrated Development Environment (IDE) versus point and click tools
A CPQ project is very complicated and it takes a large team to develop it concurrently. In order to support concurrent development, we need IDE style metadata driven development tools using modern version management tools like a Git repository. As developers, we all use Integrated Development Environment (IDE) for development, not point and click admin tools. Imagine if you had to use a point and click admin tool to write a java program — it would be very inefficient. At Veloce, we realized this and developed one for ourselves.
Our development workflow is like the following diagram. First image is full diagram. Second two images are inlarged sides of the diagram for easy reading.
A more efficient way to develop CPQ solutions
Veloce’s CPQ development tool is based on Salesforce Developer Experience (SFDX). The whole Veloce CPQ solution consists of metadata stored in the Git repository that can be pushed to scratch org and pulled from scratch org to update it or update in IDE directly. Each Developer has their own scratch org and can make changes to the metadata in scratch org using our admin tool.
Pulling from the scratch org to update the metadata, any developer can also use the IDE to update metadata directly if they learn how to write product model and rules in our metadata format. Trust me, after more than twenty years developing CPQ solutions, I can tell you this is a much more efficient way to develop CPQ solutions.
Typical proven development process brought to the CPQ world
Each developer has a Git branch of the project and their own scratch org and they develop part of the CPQ solution in the isolated environment. After they unit test it in the scratch org, it will be merged into an integration branch and pushed to a sandbox where an integration test is performed. After it passes integration testing, it will be merged to a release branch and pushed to a sandbox for User Acceptance Testing (UAT). After it passes the UAT, it will be pushed to production and released to the end user. This is a typical proven development process for any project and now we bring it to the CPQ world.
If you are interested in knowing more about our metadata driven development approach, please contact us for a demo.
