CI/CD Process Handover

1. Checkout to the source branch. Make sure to take note of your changes that must be merged and deployed.

2. Run the Git fetch command.

3. From the Terminal, run the Git checkout command to copy the contents of a file from the target branch:

   git checkout <target_branch> -- <file_path>
   git checkout origin/master -- 'force-app\main\default\classes\SampleClass.cls'

4. The file will now be the same as what is in the target branch, and your changes will be overwritten. Commit and push the staged changes.

5. Create a pull request, merging the source branch to the target branch. This pull request should not contain your actual changes, and will only contain changes found in the target branch but not in the source branch.

6. With the file still open, manually add your changes. Commit and push to the remote branch.

7. Create a second pull request, merging the source branch to the target branch. This pull request will contain your actual changes, but with no more merge conflicts.

1. Create a new, temporary branch based from the branch you want to revert a merge commit from, e.g., TAP-1250-RevertFromMaster based from origin/master

2. Get the Commit ID of the merge commit you will revert, e.g., 294229cf

3. Make sure you are checked out to the temporary branch. From Terminal, type command:

git revert <commit id> -m 1
git revert 294229cf -m 1

4. Commit the changes in the temporary branch, and then publish branch

5. From the temporary branch, create a pull request to the target branch, e.g., TAP-1250-RevertFromMaster to origin/master

6. Once pipelines are successful and PR is approved, merge to target branch

1. This process is done after PROD deployments to sync sit and uat branches with master, and uses a “no-commit” branch that is based from master. Use the branch: ALL-noCommitFromMaster.

2. Make sure to rebase the no-commit branch by running a Git pull command:

git pull origin master

3. Push the commits.

4. Create a pull request for merging ALL-noCommitFromMaster to sit, and another pull request to merge the same branch to uat.

Using VS Code

1. Navigate to Git Graph. Make sure to run fetch from remote(s).

2. Right-click on a branch and select Delete Branch….

3. If the branch needs to be deleted on the remote, tick both checkboxes. Otherwise, just click on Yes, delete.

Using the Terminal

1. To delete a branch locally, run the following command:

git branch -d <branch_name>
git branch -D <branch_name>

• -d is a shortcut for --delete, and -D is a shortcut for --delete --force

2. To delete a branch remotely, run the following command:

git push <remote_branch> -d <branch_name>

1. In VS Code, navigate to Explorer. Right-click on the file and select Delete.

2. From the Source Control tab, deleting the file will show up as a file deletion under Changes. Follow the same steps as you would for deploying changes: stage the changes, commit and then push to remote.

3. In Bitbucket, create a pull request to merge the source branch (where the file was deleted locally) to the target branch. Do note that upon merging, the file will be deleted in the target branch, but not on the target environment. Please see the following section: Deleting components in org.

1. As a prerequisite, the target org must be authorized in your VS Code. Please see /wiki/spaces/SNGL/pages/2715779242 for guidance.

2. In VS Code, create a temporary directory in the project source.

3. The destructive changes process requires two files: destructiveChanges.xml and package.xml. The destructiveChanges.xml will contain the components for deletion, and the package.xml must be an empty package file.

4. From the Terminal, run the following command:

// RECOMMENDED: validate the destructive change first
sfdx force:mdapi:deploy -c -d <folder_name> -l RunLocalTests -w -1
sfdx force:mdapi:deploy -c -d destructiveChangesTAPSS1349 -l RunLocalTests -w -1

// the actual destructive change
sfdx force:mdapi:deploy -d <folder_name> -l RunLocalTests -w -1
sfdx force:mdapi:deploy -d destructiveChangesTAPSS1349 -l RunLocalTests -w -1

4. This process will initiate a deployment, and thus can be monitored in Setup > Deployment Status.

5. IMPORTANT: The directory should not be staged as changes and pushed to the branch.