Loading
Salesforce Enforces New Security Requirements in Summer 2026Read More
Manage and Release Changes Easily and Collaboratively with DevOps...
Table of Contents
Select Filters

          No results
          No results
          Here are some search tips

          Check the spelling of your keywords.
          Use more general search terms.
          Select fewer filters to broaden your search.

          Search all of Salesforce Help
          DevOps Center Project Best Practices

          DevOps Center Project Best Practices

          Follow these best practices to plan your DevOps Center project. Project is a centralized workspace to manage and deploy a distinct collection of related work items.

          Required Editions

          Available in: Lightning Experience in Professional (API access required), Enterprise, Performance, Unlimited, and Developer Editions
          Not Available in: Government Cloud Plus. Contact your Salesforce account executive for more details.
          Not available in: EU Operating Zone. EU Operating zone is a special paid offering that provides an enhanced level of data residency commitment. DevOps Center is supported in orgs in the EU that aren’t part of EU OZ, per standard product terms and conditions.

          Determine the Number of Projects

          Use a single project and a single repository when:

          • Teams work on the same or dependent metadata and configuration data.
          • All changes deploy to the same production org.
          • You require unified visibility across all work.
          • Development involves interconnected objects and features.
          Note
          Note DevOps Center doesn't sync metadata and data across projects. To share changes, and surface conflicts early, teams must work on the same project to make sure that metadata and data dependencies remain synced.

          Create separate projects when:

          • Teams work on independent metadata and data with no dependencies.
          • Changes deploy to different production orgs.
          • Projects follow separate release schedules and governance.
          • You require isolated hotfix pipelines to bypass standard release cadences.
          • Teams require operational isolation or prefer to restrict visibility into the active work and changes of another team.
          Important
          Important Multiple projects increase management complexity. Create projects judiciously.

          Select Your Project Lifecycle Strategy

          Decide on a project lifecycle based on your release management processes and cadence.

          Ongoing projects: Use the same project across multiple sprints and releases. This is the recommended approach for teams with ongoing feature development and stable metadata and data scope. These projects are easier to maintain. For example, long-lived projects are ideal for a team that releases every two weeks and uses one pipeline regardless of the sprint. You can track project performance using DORA metrics and history in Activity History.

          Note
          Note DORA metrics are project-specific and don't provide data for all projects in DevOps Center.

          Per-release projects: Create a project for each major release. This approach works better for teams with discrete, time-boxed initiatives or major version releases. This requires more setup work for each release. We recommend that you archive the projects after the release.

          Hotfix projects: For critical production issues, use a separate hotfix project to support faster turnaround.

          • Create a project and connect to a pipeline that contains at least a development environment, a testing stage, and a production org.
          • After you resolve the issue, move all the changes through your standard project pipeline and keep all environments in sync.
          • Always back sync changes to your main project to prevent branch divergence.

          Manage Inactive Projects

          You can’t delete a project in DevOps Center. Add a z_ prefix to your inactive project. For example, z_MyOldProject. This moves the project to the bottom of the list.

          Configure the .forceignore File

          The .forceignore file determines which changes DevOps Center excludes during commit and deployment. Configure .forceignore file in the main branch before building your pipeline so it propagates to all feature branches. To modify a .forceignore file, apply the edits within the work items feature branch. The edits propagate through your pipeline as you promote the work item. See Exclude Metadata with .forceignore File.

          DevOps Center Project Strategy Recommendations

          SCENARIO Recommendation Example
          Same production org with overlapping metadata and data. One project, one repository structure A platform team customizes interconnected objects. Your team develops Sales Cloud features, where developers customize the Opportunity object while others work on Campaigns. Both features use shared custom objects. Use one project because the metadata overlaps.
          Same production org with independent metadata and data. One project structure (preferred) Parallel work tracks where an Apex team and a Marketing Cloud connector team deploy to a shared environment.
          Geographically or operationally separate production orgs. Separate projects Independent deployments to separate Europe and US production orgs due to data residency requirements. The orgs contain similar apps but deploy independently. Create two projects, one for each production org.
          Urgent, hotfix pipeline path required. Separate hotfix project Critical fixes that require an isolated path to bypass the standard release cycle.
           
          Loading
          Salesforce Help | Article