Validate deployment” but selecting deploy-test-sandbox rather than validate-test-sandbox. We can deploy without validation following “Step 11. Once the merge request is approved, we can deploy our changes. In the merge request, there is a button to approve. We will decide if we have to validate the package again. In case there are any comment which we want to apply, we should add the changes in other commit and wait for the approval. In order to grant quality in our code, other developer should review the merge request and add some comments. Select our “test_1” branch and click on “Run Pipeline”.Ĭlick on the play icon on the validate-test-sandbox job SF_CONSUMER_KEY_TEST_SANDBOX: in the connected app created in Saleforce in the Trailhead, gets the “Customer Key” value.
#Sourcetree gitlab license#
SERVER_KEY_PASSWORD: set the value for the license which you set up in the Trailhead commented on the “Overview” section.PACKAGEXML_FOLDER: set the value “test”.Go to “Variables” section, add the following variables: We can assign the reviewer on the “Assignee” field. NOTE: I suggest to add a reviewer (a dev or devops) to check the changes in the merge request before merging.
We should fill the title and the description. Select the “Source branch” field as “test_1” and “Target branch” field as “dev”.Ĭlick on “Compare branches and continue”. Open Gitlab -> our repository -> select “Merge Request”. Now the changes are on the “Stage files” area. Move changes from “Unstaged files” area to “Staged files”. Open the folder where we have the repo and write this command: sfdx force:source:retrieve -m ApexClass:ApexClassExample -u OUR_SANDBOX gitlab-ci.yml: file to deploy with Gitlab.
Go to the top of the post -> “Download” section -> get the files from GitHub -> add them in the folder where we have our repo -> we have the following folders: Now “test_1” branch should appear on the BRANCHES section. On Bitbucket -> on the REMOTES section, click twice on the “test_1” branch
Go to SourceTree -> Open our repo folder -> on the BRANCHES area, click twice on “dev”. We consider that “dev” branch is the source of truth of our dev sandbox which we will deploy.
#Sourcetree gitlab code#
Open your personal dev sandbox -> Open Developer Console -> File -> New -> Apex class -> Create a class called “ApexClassExample” -> copy and paste the code public class ApexClassExample Set up deployment variables in GitlabĬreate some changes which we will deploy later in other sandbox e.g. Push the changes from feature branch with SourceTree Commit the changes on the feature branch with SourceTree Retrieve the metadata from our personal sandbox with SFDX Create a new feature in our personal sandbox Moreover, the merge strategy is quite basic and we don’t consider any merge conflict because we focus on a simple implementation. We can validate and deploy the package with 2 Gitlab jobs shared in the GitHub link on the “Downloads” section.
#Sourcetree gitlab how to#
Here we don’t explain how to do the integration between Salesforce and Gitlab but it is a mandatory step before performing this post (for more information, go to this link). I do the local merge process with SourceTree. This post is about a CI/CD process to deploy from one Salesforce sandbox to another using Gitlab. Gitlab Continuous Integration (CI) and Continuous Deployment (CD) with SFDX, Salesforce and SourceTree
0 kommentar(er)
