Salesforce Collaborative Development with Git

The absence of Version control system in Salesforce makes it possible to overwrite each other’s class in Salesforce org without any track and it becomes a problem as it’s impossible to recapture the overwritten classes.
Version Control tracks any kind of changes in classes created by different developers and store it as a snapshot.

GIT:

-A software tool that controls the multiple versions of classes.

-An application that keeps a record of all the changes made on a project over time. 

Categories of VCS:

  1. Central
  2. Distributed(GIT)

In a distributed VCS like GIT, each collaborator gets a copy of the entire repository at any time (all branches and commits) on a developer’s machine.

VCS also make sure that there’s no address problem issue while collaborating.

Tools and workflows are there to improve communication and overall quality.

GIT Hub:

-A platform on top of Git.

-A community space where a work can be shared.

– Team’s work can be seen. (Code reviews, Integration connection, testing and code deployment)

Difference between Git and Git hub:

A distributed VCS that keeps track of changes to contents

and also provides a method for sharing that with others.

A company (or an application) that provides Git repository hosting.
 

Handles Versions

 

Handles Collaborations.

Repositories:

The record of all the changes made on a project is saved in a data structure called repository.

Commits:

It’s a snapshot of a project that indicates points each time a piece of work is added or removed.

Branch:

A series of commits that represents the changes in the project done over time.

Merge:

Combination of two or more branches (Combined History).

Tag:

A pointer that persistently refer to an event.

 

Bit Bucket (A Collaboration Platform)

-A highly transparent and contextual environment for developers.

-Branch permissions provide granular access control for your team, ensuring the right people can make the right changes to your code.

The collaboration features to apply and test changes to the code are offered by Bit Bucket.

 

Terms in Bit Bucket:

  1. Issues-A general discussion of a project. It is incorporated right into a bucket repository.
  2. Pull Request-It lets you tell others about the changes you have pushed to the repository.

-Interested parties review the set of changes, discuss potential modifications and even push follow-up commits once a pull request is sent.

-A comparison between two branches (between master (the branch with production code) and another branch used for code in development).

 

Bit Bucket Workflow:

It lets you experiment with new ideas without any fear of compromising a project.

The main steps are:-

  1. Create a branch off of master
  2. Make commits
  3. Open a pull request
  4. Collaborate
    1. Make more commits
    2. Interact with integrations
  5. Merge to master branch (once changes are approved by the team, pull request is merged into the master branch)

(Branches are deleted once they are merged)

– Short-lived branches prevent confusion, encourage up-to-date code, and set up developers for iterative improvements to projects

 

  • Open: the feature is ready to be worked on.
  • In Progress: the developer has commenced work.
  • In Review: the developer is having their work peer reviewed and iterating on it.
  • Done: the work is complete.
  • Ready for Testing: the feature has been deployed to UAT.
  • Ready for Deployment: the feature has been tested and is ready for deployment to Production.

 

 

Version Control & Feature Branching

Our Salesforce workflow requires three separate repositories, each representing a different Salesforce org.

  1. Developer Sandbox:t his repository is the first repository to which a new feature is merged. Features are first merged to the Developer Sandbox’s master branch to ensure that all integration tests are passing before promoting the changes to UAT.
  2. UAT: if the master branch of the Developer Sandbox is passing, it can be merged into the master branch of the UAT repository. Changes to UAT’s master branch are automatically deployed to the UAT Salesforce org, where end users can test that the new feature is working correctly.
  3. Production: Once the end users are satisfied, the UAT master branch can be merged to the Production master branch. Like UAT, changes to Production’s master branch are automatically deployed to the Production Salesforce org.
Please follow and like us:

Leave a Reply

Your email address will not be published. Required fields are marked *

WordPress spam blocked by CleanTalk.