Salesforce Sandbox to Sandbox deployment using GitLab tool

What is GitLab?
GitLab is a GitHub like service that organizations can use to provide internal management of git
repositories. It is a self-hosted Git-repository management system that keeps the user code
private and can easily deploy the changes of the code.

The CI CD is supported only in Sandbox / Production / Scratch orgs and not supported in
Developer Edition orgs and trailhead playground
Below are the steps for the Continuous Integration / Continuous Deployment (CI/CD) from one
Sandbox to another.

1 – Connect your SF org to GitLab account using the JWT Authorization token flow.
The reason we need to use to JWT authorization flow
Continuous integration (CI) environments are fully automated and don’t support the human
interactivity of the OAuth 2.0 web server authorization flow. In these environments, you must
use the JSON web tokens (JWT) bearer flow to authorize an org.
The JWT bearer authorization flow requires a digital certificate, also called a digital signature, to
sign the JWT request. You can use your own certificate or create a self-signed certificate using
OpenSSL. With this flow, explicit user interaction isn’t required. However, this flow does require
prior approval of the client app

If the org you are authorizing is not hosted on https://login.salesforce.com, update your project
configuration file (sfdx-project. json).
Set the sfdcLoginUrl parameter to the login URL. Examples of other login URLs are your custom
subdomain or https://test.salesforce.com for sandboxes.
For example:
"sfdcLoginUrl": https://test.salesforce.com

Run the auth: jwt: grant CLI command.

Specify the client identifier from your connected app (also called the consumer key), the path to
the private key file (server. Key), and the JWT authentication username. When you authorize a
Dev Hub org, set it as the default with the --setdefaultdevhubusername parameter. For
example:
sfdx auth: jwt: grant --clientid 04580y4051234051 \
--jwtkeyfile /Users/jdoe/JWT/server.key --username [email protected] \
--setdefaultdevhubusername --setalias my-hub-org

This example shows how to use the --instanceurl parameter to specify an org hosted

on https://test.salesforce.com rather than the default https://login.salesforce.com:
sfdx auth: jwt: grant --clientid 04580y4051234051 \

--jwtkeyfile /Users/jdoe/JWT/server.key --username [email protected] \

--instanceurl https://test.salesforce.com

Prerequisites for CI/CD implementation in Salesforce

1- Salesforce sandbox / production org

2- Connected App / Consumer key
3- GitLab server
4 Self-signed SSL certificate
5 Private key and digital certificate
6 SFDX Environment and SF CLI
7 GitLab account
8 Open SSL installed on your local machine

Private key file is named as server.key and digital certificate is named as server.crt

The reason we need SSL certificate

The JWT bearer authorization flow requires a digital certificate, also called a digital
signature, to sign the JWT request. You can use your own certificate or create a self-
signed certificate using OpenSSL
Authorize an org using the JWT Bearer Flow
Step 1-

Integrate GitLab instance with your Salesforce SB org.

For this, we need a pair of Client ID and Client secret for that we need to create a new
Connected App in our SF org.

1. In Setup, enter App Manager in the Quick Find box, select App Manager, then
select New Connected App.
2. Fill in the application details into the following fields:
o Connected App Name and API Name: You can give any name for the App.
o Contact Email: Enter the contact email for Salesforce to use when contacting you
o Description: Description for the application.
3. Select API (Enable OAuth Settings) and select Enable OAuth Settings.
4. Fill in the application details into the following fields:
o Callback URL: The callback URL of your GitLab installation.
o http://localhost:1717/OauthRedirect
o Selected OAuth Scopes: Move Access your basic information (id, profile, email,
address, phone) and Allow access to your unique identifier (OpenID) to the right
column.
 5. (JWT only) Select Use digital signatures.
6. (JWT only) Click Choose File and upload the server.crt file that contains your digital
certificate.
7. Add these OAuth scopes:
o Manage user data via APIs (API)
o Manage user data via Web browsers (web)
o Perform requests at any time (refresh_token, offline_access)
o
8. Select Save.

After creating a connected app, we can test our connection with our packaging org by running

the command with the below-mentioned parameters.

app_id -    Client ID

app_secret -     Client Secret

name: 'salesforce',

# label: 'Provider name', # optional label for login button, defaults to "Salesforce"

app_id: 'SALESFORCE_CLIENT_ID',

app_secret: 'SALESFORCE_CLIENT_SECRET'

}
After creating a connected app, we required a script with SFDX commands to start a

pipeline written in YAML with the name.gitlab-ci.yml. Basically a gitlab-ci.yml file contains three

jobs like Build, Test and deploy.

9. On your GitLab server, open the configuration file.

For installations from source:
cd /home/git/gitlab

sudo -u git -H editor config/gitlab.yml

10. Add the provider configuration:

