- 2Installing Flosum
- 3Setting up Flosum integration user
- 4Connecting sandboxes to Flosum
- 5Setting up users in Flosum
- 6Setting org permissions
- 7Decide on naming convention
- 8Initialize the repository
- 9Setting up workflow permissions Application Development Flow
- 10Pulling changes from dev sandboxes
- 11Branching strategy
- 12Conflict and Merge strategy
- 13Static Code Analysis
- 15Regression testing
- 16Reference Architecture Integrations
- 18TFS/Azure Devops
- 19Git Integrations Compliance & Governance
- 20Compliance & Governance
Branches & Branching Strategy
The purpose of this unit is to establish and document a branching strategy using the Flosum release management solution. We will explore different types of branches and discuss important considerations that will inform your decisions. Upon completion, you will be able to define how your team will use branches as part of your deployment process in Flosum.
What is a Branch?
Branches store code for each feature in a segregated matter and contain the code while it is in transit on its way from development to production. Branches can exist on several different levels. Each branch could either represent the changes made for a user story, the changes made by a team, the changes made during a particular sprint or the changes made for an entire enterprise release.
Your organization will probably use multiple different types of branches to facilitate testing, conflict management and deployments. Below we will explain the different kinds of branches and guide you through creating a branching strategy.
Using feature branches allows your team to isolate the changes made for each user story. For example, two developers may need to work on the same component for two different user stories. By committing their changes to two different branches, they can isolate their changes from each other while working in parallel.
Once developer changes have been retrieved from a development sandbox, a developer selects only the components that relate to the feature or user story they are working on and commits them to a feature branch. For example, a snapshot may have pulled in 30 changes, but the developer only commits the 5 components that he needs for this particular user story to the feature branch.
We have found that it is a best practice to use a separate feature branch to represent each unique user story, change request or piece of functionality. Creating a branch for each feature makes it easier to track user stories, identify conflicts, test and validate features and manage releases. The admin or developer responsible for a particular feature typically creates and owns a feature branch.
Flosum Features at the Feature Branch Level
Flosum offers several project management, code analysis and code review features at the Feature Branch Level that your team may choose to utilize:
- Agile Project Management Integration: If your organization utilizes an agile project management solution such as JIRA, Azure DevOps or Service Now, the feature branch can be mapped to a ticket within that tool.
- Code Analysis: If configured, Flosumwill automatically start static code analysis via Apex PMD.
- Code Review/Approval: Flosumprovides an option for code approval, called a "pull request." A developer can invite his team members to review his code within the feature branch. Team members can either approve or reject the code and provide comments before it is moved along in the development process.
A release branch is a branch that contains all of the code ready for a deployment into production. It typically contains code from multiple feature or integration branches.
Feature or integration branches are tested for code conflicts and then merged into a release branch. As a best practice, we recommend creating a separate release branch for each deployment.
The person creating the release branch should have visibility into the entire application development process. For example, she needs to know which features have been approved for the upcoming release. Because it should contain all of the code for a deployment, a team lead or release manager typically creates and owns the release branch.
Once a branch contains all of the code that is needed for that release, a deployment can be created in Flosum with just a few clicks of a button. Unlike change sets, this same deployment can be re-used as many times as desired.
Larger teams that have multiple developers working on one user story may choose to use an integration branch (also known as a merge, sprint or team branch) to combine their work into a single merged branch. Integration branches are an optional type of branch that can help an organization organize the work of multiple teams into releases.
Another use case for an integration branch would be for a team that combines work from multiple sprints into a single release. The team would merge all of the work completed during the sprint into a sprint branch and then merge the sprint branches into a release branch when they are ready to create a deployment.
Because an integration branch contains work from multiple developers, the best practice is to designate one person from each team to create these branches. Your organization may choose to have team leads or release managers create and own integration branches.
An environment branch is a branch that it is created to deploy changes to a specific environment (QA, UAT, etc.). Environment branches create challenges with syncing code across your organization’s environments because each environment would be receiving its own deployment.
Flosum contains an impact analysis feature which allows users to check their deployment against the target org to detect and resolve any conflicts. This negates the need to have Environment level branches which are notoriously hard to maintain. If your organization would like to ensure that all deployments are successfully deployed in QA and/or UAT environments before being deployed to production, explore our pipelines feature.
Repository/ Master Branch
Once the code is ready to be deployed into the production org, it should then be committed to the repository. A repository or master branch contains all of the code that has been deployed to production and includes all deployed changes made by any developer in any deployment. It is the single, complete source of truth for your code and feeds code downstream to the development sandboxes.
Flosum can support multiple repositories. We recommend that each production org have its own repository and that the repository be updated each time you deploy changes to production.
Updating the Repository
Keeping your repository synced with production ensures your developers always have access to the latest version of deployed code. An up-to-date repository is essential for keeping all of your development orgs in sync with each other.
We strongly recommend that you defer committing changes to the repository until you are ready to deploy those changes into production. Components should have passed all testing requirements (QA, UAT, etc.) and be approved for deployment to production before they are committed to the repository.
Branching Best Practices
- Branches should follow a standard naming convention. Names can be based on user stories, feature branches, ticket numbers etc. or project based. For example: Proj1Rel2 or Proj1Sprint3
- We recommend establishing a regular cleaning cadence for branches. For example, your team may decide to delete feature branches after the code in them has been released to production and committed to the repository.
- Use feature branches to isolate your code by user story. Consistently using feature branches enables you to track, analyze and manage code at the feature level.
- Implement pull requests if peer review is part of your development process. Using pull requests enables your team to complete and track code reviews within Flosum.
- Use the static code analysis feature for automated quality checks. This is an easy way to improve your QA process.
- We recommend you use branches for conflict and merge analysis.
- Establish governance on how branches are created. Please see the compliance and governance section for more information on this topic.