Lifecycle Center Project Best Practices

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 Lifecycle 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 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 DORA metrics are project-specific and don't provide data for all projects in Lifecycle 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 Lifecycle 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 Lifecycle 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.

Lifecycle Center Project Strategy Recommendations