For installation from source:
- {name: 'salesforce',

# label: 'Provider name', # optional label for login button, defaults to "Salesforce"

app_id: 'SALESFORCE_CLIENT_ID',

app_secret: 'SALESFORCE_CLIENT_SECRET'

11. Change SALESFORCE_CLIENT_ID to the Consumer Key from the Salesforce connected

application page.
12. Change SALESFORCE_CLIENT_SECRET to the Consumer Secret from the Salesforce
connected application page.
13. Save the configuration file.
14. For the changes to take effect:
o If you installed from source, restart GitLab.

Once the SF org and GitLab are connected, then, you can deploy your components from your
local machine VS code to the GitLab repository and branch and from there you can deploy
those components to the target org by below steps.
Create a feature branch in GitLab
Pull the Dev branch into the feature branch
Add deployment folders to our local repository
Retrieve the metadata from our SF org using SFDX
Commit the changes on the feature branch
Push the changes from feature branch
Create a merge request from GitLab
Set up deployment variables from GitLab
Validate deployment with GitLab
Approve merge request in GitLab
Deploy changes with GitLab
Merge changes with GitLab
Steps – To create a CI pipeline
1 – Obtain a Dev Hub org, which is required for creating a scratch org in CI pipeline.
2 – In your Dev Hub org, enable both the features, Dev Hub, and second-generation packaging.
3 – Create an unlocked package.
4 – Create a new GitLab project.
5 – Configure CI/CD GitLab variables in your GitLab project.
6 – Clone your project locally
7 – Add your Salesforce DX source, to your local GitLab project then commit and push the
changes to the master branch, which will initiate the CI pipeline.

Steps completed
1 – Obtain a Dev Hub org – completed (Username - oytandale@empathetic-badger-
fuohws.com)
2 – Create a scratch org for CI pipeline – completed
3 – Enable Dev Hub – completed
4 – Enable second-generation packaging – completed
5 – Create an unlocked package – In progress
- { name: 'salesforce',
# label: 'Provider name', # optional label for login button, defaults to "Salesforce"
app_id:
'3MVG9n_HvETGhr3Dn6QwUTGJMH3fY61cFtZJcOO0S_EEY6iWMiTBREurJVHWp1aUritoGZ4tao
AYXubfUr3y7',
app_secret:
'1CC3AF6CC767744DA370DB804FC747008872AA214205F5664FCE6A6A34DC76A7'
}

Salesforce OmniAuth Provider 

You can integrate your GitLab instance with Salesforce to enable users to sign in to your GitLab
instance with their Salesforce account.

Create a Salesforce Connected App

To enable Salesforce OmniAuth provider, you must use Salesforce’s credentials for your GitLab
instance. To get the credentials (a pair of Client ID and Client Secret), you must create a
Connected App on Salesforce.
1. Sign in to Salesforce.
2. In Setup, enter App Manager in the Quick Find box, select App Manager, then
select New Connected App.
3. Fill in the application details into the following fields:
o Connected App Name and API Name: Set to any value but consider something
like <Organization>'s GitLab, <Your Name>'s GitLab, or something else that is
descriptive.
o Contact Email: Enter the contact email for Salesforce to use when contacting you
or your support team.
o Description: Description for the application.
4. Select API (Enable OAuth Settings) and select Enable OAuth Settings.
5. Fill in the application details into the following fields:
o Callback URL: The callback URL of your GitLab installation. For
example, https://gitlab.example.com/users/auth/salesforce/callback.
o Selected OAuth Scopes: Move Access your basic information (id, profile, email,
address, phone) and Allow access to your unique identifier (openid) to the right
column.

6. Select Save.
7. On your GitLab server, open the configuration file.
 For Omnibus package:
sudo editor /etc/gitlab/gitlab.rb

For installations from source:

cd /home/git/gitlab

sudo -u git -H editor config/gitlab.yml

8. Edit the common configuration file settings to add salesforce as a single sign-on

provider. This enables Just-In-Time account provisioning for users who do not have an
existing GitLab account.
9. Add the provider configuration:

For Omnibus package:

gitlab_rails['omniauth_providers'] = [

name: "salesforce",

# label: "Provider name", # optional label for login button, defaults to "Salesforce"

app_id: "SALESFORCE_CLIENT_ID",

app_secret: "SALESFORCE_CLIENT_SECRET"

For installation from source:

- { name: 'salesforce',

# label: 'Provider name', # optional label for login button, defaults to "Salesforce"

app_id: 'SALESFORCE_CLIENT_ID',

app_secret: 'SALESFORCE_CLIENT_SECRET'

}
 10. Change SALESFORCE_CLIENT_ID to the Consumer Key from the Salesforce connected
application page.
11. Change SALESFORCE_CLIENT_SECRET to the Consumer Secret from the Salesforce
connected application page.

12. Save the configuration file.

13. For the changes to take effect:
o If you installed via Omnibus, reconfigure GitLab.
o If you installed from source, restart GitLab.

On the sign in page, there should now be a Salesforce icon below the regular sign in form.
Select the icon to begin the authentication process. Salesforce asks the user to sign in and
authorize the GitLab application. If everything goes well, the user is returned to GitLab and is
signed in.

GitLab registration token - GR1348941MYbe4NMpP4GwEAU4yszz

Steps for GitLab runner - https://www.tutorialspoint.com/gitlab/gitlab_installation.htm

Connected App steps using JWT - https://developer.salesforce.com/docs/atlas.en-
us.sfdx_dev.meta/sfdx_dev/sfdx_dev_auth_connected_app.htm
Connected App steps using OmniAuth - https://docs.gitlab.com/ee/integration/salesforce.html