Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


titleunder construction
- We are what we repeatedly do – The platform has all the components we need to build an efficient deployment pipeline and support continuous delivery of enterprise-grade managed packages. The goal of continuous delivery is to increase customer satisfaction by being able to distribute an updated release at any time.


A similar pipeline

DreamOps Pipeline Stages

Table of Contents


This page provides a top-level overview of the DreamOps process. See Roles for more about the steps taken by individual team members.



Each stage in a pipeline is a unit of work. A stage's work must be fully complete before the result flows to the next stage. Given sufficient resources, stages can operate in parallel. Ideally, the stages and resources are balanced so that work moves through the pipeline at a steady, consistent rate.




Develop and Test Stage


Create Change (Commit and Analyze)


Developer begins task via Visualforce Request form, from build server, or a ChatOps command in HipChat (@hubot build ABC-123).

A developer can be a coder, admin, or any other team member.


Alternative: We could provision the task orgs in advance, and then refresh the task branch/org
with the latest develop. In that case, we should also identify which JIRA Issues need dev orgs
(or we could just do them all).

Develop Task Checklist
  • JIRA
    • Seasonal Project
      • Component==Package
  • Confluence
    • Checklist Template
    • Seasonal Space
  • EnvHub
  • Visualforce Request form
    • Apex web service for remote submit
  • Bamboo
    • Build plan to invoke request form
  • HipChat
    • Hubert
      • Script to invoke form




Background Task -

Build creates task branch from develop (trunk), and queues task org (trial instance).

  • Bitbucket
  • TSO
  • Signup API

Background Task -

 Callback function is exercised when org is ready.

    • Sets password and makes other configuration.
    • Alerts developer that org is ready for login.
  • Proxy Signup
    • Proxy script to setup org
  • Build plan to orchestrate task org setup
  • Core Package
  • Core Data / Mock Customer
  • Opt Packages
      • Push Package Install
  • Data Loader
    • DL Config Script
  • Opt Data



Background Task -

 Task org arrives ready-to-go with password and other settings configured.

  • Transaction dates in org are current.
  • Data is current to recently developed capabilities. 
  • Optional packages and data pre-installed.
  • Irrelevant metadata is removed.

(Optional) Task org and branch are pre-synced and Illuminated Cloud IDE setup is included in branch.


IC Script (theoretical)


Admin makes point-and-click changes, or coder develops task, including ApexDocs for globals.

As needed, Coder or Admin includes help text descriptions and sample data, as provided by task description.

(question) How do we inject external IDs without fuss and bother? Toggle trigger to populate on save? What's the toggle failsafe? Screen alert?

  • IC Installed Locally
  • ExtID mode trigger


7As needed, developer runs supplemental builds via ChatOps or build server.
  • Deploy branch to org

  • Add'l Builds
  • Developer commits to task branch as desired, cross referencing task ID in commit messages.
  • Developer updates package.xml with new components.
  • Component access is provided by permission sets.
  • Administrator (TBD) ...

Develop runs build to analyze branch with SonarQube, and resolves issues found in report.

Developer moves task to code review column, and signs up for another task, by working the board right to left.

  • SonarQube
    • BB Plugin
  • SQ scan package
  • SQ scan pull request
10Developer creates pull request.
  • Developer also creates pull request for any mock data changes. 
  • Mock data in repository


Verify Change (Peer Review and Embedded Testing)


Peer reviewer approves PR, and submits for embedded testing.

Validate Task Checklist 

Embedded tester uses the task org to explore the task.

  • Each task has its own org, freeing developers to start a new task.
3When testing completes, and pull request is fully approved, peer reviewer merges pull request.
  • Task org expires within 90 days.
  • Task branch is deleted on merge.

Build deploys develop to source org, staging org, and branch org. 

Build updates ApexDocs on develop help site. 

(TBD) Build updates OctoDocs on develop help site.

(Automated Tasks)
  • CI build plan
  • Help web site
  • ApexDocs
  • ApexDocs build plan

ApexUnit runs tests on branch org and posts report to web server.

Apex Tests run in parallel mode, and failed test are resubmitted.

 Build greps ApexUnit report and posts to DevOps chat room if report fails quality gate. 

  • ApexUnit
  • ApexUnit Runner
  • grep script
  • HipChat Room


Create and Verify Version


New components added to the package manifest add themselves to the package.

New package versions are uploaded and pushed to a series of internal orgs for verification.

If deployment or tests fail for one internal org, the remaining orgs are not updated. 

Upload Version Checklist
  • Release Coord board in JIRA
  • Confluence Change Log template
  • Build plan to deploy to package branch
  • Chrome bookmark to show what components are added
  • Point and click by Org ID
    • Select with Selenium script
  • Or, build plan to install version via API
    • Store credentials in secure fields
 Each internal org exercises its own set of automated tests.
  • Upgrade sandbox (firewall) – API regression tests
  • Mock Customer sandbox– local Apex tests, Selenium smoke tests
  • TSO ...
  • Upgrade test org
  • GA TSO
    • Data transfer build plan
 When each internal upgrades succeeds
  • Updated mock data is pushed to internal orgs
  • Mock data transfer build plan

