Pipeline

Created by Ted Husted
Last updated: Nov 21, 2016

What's all this now?

  • Out-of-the-box, a Salesforce packaging org provides all the tools that you need to develop and distribute a managed package. 
    • It is entirely possible to do everything you need to do in the packaging org. It's just a question whether you want to.
  • The purpose of the DreamOps Experience is to supplement the packaging process so that Force.com works equally well for larger teams with larger codebases. 
  • Many people start by developing directly in the packaging org, and then add version control, Trialforce, and other features slowly, as the package grows and matures. 
    • The role of this guide is to help teams accelerate the growth process by sharing practices that others have found effective.

The pipeline is presented in two forms, "Minimal" and "Optimal".

  • To remain effective, most enterprise teams should work to implement at least the Minimal form – or its equivalent.
  • Once the Minimal form is in place, you may wish to increase value by implementing the Optimal form over time. 
  • Depending on your situation, you may need only a subset of the pipeline items.


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. The DreamOps Experience extends the base components with other capabilities that all devops professionals should want in their toolbelt.


A typical devops pipeline

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.


DreamOps Delivery Cycle

To complete the Application Lifecycle Loop, the Monitor and Optimize and Plan and Measure stages (not shown) create new product backlog items as input to the Develop and Test and Deploy and Release stages.



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


Develop and Test

These stages form the core of development and testing capabilities. 


Create Change - Daily

One ideal development day per task. 



Task - Minimal / OptimalChecklistSetup
1

Developer requests environment

Drawing of a space shuttle with booster rockets.

A Developer can be a Coder, Admin, or any other team member.

Minimal

Optimal

  • Developer may select prior version as basis for trial (when creating a patch).
  • Developer can also begin this task using a ChatOps command in HipChat (@hubot build ABC-123), or directly from the build server.

(tick)

Develop Task Checklist

(In Progress)

(info) Setup

2

Build prepares environment

Drawing of several smaller workflows interacting with a larger panel.


Minimal

Build (via Signup Request and Proxy Signup)

  • updates trial instance to the latest commit to develop,
  • places managed code into an unmanaged package,
  • sets username and password using a shared convention,
  • alerts user that trial instance is ready.

Optimal

  • Data included in the template follows a mock customer implementation.
    • Mock customer dates are designed to pivot on the TSO org creation date.
  • Build also makes other changes specific to the package, to avoid manual setup.
  • Ideally, the build runs on a dynamic build agent, for scalability.




(info) Setup 
3

Developer completes task using environment

Photo of co-workers collaborating over a computer monitor.




Minimal

Coders or Admins make point-and-click or code-based changes.

  • For code-based changes, developer may also connect an IDE directly to trial org.
    • (No need to use local Git repository. Commits are automated.)

Developer adds any new components to the unmanaged version of the package, using the Salesforce UI.

Optimal

  • For tabs,
    • Developers create Help for this Page stub in help content site.
      • A Visualforce page routes HFTP request to help content page.
  • For global classes, Coders create
    • ApexDocs,
    • Regression tests to exercise new global methods from another package.
  • For new or modified Apex classes, triggers, or tests
  • For all new components,
    • Component access is provided by permission sets.
  • 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?


(info) Setup 

4

Developer submits environment for review.

Diagram of source code flowing through a pull request.



Minimal

  • Developer completes Change Log and/or Upgrade Steps fields in JIRA to describe modifications to package behavior or configuration.
  • Developer runs build to submit task environment for review.
    • Build retrieves or creates Git branch for task, retrieves unmanaged package over branch, submits commit, creates pull request from task branch to develop.
      • Commit includes updated package.xml created when package is retrieved.

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

Optimal

  • Build 
    • includes any sample data changes in the pull request.
    • launches ApexUnit tests in task org.
    • launches UI acceptance tests in task org using Selenium Nightwatch.
    • applies static analysis and dynamic analysis to the pull request.
  • Before moving task to Code Review, Developer reviews issues found by analysis and any failed tests, makes any needed changes, and re-submits.

(question) After the initial provisioning, how do we re-acquire the Session ID to run the build on dynamic agents? Set it in the org when it is provisioned, and have developer enter? Can a dev org build itself from a button, tab, or page?


(info) Setup 


