Topics Map > GitLab

DoIT Shared Tools - GitLab - How-to Use GitLab and Salesforce

Campus partners developing in Salesforce mostly likely can use the git.doit.wisc.edu. In order to be granted access, please request a needs analysis and discuss your goals with the Shared Tools team.

Salesforce and GitLab Training Resources

Salesforce Development Resources

The following resources, descriptions, and images were provided by Salesforce.

Accelerators

Trailheads

Types of Salesforce Development

Benefits of Using Source Control

  • Helps deal with the challenges of merging changes from lower environments and keeping isolated environments in sync with one another (at all levels).
  • Provides visibility and auditability so that with every new release, you refresh source back to a clean slate.
  • Mitigates conflicts with parallel development in the same org with multiple teams.
  • Provides the ability for development teams to scale better

Org Development with Source Control

  • Changes are tracked on a per-org basis, but relative to source control
  • Source control is used as the ultimate source of truth for the changes that are under active development. 
  • Developers check changes into source from their individual developer sandboxes, recommended to run at least a daily sync to keep the individual orgs up to date.
  • Conflict management and merging of individual changes happens within source control. 
  • Aggregated changes are deployed programmatically to build/test/release environments, based on the changes aggregated in source control.
  • UI-based change sets created through Setup can still be used as-needed, but need to be used with caution so as to not overwrite when metadata is deployed from source control

Package Development with Source Control (Preferred)

  • Changes are tracked in source control, relative to the package itself 
  • Version control serves as a long-term artifact, containing all the metadata and configuration information for packages and the versions of those packages that are in development.
  • In lower environments, developers iterate through changes and develop in scratch org or sandbox environments. 
  • Developers use source:push/pull to synchronize changes made declaratively and programmatically in a scratch org with the metadata and package information in source. 
  • When changes need to be promoted to build/test/release environments, a package and package version are created from the metadata in source. 
  • An updated package version is installed to synchronize higher environments.
  • UI-based change sets are still available, for promoting changes that aren’t contained in a package version or tracked in source.
  • Unmanaged deployment scripts can be used to allow non-packaged metadata to be deployed with one action instead of separate workflows.
  • SalesforceDX (SFDX) required and CumulusCI (CCI) recommended on top of DX.

Note: Not all features of Org development are available in Package Development. At times a hybrid approach is required. 

Key Diagrams of Salesforce Development, Repository Management, and Branching Strategies

Application Life Cycle Management for Salesforce Projects

The Application Lifecycle for Salesforce Projects is extremely similar to non-Salesforce application development in it's capabilities and execution. All work should begin in a backlog for review, grooming and prioritization ahead of actually building or executing the request. This pre-work allows you to ensure validity of the request while also grouping work items together into a streamlined build process rather than working in isolation. Once a request is moved into development it follows the development methodology you prefer (Salesforce leverages Agile) and moves through your environments and release processes through CI/CD (Continuous Integration / Continuous Development) pipelines via your source control system(s). After a work item has been executed and adequately tested it is released into production for end user usage and 

This process is, or at least should be, an iterative process requiring constant feedback and evaluation of the deliverables. This feedback loop ensures that work moving through the pipeline is set up for success through security, system stability and end user accessibility. Each layer of the application lifecycle should include a component of solution re-evaluation, user testing, platform stability and end user accessibility. Salesforce's metadata model is fully aligned to this process helping align and lower the risk of release conflicts or release discrepancies ensuring you are ready to run once you outline your unique process steps and release stages.

The Application Lifecycle includes planning, ideas,  development, and release management. This diagrams outline the key components of this process including source control.

Development & Release Management: Package Development with Source Control (Preferred)

This shows the release management process using a package development model. In this model, version control serves as a long-term artifact, containing all the metadata and configuration information for packages and the versions of those packages that are in development. Changes are tracked in source, relative to a package version. In the lower environments, developers iterate through changes and develop in scratch org environments. They use source: push/pull to synchronize changes made declaratively and programmatically in a scratch org with the metadata and package information in source. When changes need to be promoted to build/test/release environments, a package and package version are created from the metadata in source. An updated package version is installed to synchronize higher environments. UI-based change sets are still available, for promoting changes that aren’t contained in a package version or tracked in source.

This shows release management with source control, still using an org-based development model. Changes are tracked on a per-org basis, but relative to source. In this scenario, source control is used as the ultimate source of truth for the changes that are under active development. Developers check changes into source from their individual developer sandboxes. Conflict management and merging of individual changes happens within source control. Aggregated changes are deployed programmatically to build/test/release environments, based on the changes aggregated in source control. UI-based change sets, created through Setup, can still be used on an as-needed basis, as the top line shows. The addition of source control helps deal with the challenges of merging changes from lower environments, and allows you to start integrating tools like CI/CD to keep environments in sync. Additionally, this model provides more visibility and auditability into the release manifest. With every new release, you refresh source back to a clean slate.

a diagram of the development and release management strategy including source control.

Branching Strategies Package Based Example

The following diagram highlights the capabilities and strategy to manage branches between UW-Madison and partners through a package driven release strategy. In this diagram, the repo & subsequent branches at the top (in red) highlight how packaging can provide isolated source code which is accessible to partners without impacting the actual packaged solution. The partner can access the packaging source in isolation by pulling the source code into their own repos and then posting back to the main or by working in conjunction with the source owners in the main repo. This approach creates a highly secure and tightly controlled source code model where the code is available to all developers yet tightly controlled on who can update the actual / main source repo.

A diagram showing the master, hotfix,  develop, and UAT tracks for UW-Madison and Mater and Develop tracks for a partner.



KeywordsGitLab, Salesforce, resources, training, development, release, deploy, continuous integration, ci, continuous deployment, cd   Doc ID112096
OwnerTeresa A.GroupShared Tools
Created2021-06-30 19:28:46Updated2023-11-08 15:12:01
SitesDoIT Help Desk, DoIT Staff, Shared Tools
Feedback  0   0