How To Deploy SFDX Changes In Git
By deploying SFDX changes in Git, developers can maintain a centralized repository for their source code, enabling version control, collaboration, and history tracking.
Table of contents
It allows developers to track and manage changes across multiple branches, collaborate with teammates, review and merge changes quickly, and maintain a consistent and auditable deployment process.
By leveraging Git, SFDX changes become part of a structured development workflow, enhancing code management.
But it does come with some obstacles, including the following:
Deployments are always target specific
If you have multiple orgs, you must prepare the deployment yourself. You can do it with tools or manually. You prepare a zip file with the metadata files and manifests. That is the components you want to deploy (the “package.xml”).
You would include a “destructiveChanges.xml” to delete something in a particular org.
You need to explicitly say what you want to perform
You could do a full deployment, which is slow and only works for smaller orgs.
Git repositories can grow significantly in size when storing large Salesforce metadata files
Since SFDX projects often include large metadata files, this can lead to larger repository sizes and longer clone and pull times.
You can also do an incremental deployment, which only includes a minimal amount of components
When it comes to Git, most people perform incremental deployments based on Git branches. Git commits typically operate at the file level, but Salesforce metadata is structured in a granular manner, consisting of multiple files for a single component.
This can make creating atomic commits that encompass all related changes to a particular Salesforce component difficult.
Salesforce metadata can be complex, and managing versioning for changes can be challenging
Git may not be inherently designed to handle Salesforce metadata changes efficiently, resulting in potential conflicts.
Care must be taken to avoid committing sensitive information
This can include passwords or access tokens to the Git repository.
Moreover, using Git effectively requires familiarity with its concepts and commands.
From deploying changes to packages
In the open-source ecosystem of deploying changes, the GitHub “sfdx-git-delta” tool can do the job. At Hutte, we have created a recipe that uses this tool – “cicd-incremental-deployment.”
But in general, focusing on packages (like unlocked or second-generation packages) is best practice.
The great thing about packages is that Salesforce does all the work or ‘magic’ for you. The downside is that not all metadata types are packageable.
2️⃣
Overall, it is important to remember that as Salesforce completes its migration to second-generation packages, adopting a Git-based approach will become crucial for development.
Are you considering moving to Git? Explore Hutte, a visual tool that enables seamless integration with Git for streamlined development workflows.
Start your free 30-day trial, or check out our demo below.
Visualize Git with Hutte
At Hutte, we enable you to visually leverage the benefits of Git-based development without needing CLI. We have removed the barriers Git can pose as Hutte is a web UI to SFDX that allows for visual Salesforce version control.
You can also create and manage Salesforce scratch orgs and sandboxes. There is no need for code, meaning no hassle is involved.
Furthermore, you don’t need to install or learn Git, as Hutte’s UI is already integrated into Git hosting tools, like GitLab and Azure.
You can also view the changes you made from these hosting providers, including your pull request, in a line-by-line comparison format.
🤯
There is no need to reproduce this data as everything is generated and integrated with Hutte.
If you're interested in delving into Salesforce Git version control, take a look at our user-friendly guide on its implementation and installation.
Hutte is truly one of the best tools that we use. Product owners, Salesforce solution architects, business analysts — anyone on our team can easily and visually accomplish the tasks that would otherwise take a lot of clicks, time, and coding.
Take a scratch org from the pool
Once you have created a Hutte account with us, you will start from a fresh environment by taking a scratch org from the pool.
You can name your org referencing the issue tracking system you use (such as Jira). Once you’ve named the org, you will have your environment in place.
With Hutte, you don’t need to share your sensitive and confidential Salesforce org credentials manually. You can simply one-click login, and you can then do your work on the platform.
Create new metadata and execute changes
You can create new SFDX metadata in your org. In this coding example, we have selected an Apex class.
💾
You add your logic to the Apex class and save it. This now becomes part of your environment.
To create a change, go to “Setup.” Then, select “Object Manager” from the dropdown menu on the left.
🙌
This is where the data model lives. You will then open up a custom object.
You can make any change you desire as you have access to the data model. To implement a change to a field, for example, you will select “Field & Relationships.” In this instance, we are changing the “Help Text.”
Once you have added in your help text, you will save it. To view your changes, you will go to the “Changes” tab.
In this example, the changes had the following impact to the org:
- “MyClass” was added
- The admin profile was touched by adding a new class
- The field change was added.
You can now pull changes
From here, you can describe your actions and select what to include from the changes you committed to.
📁
You will then click on “Submit.” This will create your SFDX pull request, and your changes will get added to Git.
Get a competitive edge with Git
⚒️
Installing Git through conventional means like SFDX or the Git command-line tool can present difficulties for non-technical users due to complex technical procedures.
By employing Hutte, users of any background or skill level can effortlessly collaborate with Git, make code modifications, and create pull requests.
Authors
