Level 1

Page:

Defect Resolution —
Crucial defects are quickly repaired and (MP) made available as patch versions to affected subscribers. ^(TBD)
Page:

Toggle Off —
Optional features promoted to GA or Beta in a release can be deployed in an activated or deactivated state and toggled on or off by the subscriber. ^(TBD)
Page:

Health Check —
The packaging and business orgs continue to pass the Salesforce Security Health Check following each major release, with a score of 80% or above. New subscriber orgs are reviewed with the Salesforce Optimizer before launch. ^(TBD)
Page:

Release Ready —
The packaging and pre-launch production orgs kept in a state of continual release readiness. ^(TBD)
Page:

Toggle Tests —
Validations are performed with all features toggled off, all features toggled on, and with only new features toggled on. ^(TBD)
Page:

Validation —
The latest work increment, is examined at the close of each sprint, to determine whether the version is ready-for-primetime. For MPs, a milestone version is validated. For CSs, a full staging sandbox is validated. For MPs, patch versions are run through the same gauntlet as major versions. ^(TBD)
Page:

Tag Repository —
The packaging or production branch in Git is tagged using the JIRA version ID. ^(TBD)
Page:

Merge and Deploy —
The new increment is merged, and deployed to the packaging org or production (using the Ant Migration Tool or SFDX tool). All metadata in the repository is deployed using a blank manifest ^(TBD)
Page:

Transient Branch —
To freeze the work increment being released, a temporary branch is created from develop, and a pull request created from the transient branch to packaging or production. ^(TBD)
Page:

GNG Baseline —
Just prior to the sprint retrospective, a master pull request and an updated change log are generated, for review at the retrospective and Go/NoGo meeting. ^(TBD)
Page:

No Pull Request Left Behind —
Prior to merging a new work increment, open pull requests from prior sprints are reviewed, to ensure completed work is not left outstanding. ^{^(TBD)}
Page:

You Break It —
^{Failed builds are raised up in email alerts for handling by the developer responsible for the last change. (TBD)}
Page:

CheckOnly After Merge —
^{(sf) On merge to develop, the updated develop branch is validated (checkOnly) with the packaging org or production branch. (TBD)}
Page:

Peer Review and Testing —
^{Peer developers review and test all changes before code and sample data is merged back to version control, following a test plan that is created for each issue in Confluence. (TBD)}
Page:

Context Help —
Help for this Page is extended for new tabs, updated as needed, and linked to Help Site. ^(TBD)

Level 2

Page:

Defect Timebox —
Rather than assign story points, initial work on a defect proceeds within a predefined standard timebox. If the defect cannot be resolved within the timebox, then whether to proceed is reviewed at standup. For example, the timebox may be based on how long it takes to resolve 80% of the defects ^(TBD)
Page:

Fail Events —
(sf) Issues found by failing Apex Unit tests or Selenium tests are posted to cloud-based logging systems, just like production errors and messages. ^(TBD)
Page:

Hammer Tests —
(sf) Subscriber Apex tests are run periodically to detect any new failures. ^(TBD)
Page:

Org Details Object —
(sf) To track additional detail about subscriber orgs, a custom object in the business org is linked to the LMA and the subscribers Account object. The org details aggregates the API applications installed for each subscriber, the instance, the my domain name, the production org ID, as well as the staging/preview sandbox IDs, and refresh history. Ideally, an automation posts an alert whenever a new org is added, to queue followup actions. ^(TBD)
Page:

Scope / Docs —
Validation includes the relevant help topics and other documentation (ApexDocs, Developer Guides). ^(TBD)
Page:

Scope / Tests —
Validation includes both regression tests and feature acceptance tests, in automated and exploratory form. ^{#TestLikeACustomerr} ^(TBD)
Page:

Automatic Change Log —
The change log is determined by observing the Git pull request, with little or no human intervention. ^(TBD)
Page:

Jira Change Log in your Confluence Wiki —
Update the change log to list the issues for the new version. (May be done in GNG Baseline.)
Page:

UI Regressions —
^{Selenium Nightwatch tests are included where appropriate to assure that the user interface will continue to work as expected. (TBD)}
Page:

Short Running Tests —
During code review both Apex unit test coverage and Apex unit test duration on new components is confirmed to be within expectations (less than five seconds per method). (See also ApexUnit.) ^(TBD)
Page:

Security Scan —
Common security issues are checked as part of peer review or static analysis ^(TBD)
Page:

Quality Scan —
^{Once a pull request is created, changes are verified through static analysis and by running the Apex unit tests. (TBD)}
Page:

OctoDocs —
Other shared components are documented with Octopus. ^(TBD)
Page:

Cache Partitions — (sf) Platform cache partitions are used in managed packages and local extensions where needed. ^(TBD)
Page:

Flows for the Win! — (sf) Flows are available for use in managed packages and local extensions. ^(TBD)

Level 3

Page:

Score Card —
A set of leading and lagging metrics are used to predict and then review the success of a CS project or MP major version and compared with actual results prior to the next event. ^(TBD)
Page:

Root Cause Analysis —
To ensure the quality and improvement of our change management process, and to prevent previously discovered problems from recurring, we perform a root cause analysis (RCA), by asking five whys. ^(TBD)
Page:

Defect KPI —
Defect reports and repairs are closely monitored and used as a key performance indicator. ^(TBD)
Page:

Defect Analytics —
Defect dashboards and reports are available in the business org. ^(TBD)
Page:

Feature Auditing —
(sf) FeatureSetupAuditTrail for subscribers are aggregated as part of Push Metrics. (Needs to be considered in the context of the Feature Management pilot.) ^(TBD)
Page:

Graceful degradation —
Apex unit tests can make configuration changes during a test run to confirm features work as expected when enabled or disabled. ^(TBD)
Page:

CheckOnly Before Merge —
(sf) The full set of Apex tests on the task branch is automatically validated (checkOnly) against the packaging org or production org when the pull request is created. ^(TBD)
Page:

Information Radiator —
Display key statistics, performance indicators, and inspirational messages in a highly visible location, for the benefit of team members and passers-by. (TBD)

Browser not supported