| Excerpt | ||||||||
|---|---|---|---|---|---|---|---|---|
|
DreamOps Pipeline Stages
| Table of Contents |
|---|
| Tip |
|---|
This page provides a top-level overview of the DreamOps process. See Roles for more about the steps taken by individual team members. |
| Info |
|---|
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).
- JIRA
- Seasonal Project
- Component==Package
- Seasonal Project
- 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
- Hubert
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.
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
- 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
- Developer also creates pull request for any mock data changes.
- Mock data in repository
Verify Change (Peer Review and Embedded Testing)
| Task | Checklist | Setup | ||
|---|---|---|---|---|
| 1 |  | Peer reviewer approves PR, and submits for embedded testing. | Validate Task Checklist | |
| 2 |  | 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.
| " | |
| 4 | 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) |
| |
| 5 |  | 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.
- 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
- 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
- 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.
- Message parser
Validate Version (User Acceptance Testing)
| Steps | Checklist | Setup | ||
|---|---|---|---|---|
| 1 |
| 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. | ||
| 2 | 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)
| Steps | Checklist | Setup | ||
|---|---|---|---|---|
| 1 |  | The new version can be released to individual customer orgs or to all customers in a group. | /wiki/spaces/GUIDE/pages/3440884 | |
| 2 | Access to new components is granted by permission set changes. Manual upgrade steps are automated or streamlined. | |||
| 3 | LMA updates version reference, which presents on the Org Details object in the NimbleUser org. | Org Details object in business org | ||
| 4 | ||||
| 5 |
| Confluence template | ||
| 6 |
| |||
| 7 |
|
Deploy Milestone Version
Rollout Seasonal Version
Deploy Emergency Version
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
| Steps | Checklist | Setup | ||
|---|---|---|---|---|
| 1 | | In production, errors and failed expectations are logged for review in Loggly, and usage metrics are tracked.
| Monitor Production Checklist | |
| 2 | All repetitive tasks are documented with work instructions. Changes to customer metadata are tracked with version control, in a single branch. | |||
| 3 | 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
| Steps | Checklist | Setup | ||
|---|---|---|---|---|
| 1 | | Groom backlog | Specify Story Checklist | Confluence Templates |
| 2 |
| |||
| ||||
| 3 | Determine customer benefit | |||
Learn
Measure
|