Consulting Services

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:
    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:
    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:
    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)

  • Page:
    Permissions

    (sf) User access to new components is handled through permission sets and an optional stub profile. For MPs, updating customer permsets or profiles is handled through Direct Deployment. (TBD)

  • Page:
    Issue IDs in Commit Logs

    Each and every commit references an issue ID, so that we can trace from the commit to the issue tracker (and vice versa).  Ideally, this practice is enforced by a pre-commit hook so that the Version Control System will not accept a commit that does not reference an issue tracker ID. (TBD)

  • Page:
    Ready to Review

    Automated Pull Requests - Any changes made to the development environment can be automatically committed back to version control, without special knowledge of GitThis task automatically updates the package manifest (by retrieving the package by name). (TBD)

  • Page:
    Start New Task

    Automated Task Branching - Task branches and pull requests can be managed by running a build when development work begins, without special knowledge of Git. (TBD)

  • Page:
    Disposable Dev and Demo Environments

    Single-use development or demo instances are provisioned from source control, used briefly for a single task or feature, and then discarded. For Salesforce, environments may be provisioned from an Enterprise Edition Org with Sandboxes, a Scratch Org Dev Hub (beta), or a Trialforce Source Org (partners). (TBD)


Level 2 

  • 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 / Tests

    Validation includes both regression tests and feature acceptance tests, in automated and exploratory form. #TestLikeACustomerr (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:
    Security Scan

    Common security issues are checked as part of peer review or static analysis (TBD)

  • Page:
    OctoDocs

    Other shared components are documented with Octopus. (TBD)

  • Page:
    Flows for the Win! — (sf) Flows are available for use in managed packages and local extensions. (TBD)
  • Page:
    Clean Orgs

    (sf) DX Scratch Orgs are used, or spurious metadata is scrubbed from other development environments, so that the environment only contains components found in the target package. (TBD)

  • Page:
    Org Request Form

    Environment requests can be launched from the business org, or secure web site, without visiting external sites or servers. (TBD)

  • Page:
    CS Task Sandboxes

    (sf) For consultants, developer sandboxes are provisioned and populated with a scrubbed subset of the customer's production data, and a full sandbox is used to integrate changes for customer acceptance testing. (TBD)

  • Page:
    On-board/off-board

    The access new employees require is defined by role, and work instructions include removing access from business resources and development resources when an employee leaves. (TBD)

  • Page:
    BuildOps Maintenance

    The infrastructure used by the build pipeline is regularly maintained according to a set schedule and checklist, including pruning abandoned task branches. (TBD)

  • Page:
    Designated Workspace

    Using a template, a separate Confluence workspace is created for each customer implementation or major release series (such as Winter, Spring, Summer, for Salesforce) in order to aggregate the resources generated for each release and to avoid creating a future maintenance burden. (TBD)

  • Page:
    Agile Methodology

    Development work is managed using a well-defined Agile process, where progress on open items is visible on a shared Agile board, and the team continuously improves through blameless retrospectives. (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:
    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)

Please submit feedback to the DreamOps Success Group http://dreamops.org/group.