This article describes the primary concepts and terminology used in Flosum.
By using Flosum ALM Snapshots, you can pull recent changes from your developer orgs into Flosum ALM. You can select a date range to check for changes. Flosum ALM will inspect the developer org and retrieve the changes for the dates specified.
Within the Flosum ALM solution, Deployments are outbound deployments. Deployments are also manifest-driven which means, unlike change-sets, you will not have to create them over and over again.
*Patches have been renamed to Deployments.
A Branch isolates the code changes between different streams of development. Having separate branches allows developers to work independently while making simultaneous updates to the same component without stepping one another’s toes.
For example, Developer A can make changes to the Account trigger in one branch while Developer B can make changes to the same component in another Branch at the same time.
We recommend as a best practice that a new branch is created for every new work item such as a new feature, case, user story, or a bug fix.
A Snapshot is taken of the changed components within a dev org. Those changes can then be committed to the branches.
Changes to components from the branches to the Repository should be committed only when:
- the code is ready to be deployed to production
- the development of the feature is complete
Version Control & Repository
Flosum's version control has all the capabilities of a modern version control system including:
- Multiple branching strategies
- Full historical details of every component
- Full view based on user stories
- Full traceability of all actions by every team member
- Special handling of different metadata types
- and much more
Flosum's version control provides all the capabilities of the version control that are applicable to the Salesforce platform, in addition to 100% support of all the metadata types.
Advantages of using Flosum's version control:
- Completely built on Salesforce & Built specifically for Salesforce
- Easy to use, no training required
- Version Control History differences
- Differences between files
- Commits by User Story
The Repository can also refer to the main line, trunk, master branch, or the head of version control. The Repository is the central database which tracks all the latest changes from each developer. Developers can also review past historical changes made by other developers.
During implementation, the Repository is initially populated with the code from the production org so that all changes from that point forward can be tracked.
When using Version Control, the code in the production org maps to a version of the code in the Repository. There is only one Repository in each Flosum org.
All the developers share this Repository and commit their changes to their Repository when the code changes are completed.
It is a best practice to first commit the code to the Repository, and then deploy the committed code from the Repository to the production org.
A log of Commits is a record that is created when you commit a set of changes from the branch to the Repository. This information is tracked under the Commits tab within Flosum ALM.
Let’s touch upon a final topic: Conflict Resolution. Conflicts can arise in two instances:
- When a developer is committing changes to a branch
- When the branch is being committed to the Repository
For example, when a change is committed from a branch to the Repository, it can result in a conflict if the components in the branch that you are committing has been modified by someone else since you started making the changes in your branch. A conflict is detected when two developers are making changes to the same component and one developer is about to overwrite the changes of another developer.
During the conflict management process, conflicts are automatically detected by Flosum ALM and the components are categorized into three different categories:
Components that have conflicts: These are the components have been modified by some other team member. The corrective action is to refactor your code with the latest version of these components from the branch to ensure the previous changes are not lost.
Components that are safe to commit: No other developer has touched these components in the Repository. Hence, the changes are safe to commit to the Repository.
Components that will not be committed: The same version of these components already exists in the branch or the Repository. Hence, these components will not be considered for committing.
Putting it All Together
This diagram shows how all the overall terms fit together. Let’s follow the diagram from left to right.
Let’s assume that you are working on two new features in your developer org. For Feature A, you modified two components and for Feature B, you modified three components in your developer org.
As you are developing these features, you can create snapshots periodically, as required, to pull the changes into Flosum ALM as a backup of your code. For each of the two features, you can create a separate branch—one for Feature A and another for Feature B.
*Patches have been renamed to Deployments
From the snapshots, you can commit the changes to their respective branches. Because you may not have finished your development after your first commit to the branch, you can make more changes in your developer org, pull the new changes via snapshot and commit those changes into the branches.
The changes on your branch are private and available you and those working on the feature.
After you are done with your feature development, you can commit the completed changes in the branches to the Repository. Once the changes are in the Repository, a deployment can be created from the Repository and deployed to any organization.
Here is the summary of all the terms:
*Patches have been renamed to Deployments