Salesforce Pull Request Workflow

VIDEO TRANSCRIPT | Recorded: 2025-01-08 | Verify against current system state

Abstract¶

This session provides a complete walkthrough of the Salesforce development workflow used with I2C (Integrate to Cloud). Jeff covers the initial setup requirements including Visual Studio Code with Salesforce extensions, Bitbucket integration, and the feature branch naming convention. The video explains the full pull request lifecycle from creating a ClickUp task, through development in a sandbox, to code review and deployment through I2C's testing environments to staging.

Key Procedures¶

• Initial setup: Install VS Code with Salesforce extensions, connect to sandbox environments
• Bitbucket setup: Install Bitbucket extension or clone directly, get token from IT Support account for push/pull access
• Create ClickUp task first: Every code change requires a ClickUp ID for I2C's CI/CD process
• Copy ClickUp ID from task (click copy or grab from URL)
• Pull dev branch from Bitbucket before starting work
• Create feature branch: feature/PR-{clickup-id} (optionally add dash and short description)
• Dev environment is the source of truth - deploy from dev branch to your sandbox
• Code drift warning: Staging may have changes not in dev; lean toward dev unless you know staging was modified
• Only deploy specific metadata files you're working on - avoid full org deploys due to sync issues
• Use SFDX commands in VS Code to deploy to sandbox and retrieve changes after testing
• Commit changes to feature branch, then create pull request in Bitbucket
• Pull request must include: ClickUp URL in description, explanation of changes
• Keep commits small - break up multiple changes into separate PRs when possible
• Pipeline runs automatically on merge to dev - check for success or failures
• Common failure cause: Merge conflicts from multiple developers on same files
• Request review from I2C (Victor) - they review within 1-2 days typically
• PR approval flow: PR → I2C internal testing → staging environment
• Monitor PR status - the longer it sits, the more merge conflicts accumulate

Notable Statements¶

• 0:00:47 "Really, the first thing you should do is create a ClickUp. If there's not a ClickUp already, you should create a ClickUp for this because you're going to need this ID."
• 0:01:01 "This ID is used in I2C's CI/CD process to match a feature branch that's created to a ClickUp."
• 0:02:32 "The dev environment is supposed to be the source of truth. This is the scary part because sometimes there are staging changes in place that aren't yet in dev."
• 0:02:54 "There is quite a bit of code drift and it's difficult to tell which one is the right one."
• 0:03:50 "I do not recommend pulling down or pushing up everything from dev into your sandbox... because staging environment is so out of sync."
• 0:04:01 "Identify the specific metadata records that you're going to affect, and then only deal with those specific things."
• 0:05:25 "The smaller your commit, the better it will be."
• 0:09:03 "The longer it sits there, the more merge conflicts you're going to have to deal with at a later date."

Systems & Configurations¶

Systems Mentioned¶

• Visual Studio Code (development IDE)
• Salesforce (sandbox environments, staging, production)
• Bitbucket (source control, pull requests)
• ClickUp (task tracking, CI/CD integration)
• SFDX (Salesforce DX CLI commands)
• I2C CI/CD Pipeline (automated deployment)

Specific Configurations¶

Credentials/Access Mentioned¶

• IT Support account for Bitbucket token
• Sandbox environment access
• Bitbucket repository access (AANP workspace)

Errors & Troubleshooting¶

• Issue: Pipeline failures after merge to dev
• Cause: Merge conflicts from multiple developers working on same files
• Resolution: Wait for other developer to finish, or have I2C cherry-pick your changes

• Timestamp: 0:06:10

• Issue: Code drift between dev and staging

• Cause: Changes made directly in staging not back-ported to dev
• Resolution: Lean toward dev as source; only accept staging if you know it was deliberately modified

• Timestamp: 0:02:54

• Issue: Changes not visible in AMP staging after PR approval

• Cause: PR only moved to I2C internal testing, not full staging yet
• Resolution: Wait for second approval to move from I2C testing to AMP staging
• Timestamp: 0:08:21

Transcript Gaps & Quality Notes¶

• Recording from live walkthrough session
• Duration: ~9 minutes
• Presenter: Jeff Sikes
• Audio quality: Good
• Some speaker attribution to "Speaker 2" appears to be Jeff continuing
• References ClickUp which may transition to different project management tool
• I2C workflow may evolve; verify current process with I2C contact