Review the Release Lifecycle

Planning

Teams review and plan for what they want to complete in the upcoming major release. They review their product wishlists, product ideas on IdeaExchange, and known issues.

• Got a great idea for a product feature? Visit Marketing on the IdeaExchange to tell us about it.
  
• Check the status of known issues on the Salesforce Known Issues site.
  

Agile Development

Once a plan is in place, teams organize the work into sprints where they focus on specific features to build and test. The development cycle ends with a feature freeze, the date when all incomplete features are removed from the upcoming release.

• Build, test, and repeat! All features go through a series of unit, functional, and performance tests before being added to a release.
  
• After feature freeze, teams begin the process again for the development of the next release.
  

Release Readiness

At feature freeze, only completed features that have been tested, validated, and approved are included in the release.

• Additional tests are performed, including backward compatibility testing, integration tests, functional tests, database and deployment script validation, along with customer use case validation.
  
• Multiple teams must approve updates.
  

Staggered Releases

Once approved, Marketing Cloud Engagement releases new features using a staggered release approach. All customers receive release updates during either our release one (R1) or release two (R2).

• Before we release R1, we have an internal R0 release to allow internal teams with Salesforce Marketing Cloud Engagement accounts to conduct even more tests.
  
• Approximately 25% of customers are included in R1 based on their database instance.
  
• The remaining 75% of customers are included in R2.
  

2 to 3 weeks prior to release

During release readiness activities, we:

• Meet with executives to review testing and preparedness playbooks.
  
• Confirm release signoffs from executives.
  
• Close any outstanding functional issues.
  
• Finalize deployment components.
  

1 to 2 days prior to the release

During pre-release activities, we:

• Make backward compatible SQL schema updates. (Which basically means we prepare for the worst by making sure there is a rollback option in case an issue occurs.)
  
• Prepare for no downtime or any disruptions.
  

Release day

To ensure minimal impact:

• At 12 PM EST on release day (which is always Saturday in the US), we deploy database and code updates. This day and time was selected because it has the lowest amount of customer traffic.
  
• For quality control, we conduct automatic and manual data validations right after the release.
  

1 day after the release

We check in with:

• Site reliability, support, release management, and engineering to see if there are open release-related issues.
  

We use:

• Monitoring tools to proactively identify and resolve issues before affecting customers.
  

Ongoing

Bugs are being researched and reviewed for possible fixes. Once a fix has been identified and any code changes occur, they are tested thoroughly.

2 days before release

Approved fixes are locked in for the next patch release. Teams also finalize deployment components and confirm their deployment plan.

1 day before release

New code is deployed to an internal production instance at 2 PM EST. Teams track and monitor the deployment and conduct additional tests.

Release day (Wednesday)

With no downtime*, new code is deployed to all customers at 8 PM EST on Wednesdays in the US. Additional smoke tests and validations occur after release.