Please refer below blog to know how to setup gearset

https://blogs.absyz.com/2019/10/18/salesforce-ci-cd-introduction-to-gearset/

Software deployment involves installation, configuration, development, testing and Go- live/ releasing it to production for use. It can either be carried out manually or through automated systems. Release management provides a framework to control when and where changes are promoted from one Salesforce organization to another.

In this blog, we’ll see how we can automate the deployment pipeline using Gearset. 

Gearset CI can be set up with both Salesforce org and version control systems.

Prerequisites:

1. Add salesforce connections in gearset. (add a friendly name to recognize easily)

2. Add GitHub connection.

We’ll create a simple deployment path: 

1. Dev to QA 
2. QA to Git Branch 
3. Git Branch to Production

Let’s see how we can run the deployment cycle using gearset.

I. Dev to QA

In an initial stage, developers/admins start working on features and their components in developer org. They will finish the unit testing and will hand over the features to QA team for testing. QA team will test in separate environment called QA org

I created 1 new field in account called classification and added trigger on account 

Let’s see how we can compare a deploy these changes from dev to QA org

1. Go to gearset and click on compare and deploy
2. Select source as developer org and destination as QA/Testing org 

     3. Click on Compare Now. you’ll be redirected to the Comparison page as shown below. Wait for the process to complete

        4. You’ll be redirected to the comparison result page, which shows the metadata differences between source and target. You can see what changes have been made, when and by whom at a glance, without the need for manual XML diff or change tracking documents.

Metadata items are shown in the table with the following columns:

Name: the name of the metadata item

Metadata type: type of metadata (eg: profile, custom field)

Difference type: whether the item is New, different, deleted or No difference

Changed on: the last modified date for the item

Changed by: who made the last changed to the item

You can also add the filter to above columns 

Gearset group changes to your metadata by their types:

• • Different (changed item): the item exists in both source and target but there are differences between your source and target; deploying it will update the target with the version from the source
  • New: the item only exists in your source; deploying it will add this item to your target
  • Deleted: the item only exists in your target; deploying it will remove this item from your target
  • No difference:  the item exists in both source and target and is identical; you can’t select it as there would be no changes to deploy 

     5. Click on any metadata item to view the line by line comparison between source and target in the diff viewer. In the screenshot below I selected a new custom field called company classification. Its new item so in the target, it is showing blank.

      6. In the screenshot below I selected a changed metadata item: Account Page Layout. I’ve added my new field company classification to the layout. The layout exists in target but the field on layout is not there. In the diff viewer, you can see the changes.

     7. Select the items you want to deploy, you can view them in the selected items tab

     8. Review the changes and click on next. You will be redirected to the deployment summary page. Give a name for your deployment. There are 2 options here:

        1)  Deploy now: deploys the selected changes to target

        2) Validate deployment: perform a check-only deployment, running any tests in your target and checking the validity of the components without actually applying them to your target.

You can choose the option based on your requirement. I’m clicking on deploy now. 

     9. When the deployment finishes, you’ll see a summary of the key information. Gearset will email you a copy of the deployment report as a PDF. You can also download this report from the deployment page, or from your deployment history.

           Done! we pushed the changes to QA. QA team will do a full round of testing. After finishing the test case execution we are good to go to the next step.

II. QA to Git

Our next step is to push the changes to the Git Branch.

Let’s see how we can move the changes from salesforce to git using gearset.

1. Go to compare and deploy page and select source as QA org and target as source control git. I created a new branch V_1.5. I’m going to deploy the changes to this branch.
2. View the changes and select the required changes and click on deploy.
3. You can always roll back the deployment changes from the deployment history page

Done! We successfully moved the changes to git branch. 

III. Git to Production

Our next step is to push the changes from git to production env. 

We are going to create a Continuous integration job(CI job) to automatically push the changes from git to production.

Let’s set up the CI job in gearset:

1. From Automation select Continuous integration.fill the details as per your requirement

 Name: name of your CI job

Source type: here Github, if you are using any other source control choose that

Source repository: select the repository from your source control

Source branch: select the branch which has the metadata components

Target type:  salesforce 

Target org: select production salesforce connection

Run job: Choose how often you want the job to run. If you’re using a Salesforce org as the source, this can be every 4 or 24 hours. If you’re using version control as the source, you can alternatively choose to run the job when the source branch is updated.

Difference types to deploy: new items and changes items

      2. Let’s set up  a webhook for a CI job from source control

Webhooks allow Gearset to detect changes pushed to a repository in real-time, without having to poll to see if anything has changed. Whenever you push to the repository you’ve set up, Gearset will immediately pick those changes up and sync them to your target.

Click on Webhook setup from CI job.

Popup will be shown as below, Copy the payload URL and shared secret.

Now we need to set up a webhook in our source control system.

Go to your GitHub repository and click on settings and new webhook. 

Paste the Payload URL and the shared secret and set content type as JSON Format.

      3. Let’s choose the metadata types we want to deploy

• • This defines which metadata types the CI job will compare and deploy between your two orgs. 
  • Click on the metadata filters tab, then you can specify whether you want to retrieve all of the items within a metadata type or just a subset. By default, the setting will be on All items.

     4. Let’s set up the Notification preferences for CI job

• • Select on the Notification settings tab
  • Choose whether to get notified after every CI job run, irrespective of the outcome or only if the CI job fails.
  • Enter the email address(es) of who to notify of the result.
  • Gearset also supports SMS notifications (US, UK and Australia only), Slack and Microsoft Teams integration via webhooks, and Chatter integration.

    5. We successfully created a CI job

      You can now perform the below actions.

• • Enable/disable
  • Run the job
  • View history

You can view the job history and comparison at any time.

Other features provided by Gearset:

We can also integrate gearset with Jira and cruise control. Refer below links for more details:

https://docs.gearset.com/en/articles/1384669-integrating-with-jira

https://docs.gearset.com/en/articles/1155842-integrating-gearset-with-cruisecontrol

We can also deploy data using gearset, refer below link for more details:

https://docs.gearset.com/en/articles/1376661-data-deployments-with-gearset