Skip to main content

How to implement CI/CD utility on the example of JET BI’s Advantage project

About Us
Published by jetbi
20 December 2022
100

CI/CD is a utility for Gitlab that is used to scan the project for errors and/or low-quality code, to make the project convenient for deployment on Scratch orgs and easy to configure for use. Checking with the CI/CD pipeline will help you determine what fixes and improvements need to be made to successfully deploy the project to any new org.

Example of CI/CD usage on our project for Advantage application development. The steps below display how to roll out Advantage app code on a new scratch org.

Prerequisites

  • You must deploy your project to Git and all branches should be created on a remote repository.
  • A Jenkins file should be added to the project folder, containing the necessary settings for checking the project through the pipeline.
  • Make sure that you have an available DevHub to create Scratch orgs.

 

1. Prepare a Jenkins file for pipeline configuration

1.1. In your Gitlab open your project, then select CI/CD -> Pipelines -> Run pipeline, then create a new pipeline.

1.2 Pipeline will be run automatically when you commit to any branch of the project. Then the validation process will be started.

ci-cd-1

2. Run the pipeline to check for errors in the project

2.1   First of all, at the “Build” stage, CI checks the project for the presence of all the metadata used. It is necessary that all objects, fields, classes, etc. are specified in. xml files. If you have passed this stage, it means that this project can be successfully deployed in scratch org.

ci-cd-2

2.2   Then your code needs to pass the code quality checking. This check provides the code with a static code analyzer for bad practices and unnecessary elements.

ci-cd-3

2.3   The last check is to run the unit tests. Tests are run as the standard user, without access to the application and all its components. Therefore, tests should be implemented using custom records of the User object and the System.runAs() method. The user must be assigned a permission set that grants access to all the necessary components of the application. If all pipeline checks have been passed, then the project is ready for deployment.

ci-cd-4

3.  Push the project to Scratch org

3.1 Create a new Scratch org using the sfdx-project.json file. For correct project deployment, you need to add a parameter "namespace": "advantage" to this file.

3.2 Use a commanding force:source:push to push the project to Scratch org. If the validation by pipeline was successful, the project will be successfully deployed to the environment.

3.3 You need to configure your user to make this project available for use. Open Setup > Permission Sets, then select 'Advantage administrator' and add the assignment to your user.

ci-cd-5

Perform the same actions for the “Advantage user” permission set. Then you’ll be able to find the Advantage app in the list.

 

As a result of passing the verification, we got a ready-to-use project that can be quickly and easily deployed to any Scratch organization. After installing the project, it is very easy to configure it for use, without additional efforts on user profile and field-level security configuration. The user only needs to create or upload data via Data Loader. This greatly facilitates the project development process across divided organizations.


Aleksandr Zherebilo
Salesforce Developer
image
Question to the expert
image

We have available resources to start working on your project within 5 business days

1 UX Designer

image

1 Admin

image

2 QA engineers

image

1 Consultant

image
Related Articles
All articles
image
Is Salesforce Winning the Public Sector Race?
An analysis of Salesforce's rapid expansion into the U.S. public sector, tracing its path from cautious early government licensing deals in the 2010s through the launch of Government Cloud in 2012, its pivotal role in COVID-19 vaccine rollouts, and its 2025–2026 push into military and intelligence work via Agentforce and Missionforce. The piece covers major 2026 contracts — including a $5.6 billion Army deal, a $1.6 billion VA agreement, and Pentagon Impact Level 5 authorization — alongside real-world case studies like California's REAL ID processing and the UK's NHS back-office operations. It also examines the structural obstacles still facing Salesforce and other vendors in government tech: legacy IT systems decades old, outdated federal procurement rules, budget constraints, and organizational caution around AI adoption, plus the competitive pressure from Palantir, Microsoft, and Oracle in the race for public sector AI spending.
28 August 2026
image
Why Your Salesforce Flows Are Agentforce's Biggest Problem
This article argues that the most underestimated risk in Agentforce deployments isn't data quality — it's the automation layer: years of overlapping Flows, Process Builder processes, Apex triggers, and managed package logic that no one has reviewed end-to-end. It explains why AI agents inherit automation complexity without the tribal knowledge human admins carry, why technical debt only becomes visible after an agent hits it in production, and why a clean demo is no indicator of production readiness. The article closes with a concrete, tool-by-tool inventory approach using Flow Trigger Explorer, Salesforce Optimizer, Setup Audit Trail, Apex Debug Logs, Agent Builder, and Health Check — scoped to the specific processes the agent will actually use rather than the whole org.
23 July 2026
image
How to Wire Multiple Salesforce Projects in One Org Without Breaking Everything
This article maps the real integration patterns that emerge when multiple Salesforce projects — both managed packages and unpackaged code — share a single org. It covers four concrete patterns: attaching custom triggers to package-owned objects, calling global members exposed by managed packages, writing directly into another project's objects, and runtime-guarded reads of package data. It then addresses access control for authenticated and guest users, including the Master-Detail wall and the without sharing elevation pattern. The piece closes with eight concrete risks (compile-time dependencies that block uninstall, upgrade coupling, silent cascade failures, access invisible to admins) and six actionable recommendations for keeping cross-project coupling manageable.
08 July 2026