UNDER CONSTRUCTION - We are what we repeatedly do – The Force.com 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.
DreamOps Pipeline Stages
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
|Develop Task Checklist|
Background Task -
Build creates task branch from develop (trunk), and queues task org (trial instance).
Background Task -
Callback function is exercised when org is ready.
Background Task -
Task org arrives ready-to-go with password and other settings configured.
(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.
How do we inject external IDs without fuss and bother? Toggle trigger to populate on save? What's the toggle failsafe? Screen alert?
|7||As needed, developer runs supplemental builds via ChatOps or build server.||"|
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.
|10||Developer creates pull request.||"|
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.
|3||When testing completes, and pull request is fully approved, peer reviewer merges pull request.||"|
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.
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.
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|
|Each internal org exercises its own set of automated tests.||"|
|When each internal upgrades succeeds||"|
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.|
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.
|3||When version is certified, the Trialforce template is released via a Doggles or a Visuaforce admin form.|
|/wiki/spaces/GUIDE/pages/3440878||Visualforce Request form - Release ID|
Release and Deploy Stage
Deploy Version (Production)
|1||The 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|
Deploy Milestone Version
Rollout Seasonal Version
Deploy Emergency Version
Monitor and Optimize Stage
Plan and Measure Stage