A new Trialforce template is provisioned, and email alerts sent when template is ready to use.

 Email is processed as inbound message, and parsed. New template ID is captured in an object and made available to ChatOps and Visualforce Request form. IDs from GA TSO are captured but held. 
  • Inbound Message Handler
    • Message parser
  • Visualforce Request form - Hold ID



Validate Version (User Acceptance Testing)



Technical writers provision trials to compete help topics and tutorials, via HipChat or Visualforce Request form.

QA testers provision trials for exploratory, user acceptance testing, and automated smoke testing, via HipChat or Visualforce Request Form.




Net-new features are enabled with configuration toggles.

If warranted by the change set, QA testers may also provision partial-data developer sandboxes for selected customer orgs. 

  • Custom Metadata
  • Apex Web Service
3 When version is certified, the Trialforce template is released via a Doggles or a Visuaforce admin form.
    • HipChat and Trialforce Request form (NU org) return the newly certified version.


/wiki/spaces/GUIDE/pages/3440878Visualforce Request form - Release ID


Release and Deploy Stage


Deploy Version (Production)

1The new version can be released to individual customer orgs or to all customers in a group. /wiki/spaces/GUIDE/pages/3440884 

Access to new components is granted by permission set changes.

Manual upgrade steps are automated or streamlined.


LMA updates version reference, which presents on the Org Details object in the NimbleUser org. 

 Org Details object in business org



 Confluence template





Deploy Milestone Version


Milestone version

  • A RC issue is created to release a new work increment. 
  • The issues and change log are updated with the new fix version. 
  • The tip of develop is merged into into the release branch, deployed, uploaded, and installed into the internal orgs. 
  • Preview help site is updated to reflect product changes.
  • The work increment is validated by QA testing. 
  • If certified, staging and production releases are scheduled for the preview channel, and then installed. 


Rollout Seasonal Version


Seasonal rollouts are managed via a Salesforce app.

  • Application settings are reviewed and updated.
  • When the sandbox preview is announced, a set of tasks for each customer are inserted for the coming seasonal release. 
  • The milestone release process is followed, with the addition of exploratory testing in customer staging orgs. 
  • The new GA release is scheduled for all customers, and the preview channel is reset. 
  • When group 1 rolls out, the GA help site is updated to match the preview help site.


Deploy Emergency Version


Emergency release

    • A RC issue is created to release a resolved blocker. 
    • The issue and change log are updated with the new fix version. 
    • The commit is merged into the patch branch, deployed, uploaded, and installed into the internal orgs. 
    • The fix is validated in customer staging, a production release is scheduled, and then deployed using a push upgrade. 
    • Delivered is updated to reflect the fix and deployed to the GA help site.


Bootstrap Implementation


Bootstrap Implementation

  • Request jumpstart trial with managed packages installed.
    • Base setup steps are exercised in TSO.
    • Select unmanaged packages to install into trial.
      • Data is also deployed.
  • Exercise (minimal) checklist steps.
  • Launch survey wizard to configure org to customer likings.
    • Feature toggles.
    • Custom fields.
    • Membership types.
    • (TBD)
  • Convert customer data.
    • Identify partial data set for initial import.
  • Implement customizations.
    • Developers import partial data to sandbox orgs.


Monitor and Optimize Stage


Observe Changes

1In production, errors and failed expectations are logged for review in Loggly, and usage metrics are tracked. 
  • Apex Error emails are caught by inbound mail and pushed to Loggly.
  • Events are also logged to customer's Papertrail account. 
    • Papertrail alerts are sent to customers based on pattern matching.
Monitor Production Checklist 

All repetitive tasks are documented with work instructions.

Changes to customer metadata are tracked with version control, in a single branch.


At intervals, ApexUnit reports on customer production orgs and posts to HipChat and Loggly if any fail our quality gate. 



Plan and Measure Stage


Specify Next Change

1Groom backlogSpecify Story ChecklistConfluence Templates
  • Research the technical approach
  • Conduct feasibility assessments for new features 
  • Develop functional requirements
  • Refine the User experience - as needed
  • Refine the definition of done - as needed
  • Determine the level of effort required (story points) - high, refined, and final
  • Test the outcomes
    • Agree on scope revision
  • Concept - All PO
  • Research - All PO
  • Internal feedback - All PO
  • External feedback - All PO
  • Detail requirements - All PO
  • Confirmation - PO and PD
  • Development - PO and PD
  • Done - PO and PD
3 Determine customer benefit  


  • Concept
    • Review
    • Initial Research
    • Prioritization
  • Research
    • Scope Definition
    • Internal Feedback
    • External Feedback
    • Development Feedback
  • Design
    • Definition of Success
    • Refinement
    • Confirmation


  • Done
    • Incremental
    • Seasonal
  • Review
    • Metrics
    • Feedback