Krdytkyu

The current development and deployment is from sandbox to sandbox and the plan is to move to git based deployments.

What is the best way to get all the metadata of an existing org into Git(bitbucket) for the first time into a master branch?

What will be the optimal release flow, if people are developing or configuring out of single sandbox (I know this is not ideal)

What is the best way to get all the metadata of an existing org into Git (Bitbucket) for the first time into a master branch?

You need to generate a package.xml to pull all the existing metadata that you're planning to manage in Git and execute a Metadata API retrieve operation. You can construct the package by hand, or use a tool to prepare one.

One option is to use the Eclipse Force.com IDE to build the package by selecting the components that you want. You can then pull them via Eclipse, or use Workbench to perform a clean retrieve in a different working environment. Then, commit the extracted results to Git.

What will be the optimal release flow, if people are developing or configuring out of single sandbox (I know this is not ideal)

There is unfortunately nothing optimal about that sandbox layout, although the diagram you included suggests that your workflow may actually be a little more sophisticated and include individual Developer sandboxes for your developers, with a single shared sandbox for declarative work.

Release flow and cadence is very organization- and process- specific.

My general recommendation is to ensure that Git branches and merges are being used in a best-process fashion. With multiple Dev sandboxes feeding a single Dev Pro/integration sandbox, I would be skeptical about having developers do direct deployments to integration.

You'll need to define an effective workflow here to ensure that developers pull and merge work from an integration branch corresponding to that sandbox (likely into their own feature or story branches) before pushing to the integration sandbox in order to avoid overwriting code. Declarative work could be pulled directly from integration and checked in on the integration branch.

Pull requests could then be made from the integration branch to a QA branch for deployment upwards, and ultimately to master for release to production.

Even if you're not using Salesforce DX, you want to ensure that Git is defined as the source of truth for your org, not the contents of the sandboxes. The sandbox content should always be amenable to being replaced with a deployment from one of your main branches.

This is definitely an area where someone on your team needs to have the relevant expertise on managing a Git-based development flow - it's hard to use this kind of architecture operationally by just following instructions.

While I will recommend to move to Salesforce DX, but in the traditional model of release management, your master should always be a replica of what's in Production.

A typical flow that I have followed in the past is:

• 
  

  Create master as the gold copy. This should be your most recent stable copy of running code in Production. You will need to decide which metadata is important for you to version manage. E.g., if you are only looking to version control Apex, Triggers or you are also looking to version control say Roles, Profiles, etc. My approach to this is that what we build, is version controlled.

  
  
  

  As for how to extract the metadata, you will need to use the Metadata API to extract it from Production and commit it to the repo. You can use Force.com IDE for this purpose. Take a look at this link for details.

  
  


• Create release branch from master. I have usually followed an approach here is to release only what's needed. This is because if you have too many components in the branch (say, copied over from master) which are not modified in the current release, will lead to a longer deployment time. While this depends on the approach if you want to release from master or release branch, but in general, you should only deploy what's required.


• Developers create feature branches from the release branch, build, test and create PRs to merge to the release branch


• Release your code from the release branch to Production


• Merge with master after release

There can be different ways to handle depending on the scale and choice, but typically this approach has worked well for me.

You will definitely need to take care of other aspects, viz., code reviews, code merging, etc. but as long as you can put the process in the place, this will work fine.

This approach also works if your developers are working out of a single sandbox, because every developer will create the feature branch and before it can be merged to the release branch and moved to upper environments, you can implement a review process to make sure the code being committed to the release branch is validated.