Review the Release Lifecycle
Learning Objectives
After completing this unit, you’ll be able to:
- Describe the Marketing Cloud Engagement 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.
| Phase | What's Happening | More Info |
|---|---|---|
|
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. |
|
|
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. |
|
|
Release Readiness |
At feature freeze, only completed features that have been tested, validated, and approved are included in the release. |
|
|
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). |
|
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, 11, 13, and 50 receive R1. Stacks 1, 6, 7, 10, 12, and 51 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:
|
|
1 to 2 days prior to the release |
During pre-release activities, we:
|
|
Release day |
To ensure minimal impact:
|
|
1 day after the release |
We check in with:
|
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 |
|---|---|
|
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. |
*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.