Verify Change - Daily

One ideal development day or less per task



TaskChecklistSetup
1

Peer developer reviews pull request

Minimal

Peer reviewer approves pull request and submits task for embedded testing.

  • Reviewer checks that the
    • solution is fit for purpose and follows agreed conventions. 
    • Change Log and Upgrade Steps fields in JIRA cover modifications to behavior and configuration.

Optimal

(tick)

Develop Task Checklist
(Code Review)


2

Embedded tester explores solution

Minimal

Embedded Tester uses the task org to explore the completed work through the user interface.

  • Each task has its own org, freeing developers to start a new task.
  • Tester verifies that
    • Solution meets the definition of success.
    • Interface follows established conventions.
    • Invalid input is detected and handled.

Optimal

    • New tabs include a Help for this Page stub.

(tick)

Develop Task Checklist
(Ready to Test)
(Test Suite) 


3

Developer merges approved pull request

Minimal

When testing completes, and pull request is fully approved, Developer merges pull request.

  • Cleanup
    • Task branch is deleted on merge.
    • Task org expires within 90 days.




4

Build deploys changes to master environment

Drawing of a cloud filled with gears.

Minimal

Build deploys updated develop to source org.

Optimal

Build also updates a branch org (pilot) and a staging org (with sandboxes). 

  • (Winter 17) Build updates alternate packaging org and uploads new version.

Build updates

  • ApexDocs on develop help space. 
  • OctoDocs on develop help space (TBD).

(info) Setup 

5

Build launches automated test suites against updated master

Minimal

  • Build launches Apex unit tests in Trialforce source org using Ant Migration Toolkit.

Optimal

  • Build launches UI acceptance tests in branch org using Selenium Nightwatch.
  • Build uses ApexUnit to runs tests on branch org.
    • 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. 

(info) Setup 


Release and Deploy and Release

These tasks provide continuous delivery of a package to staging sandboxes and then to production orgs in an efficient, rigorous manner. 


Create and Verify Version - Per sprint task

One ideal development hour per sprint/version.



StepsChecklistSetup
1

Build deploys develop to packaging org on demand

