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.
The following resources, descriptions, and images were provided by Salesforce.
Note: Not all features of Org development are available in Package Development. At times a hybrid approach is required.
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.
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.
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.