Review the Release Lifecycle

Learning Objectives 

After completing this unit, you’ll be able to:

  • Describe the Marketing Cloud major release lifecycle.
  • Learn the steps for patch and emergency release.

Major Release Lifecycle

Let’s talk about how our product team makes the innovation magic happen! At Salesforce we follow an agile development lifecycle for each major release. We start by planning each release and then we have 8 to 10 weeks of development before a feature freeze. After that date, we focus on release readiness and then follow a staggered release process. Let’s review the phases of the lifecycle in more detail.

Lifecycle phases of a major release cycle.

Phase What's Happening More Info
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 Cloud 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 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 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.

Want to know if you are part of R1 or R2? You will receive notifications about when to expect your release, but behind the scenes the release you get is based on your stack and database instance. Stacks 4 and 11 receive R1. Stacks 1, 6, 7, 10, and 50 receive R2.

Release Procedures

As you can imagine, our teams are busy before a major release. We want to give you a behind-the-scenes view of what’s happening right before we reveal the new features to you.

When What's Happening
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.

Additional Releases

In addition to focusing on product enhancements and major release updates, our product teams work to fix bugs and research known issues. We follow a weekly patch release schedule to make regular updates to the product.

When What's Happening
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.

*This statement refers to weekly code releases.  Review this knowledge article on maintenance windows.

Emergency Release Lifecycle

Some fixes are just too important to wait until a weekly release. So when an issue gets escalated, we concentrate on finding a resolution—right away. After a fix has been identified and tested, it needs to be approved and validated before an emergency release is scheduled. Once planned, emergency code releases use a staggered deployment approach, similar to a major release. This allows us to focus on a deployment strategy with the least amount of risk.

Now that you know the release types and lifecycle, let’s talk about release notifications and preparation in the next unit.


¡Siga aprendiendo gratis!
Regístrese para obtener una cuenta y continuar.
¿Qué hay para usted?
  • Consiga recomendaciones personalizadas para sus objetivos profesionales
  • Practique sus aptitudes con retos prácticos y pruebas
  • Siga y comparta su progreso con empleadores
  • Conecte con el asesoramiento y las oportunidades laborales