Minimal

  • Developer creates a new Release Version issue in JIRA to track to packaging the new work increment. 
  • Developer 
    • creates temporary branch for version.
    • updates issues and change log with the new fix version. 
    • generates a change log based on tagged issues.
    • merges the temporary version branch into the packaging branch.
  • Build deploys updated branch to packaging org. 
    • Autoupdate is enabled so that all components under source control are added to the package. 
    • Package is automatically uploaded with Tooling API (Winter '17)

Optimal

  • Apex Tests can be run during deploy (synchronous mode) on request.
    • (Running tests synchronously can increase cycle time.)


(tick)

Upload Version Checklist

(info) Setup 

2

Build prepares new version

Drawing of a gift box tied with a ribbon.

Minimal

  • Developer performs any needed upgrade steps on packaging org, such as removing a deleted component.
  • Build 
    • runs ApexTests checkOnly before upload (in asynchronous mode).
    • queues package upload.

Optimal

  • Developer applies mock sample data updates.


3

Developer validates new version

Minimal

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

Optimal

Build installs new package versions to a series of internal orgs for verification.

  1. Regression sandbox – unmanaged package to exercise global API.
  2. Mock customer trial instance – local Apex tests, Selenium smoke tests.
  3. Mock customer Trialforce Source Org.
    • Developer
      • pushes mock data to TSO.
    • Developer
      • performs any needed upgrade steps on TSO.
      • creates Template but withholds pending further validation.

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


(info) Setup 

4

Script parses template notification

Optimal

  • (TBD) Trialforce template provisioning and deployment are automated.
  • Build (via Selenium) provisions template.
  • 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.


(info) Setup 


Validate Version Stage - Per sprint

One sprint or less per milestone version.



StepsChecklistSetup
1

Writers and Testers refine work increment


Minimal

Writers provision trials to compete help topics and tutorials, via Request Form.

  • For tabs, Writers flesh out Help for this Page stub.
  • Help topics are added or updated as needed by Writers.
  • Writer updates Delivered on the preview help site.

Testers provision trials for exploratory and user acceptance, via Request Form.

Optimal

  • Testers work from pre-defined acceptance test and customer-facing documentation.
    • Expectations are not set by developer-facing instructions or notes.
  • Testers automate acceptance tests for future sprints and extend a suite of smoke tests that do not change state.
  • Develop can request trials via ChatOps, the Request Form, or directly from the build server.

(tick)

/wiki/spaces/GUIDE/pages/3440831

(tick)

/wiki/spaces/GUIDE/pages/3440878



2

Writers and Testers enable net-new features

Optimal

Developer automates or streamlines mandatory metadata upgrade steps.

As needed, Writers and Testers flip configuration toggles that enable net-new features through custom settings, permission sets, and metadata changes.

If warranted by the change set, Testers may also provision sample-data developer sandboxes for selected customer orgs. 



3

Owner certifies version for release

Minimal

Gathering feedback from Coders, Writers, and Testers, Owner certifies version for release to customers, or deems it unsuitable for customer use.

When version is certified, Developer registers the Trialforce template for use with the Visualforce Request form.

Optimal

(TBD) When version is certified, Developer releases the Trialforce template, via ChatOps or directly from the build server.

    • ChatOps (HipChat), Visualforce form (business org), and build server (Bamboo) now return the newly certified version when a GA environment is requested.

(info) Setup 


Deploy Milestone Version - Per sprint



StepsChecklistSetup
1

Developer pushes milestone version to preview channel

Minimal

Developer announces staging and production releases for the preview channel.

  • Developer updates subscriber staging environments with preview version and invokes smoke tests.
  • Tester validates staging environments with regression tests and exploratory testing.
  • Developer updates production environments and invokes smoke tests.

Optimal

Developer uses push major upgrades to distribute milestone, with automated smoked tests.

(tick)

/wiki/spaces/GUIDE/pages/3440884

(info) Setup 

customer staging and schedules production release. 

Rollout Seasonal Release - Per season



StepsChecklistSetup
1

Developer pushes major version to GA channel

Minimal

  • When the Salesforce sandbox preview is announced, Developer inserts a set of tasks for each customer for the coming seasonal release. 
  • Developer uploads major version for seasonal release, incrementing major version to an even number.
    • The version is uploaded using an odd series first, and then a second time using the next even number.
    • Both TSOs are updated, so that the preview and GA channel are equivalent.
    • The GA patch org is created, so that the GA channel may proceed with patch versions only.
    • To cycle to the next preview version, upload a new version and assign the next odd major integer.
  • Developer follows the Deploy Milestone Version process, with the addition of regression and exploratory testing in customer staging orgs (or fresh developer sandboxes with sample data installed). 
  • Developer announces the new GA version.
  • When subscriber Group 1 rolls out, Writer updates the GA help site to match the preview help site.

Optimal

Developer manages Seasonal rollouts via a Salesforce app (TBD).

(tick)

/wiki/spaces/GUIDE/pages/3440829

(info) Setup 


Deploy Maintenance Version - As needed



StepsChecklistSetup
1

Developer applies maintenance update

Minimal

  • Developer
    • creates an issue in the JIRA Release Version project to create version. 
    • updates issues with the new fix version and generates change log.
    • merges pull request into the packaging branch.
    • deploys, uploads, and installs milestone version into the internal orgs, including the TSOs.
    • provisions trial template and configures request form.
  • Writer updates Delivered help topic to reflect the fix and deploys to the GA help site.

Optimal

  • Build deploys, uploads, and installs version into the internal orgs. 

(tick)

Maintenance Version Checklist

(info) Setup 


Launch Implementation - As needed



StepsChecklistSetup
1

Developer Launches implementation

Minimal

  • Developer requests Jumpstart trial with managed packages installed.
    • Exercises base setup steps in Jumpstart TSO, following checklist.
    • Deploys unmanaged add-ons into trial via build.
      • Build also deploys add-on sample data (TBD).
  • Developer converts customer data.
    • Identifies sample data set for initial import.
  • Build imports sample data to sandbox orgs.
  • Developer implements local extensions.

Optimal

  • Developer launches Configuration Wizard to setup org to customer likings.
    • Feature toggles.
    • Custom fields.
    • Custom record types.

(tick)

Implementation Checklist

(info) Setup 


Next Section: Roles.