We’re Here to Help!!

Find A Solution, Learn Best Practices & Get Support 24x7

Reference Architecture

Follow

Release Management
Implementation Guide

Index

    Core Setups
  • 1Overview
  • 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
  • 14Apex
  • 15Regression testing
  • 16Reference Architecture
  • Integrations
  • 17Jira
  • 18TFS/Azure Devops
  • 19Git Integrations
  • Compliance & Governance
  • 20Compliance & Governance
Example #1- A Smaller Organization with One Development Team
This example shows a basic application development flow for a small development team. In this reference, the developers are all working in parallel the same release and use the same organizations for QA and UAT. 
mceclip0.png
1.) In a typical application development lifecycle, the flow begins with the Development Team. This team  consists of three members working on their user stories separately in their development sandboxes. 
 
2.) Next, each developer will pull their desired changes into Flosum. The developer can accomplish this by utilizing one of three methods:
 
  •  The developer can pull what is referred to as a "Snapshot" of their sandbox. The Snapshot is a visual summary of all of the components that have been modified in that org in a specified period of time. For example, a snapshot can be pulled to show the changes made in the last day or last 30 days. 
 
  • The developer can create branches using Local Flosum.
 
  • The developer can utilize Flosum's continuous retrieval functionality. This functionality sits inside the developer sandbox, and automatically scans every 15 minutes and pulls any changes into Flosum.
 
3.) Once the changes are within Flosum, the developer will then decide which changes they will need for the user story they are working on and pull them into a feature branch. Each feature branch can map to a ticket within Jira, TFS, Azure DevOps, VSTS, Service Now, etc.  and specify which components have been changed. 
 
4.) If configured, Flosum will automatically start static code analysis via Apex PMD.
 
5.) Once the code has been tested, the developer will create a "Pull Request." This is a code review functionality that signals a request to other stakeholders (developers, managers etc.) to review the developer's code within the feature branch. These stakeholders can Approve or Reject the code well as give comments. 
 
6.) If the feature passes review, it is then merged into the release branch with the other developers' code. During this merge, Flosum will detect and help resolve any conflicts. 
 
*Please note that for the steps below, deployments can be done step by step to each environment, or a pipeline can be set up for Continuous Integration in which the deployments will automatically trigger through all of the environments. 
 
7.) Once the release branch has all the code from various developers, it is then deployed to the QA environment. In the QA environment, Selenium tests can be run to ensure there is no regression. 

8.) After ensuring there are no regression issues, the release branch can be promoted to the UAT org for business approvals.

9.) Once approvals are given, the branch can be deployed into production (manually or via automated CI process). 
 
10.) Once changes are pushed into production, they can also be merged into the repository (which is the master version of all of the changes that have been pushed into production). 
 
11.) Lastly, any changes that have been pushed into the repository can be deployed back into the developer sandboxes so that developers have the latest and greatest code to work with. 
Example #2- A Larger Organization with Multiple Development Teams
In this example, we will look at a sample application development flow for a larger organization that has multiple teams of developers working in parallel on the same release. This organization utilizes separate organizations for QA and UAT. 
mceclip0.png
1.) The flow begins with the Development Team. This organization consists of three teams of developers. Each team is working on their user stories separately in their development sandboxes. 
 
2.) Next, developers will pull their desired changes into Flosum. The developer can accomplish this by utilizing one of the same three methods:
 
  •  The developer can pull a "Snapshot" of their sandbox. This is the method shown in this example. 
 
  • The developer can create branches using Local Flosum.
 
  • The developer can utilize Flosum's continuous retrieval functionality. 
 
3.) Once the changes are within Flosum, the developer will then decide which changes they will need for the user story they are working on and pull them into a feature branch.
 
4.) If configured, Flosum will automatically start static code analysis via Apex PMD.
 
5.) Once the code has been tested, the developer will create a "Pull Request." This is a code review functionality that signals a request to other stakeholders (developers, managers etc.) to review the developer's code within the feature branch. These stakeholders can Approve or Reject the code well as give comments. 
 
6.) If the feature passes review, it is then merged into the team branch with the approved code from other developers on that team. During this merge, Flosum will detect and help resolve any conflicts. 
 
*Please note that for the steps below, deployments can be done step by step to each environment, or a pipeline can be set up for Continuous Integration in which the deployments will automatically trigger through all of the environments. 
 
7.) Once the team branch has all the code from various developers, it is then deployed to their QA environment. Each team branch will be deployed to QA separately. 

8.) After ensuring there are no regression issues, the team branch will be merged to the release branch. It will again be tested for conflicts during this merge. The release branch will contain the code from all three development teams and will be used to create the deployment.

9.) The release branch will then be promoted to a UAT org for business approvals.

10.) Once approvals are given, the release branch can be deployed into production (manually or via automated CI process). 
 
11.) Once changes are pushed into production, they will then be merged into the repository (which is the master version of all of the changes that have been pushed into production). 
 
12.) Lastly, any changes that have been pushed into the repository can be deployed back into the developer sandboxes so that developers have the latest and greatest code to work with. 
 
Print Friendly and PDF
Was this article helpful?
0 out of 0 found this helpful

Comments