Salesforce Platform Development Lifecycle and Deployment Architect

Advice only helps if it fits where the customer is today. You assess application lifecycle maturity, find the risks that matter, and recommend a path of improvements the team can actually adopt.

• Signs of low and high lifecycle maturity
• Interviewing a team about how it ships
• Finding risks in environments, code and process
• Mapping gaps to improvements
• Sequencing a maturity roadmap
• Presenting findings to sponsors

You build A maturity assessment with risks and a staged improvement roadmap.

The platform changes on its own schedule, and projects keep running. You plan how each Salesforce release is previewed, tested and absorbed, and how it coexists with several project streams at once.

• The seasonal release cycle and preview sandboxes
• Reading release notes for what affects you
• Release updates and when they become enforced
• Regression testing around a platform release
• Freeze windows and project calendars
• Coordinating several streams of work

You build A release calendar that absorbs platform releases across three project streams.

Environments are where process becomes real. You choose sandbox types and refresh rhythms, decide which environment serves which activity, and seed them with safe data.

• Developer, Developer Pro, Partial Copy and Full sandboxes
• Scratch orgs and when they replace sandboxes
• Environment per stream, stage and purpose
• Refresh cadence and what it destroys
• Seeding data and masking sensitive values
• Environment diagrams for a customer

You build An environment map with sandbox types, refresh rules and data seeding.

Tools should fit the team’s method, not drive it. You compare work-tracking tools, change sets, the Salesforce CLI, DevOps Center and CI servers, and recommend a toolchain for a customer’s skills and risks.

• Work tracking in an agile Salesforce team
• Change sets and their limits
• The Salesforce CLI in automation
• DevOps Center and what it simplifies
• CI servers and pipeline stages
• Recommending a toolchain for a customer

You build A toolchain recommendation that explains what each tool does in the pipeline.

Source control is the record of what changed and why. You design a branching model, handle merge conflicts in metadata, and agree what the source of truth is so that environments can be rebuilt from it.

• What belongs in source control
• Trunk-based, feature and release branching
• Merging metadata and resolving conflicts
• Versioning and tagging releases
• Pull requests as a control point
• Keeping production and source in step

You build A branching and merge policy with a worked conflict example.

Teams build on Salesforce in two ways, and the choice shapes everything after it. You compare org-based and package-based development, work with scratch orgs and source format, and handle dependencies between packages.

• Org-based development and its limits
• Package-based development and modular design
• Scratch orgs and the source format
• Namespaces and package dependencies
• Migrating an org toward packages
• Choosing an approach for a customer

You build A development approach recommendation with a plan to split an org into packages.

Quality is built in before deployment. You set up peer review and static analysis, define what a good Apex unit test looks like, and make quality checks part of the pipeline instead of a late event.

• Peer review that finds real problems
• Static analysis rules for Apex and components
• What makes an Apex test worth keeping
• Test classes and data factories
• Quality gates in a pipeline
• Managing technical debt over time

You build A code review checklist and quality gate configuration for a pipeline.

A deployment is only as complete as what the APIs can carry. You learn what the Metadata and Tooling APIs can and cannot deploy, plan manual steps before and after, and move reference data with the code.

• What the Metadata API deploys and what it does not
• The Tooling API and where it fits
• Deployment order and dependencies
• Validate-only and quick deployments
• Destructive changes and manual steps
• Reference data: custom metadata, settings and records

You build A deployment plan with ordered steps, manual tasks and reference data moves.

Testing needs a plan, not a hope. You recommend a methodology across unit, integration, regression, performance and acceptance testing, set a coverage approach, and design test data that is realistic and safe.

• Test levels and what each proves
• Coverage requirements and meaningful coverage
• Regression and automated UI testing
• Performance and load testing on the platform
• User acceptance testing
• A unified test data strategy

You build A test strategy with levels, coverage rules and a test data approach.

Release management is where all of the earlier choices meet. You weigh the three package types, plan sandboxes and branches for several streams, and handle hotfixes without breaking the main line.

• Unmanaged and managed packages compared
• Unlocked packages for customer orgs
• Choosing a package type for a team
• Release trains for several streams
• Hotfixes and back-porting
• Release notes and rollback plans

You build A release management plan for several streams, including a hotfix path.

Production is never as clean as the plan says. You handle changes made directly in production, detect drift, and manage shared artifacts and releases across several orgs.

• Why changes happen in production
• Detecting and reconciling drift
• Emergency change procedures
• Common components across several orgs
• Coordinating releases across orgs
• Retiring and archiving old components

You build An operating procedure for production changes and cross-org releases.

Take a customer with several teams and orgs and design the lifecycle: governance, environments, pipeline, testing and release. You justify each choice and show how the customer grows into it.

• Reading the customer’s current state
• Designing governance and environments
• Designing the pipeline and test approach
• Planning release and operating routines
• Presenting and defending the strategy

You build A full lifecycle and deployment strategy for one customer, with a staged rollout.