Create new features, correct defects, and standup supporting infrastructure.

Functional Headings

Build Capabilities

Bootstrapping Infrastructure - Build
- Password Manager — All resource credentials are kept in a secure, shared repository, such as LastPass.
  - Setup Password Manager
- Email Alerts — All systems are enabled for email alerts, and all email alerts go to a shared chat room, forum, email account, or distribution list. For a distribution list, to provide transparency, the alerts should also be available in a chat room or forum. (TBD)
- Version Control System — All source materials used to create and distribute products or customizations are kept under some form of version control with a history of changes.
- Post-Launch Subscriber Configuration — (sf) To provide longterm support, subscriber metadata is kept under version control, so that post-launch changes can be reviewed. (TBD)
- Issue Tracker — All new work and modifications are made according to a request logged to a common system that assigns a unique identity to each item, such as an issue tracker or agile project management tool.
- Traceability — All changes can be traced from the Issue Tracker to the Version Control System, or from version control (Bitbucket) to the change request (Jira issue) to the original requirement (in Confluence). (TBD)
  - 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)
- Collaborative Platform — Requirements and changes are specified using a collaborative environment, such as Confluence, which is integrated with development tools, such as the JIRA issue tracker and Git version control system. (TBD)
- 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)
- 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)
- 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)
- Resource Checklists — To ensure consistency and quality, checklists walk through the initial setup of recurring resources, such as managed packages, Trialforce orgs, workspaces, requirements, and internal scripting tools, as well as onboarding and offboarding resource users. (TBD)
- 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)
- Shared Two-Factor Verification — For shared and standing development orgs, the verification text number is tied to a Google Voice number that posts to a chat room (such as HipChat or Slack), for shared access.
- Topic Branching — Within the Version Control System, topic branches are created from the default branch to represent individual change requests (Jira issues). The branches are short-lived and merged back into the default branch when the task is done. An alternative to Topic Branching ("Git Flow") is Trunk Based Development. (TBD)
- Resource Management — Key resources shared across packages or implementations (such as the ant-salesforce.jar or SFDX CLI) are maintained in a common managed location, and not in the individual source repositories. (TBD)
- Managed v Unmanaged — (sf) When to use an unmanaged or managed package is clearly defined by a decision tree or matrix. When to submit a package for security review is also supported by a decision tree. (TBD)
- Resource Naming Conventions — Common resources share a strong naming scheme, so that new resources with a similar scope are easy to locate, regardless of which team member creates the resource. This practice applies to version control repositories, named packages, shared usernames, development environments, and so forth. (TBD)
- Trunk Based Development — Within the Version Control System, new development is committed directly against the trunk, and checked in at least daily. An alternative to Trunk Based Development is Topic Branching. (TBD)
- Branching Model — A high performing development team selects a branching model that works well in their own environment. The two most popular models are Topic Branching and Trunk Based Development. Branching is a core practice. Each team member must understand the branching model being used, and should understand why the selected model is the best choice for their team. (TBD)
- Configuration Management System — All server operating systems and application software are setup and updated using automated configuration tools, such as Puppet, Chef, or AWS Cloud Formation. (TBD)
- Resource Runbook — Outline the lifecycle of each infrastructure resource, and any operational parameters, in a runbook or set of runbooks. (TBD)
- Equivalent Staging and Production Environments — To properly test ongoing changes to the work increment, we need a staging environment that matches the production environment as closely as possible.
- Continuous Integration Build Server — A build server integrates with other resources, such as the Version Control System, Configuration Management System, and other tools, in order to execute routine builds, launch automatic tests, and undertake other housekeeping tasks. (TBD)
- Deploy to Staging on Every Merge — On any change to the head of development, deploy the updated work increment to staging environment. (TBD)
Provisioning Environments
- 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)
- Build Request Form — Supplemental builds can be launched from the business org or secure web site, without visiting external sites or servers. (TBD)
- Mock Demos — Sales demos are based on a thoughtfully designed mock customer, complete with realistic mock data, designed to be used with trials. (TBD)
- MP Task Orgs — (sf) For managed packages, Trialforce is used to create new environments from on a secure Visualforce page, or DX is used at the command line by Platform Developers. (TBD)
- 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)
- Org Request Form — Environment requests can be launched from the business org, or secure web site, without visiting external sites or servers. (TBD)
- ChatOps — Environments can also be provisioned by querying a robot service in a chat room (Doggles in HipChat). (TBD)
- 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)
- Mock Orgs — For MPs, the development environment is based on the primary Sales Demo and includes realistic mock data bundled with the trial. For CSs, the development sandboxes include a subset of customer production data loaded with a build agent. (TBD)
- Mock Package — The core Sales Demo is handled as a package so that it can be redistributed to more than one environment type. (TBD)
- Role Orgs — MP staff and partners can provision different types of trials according to each person's role, with either source code or packages installed (development, testing, training, and/or sales use). (TBD)
- Cohort Orgs — MP environments are provisioned to represent different segments of its subscriber base, pre-configured with settings and data appropriate to each segment. (TBD)
- Development Environments on Demand — A working development environment can be automatically provisioned by developers, as needed, either through an online request form or ChatOps.
Working with Environments
- Demo Orgs Ready to Use — Sales demos and other trials also arrive pre-configured and ready to go, without routine manual steps. (SF orgs are configured by using Proxy Signup to modify the trials in-flight.) (TBD)
- Dev Orgs Ready to Use — MP development environments arrive ready-to-go. Developers sign-in-and-go without so much as setting a password. (TBD)
- 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)
- 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)
- Data to Go — Ready to Review includes changes to the mock sample data. (TBD)
- Ready to Use IDE Support — (sf) IDEs can be attached to development environments without cloning the Git repository to a local workstation. The native developer UIs can also be used to make changes to be placed under version control. (TBD)
Managing Change - Build
- 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)
- Report Examples — New reporting examples are included with new features, as appropriate, and distributed through Direct Deployment. (TBD)
- External ID Fields — (sf) External IDs are included with standard and custom objects to support capabilities like data conversion, sample data import, and staging refresh. (This item does not include implementing the capabilities, only the External ID fields.) (TBD)
- Proxy Base — For extension packages being developed alongside a base package, to support base API changes for the extension, the base is represented by a proxy package using a different namespace prefix so that the base can be updated incrementally during the development sprint. (TBD)
- Proxy Upload — (sf) For managed packages using Proxy Base, a new version is automatically uploaded and installed into an integration or development environment, after every change to the mainline or on a nightly basis. (TBD)
- Flows for the Win! — (sf) Flows are available for use in managed packages and local extensions. (TBD)
- Cache Partitions — (sf) Platform cache partitions are used in managed packages and local extensions where needed. (TBD)
- Customer Collaboration — Customers have access to an issue tracker and wiki (such as JIRA and Confluence) that can be used to collaborate between themselves and with the implementation team. (TBD)
- Unit Tests — As part of coding an item, include light-weight automated tests that exercise the internal interface for individual classes or components. A unit test provides a strict contract that the piece of code must satisfy. (TBD)
- Team Agile Board — A team agile board is a work and workflow visualization tool that optimizes the flow of work during an iteration. The board provides columns to represents phases of work, such as To Do, In Progress, and Done. Each work item is represented on the board as it moves across the columns. An agile board can be used with Scrum, Kanban, and other methodologies, and be physical or virtual. (TBD)
- Feature Agile Board — A feature agile board tracks the progress of a feature from inception to adoption. The board provides columns to represents phases of work, such as To Do, Plan, Build, Operate, Evaluate. Other agile board may track the progress of each feature with the top-level phases. (TBD)
- Continual Builds of Complete Test Versions — At least once a day, automatically build a complete release candidate, including dependencies, documentation, and automatic tests. Deploy build to a staging or test environment. (TBD)
- Short Running Tests — During code review both Apex unit test coverage and Apex unit test duration on new components is confirmed to be within expectations (less than five seconds per method). (See also ApexUnit https://github.com/forcedotcom/ApexUnit.) (TBD)
- Go/NoGo Milestone Checkpoints — At the close of each iteration, stakeholders jointly determine whether to proceed with the next milestone version. (TBD)
- 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)
- Static Analysis — Once a pull request is created, changes are verified through static analysis, including quality scans and security scans. (TBD)
  - Security Scan — Common security issues are checked as part of peer review or static analysis (TBD)
    - Quality Scan — Once a pull request is created, changes are verified through static analysis and by running the Apex unit tests. (TBD)
- Coding Style Guide — Document the set of conventions about how to write code for your project. It is much easier to understand a large codebase when all of its code is presented in a consistent style. (TBD)
Documenting Change
- Value Stream Map — A value stream is the series of activities used by an organization to deliver a product or service to an external or internal customer. A value stream map breaks down the process time for each activity, the lead time between activities, and the success rate. The map is depicted as a flow chart annotated with key metrics. Key metrics are lead time, process time, activity ratio, rolled % complete & accurate. Often a current state map is used to derive a future state map with process improvements.
- API Documentation — Describe what services your application programming interface offers and how other people can use those services. (TBD)
- Evergreen Help Site — The Preview and GA help sites are updated within each sprint to cover new tasks, topics, and references meaningful to end-users. (TBD)
- Developer Design Documents — Document key aspects of the application design for the benefit of other developers, and your future self. (TBD)
- OctoDocs — Other shared components are documented with Octopus https://appexchange.salesforce.com/listingDetail?listingId=a0N3000000B5cEKEAZ. (TBD)
- Technical Change Log — Itemize each work item merged into a given work increment, and provide a standard description of the change. (TBD)
  - New Components — Once the new increment is deployed, update the change log to list any new components (classes, fields, and so forth) being added to the version, by using a Javascript macro to scrape the package details 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.)
    - Setup Change Log
    - Change Log Fields — In the JIRA issue, fields are available for developers to summarize the actual change being made, and to indicate the need for any Upgrade Steps or Feature Toggles. (These fields are included in the change log generated for each version.) (TBD)
- Troubleshooting Articles — Capture how unusual and everyday problems were solved, in case the issue reoccurs. (TBD)
- ApexDocs — Global classes are documented with ApexDocs and available through the help site. (TBD)
- Help Site — Help topics are provided for all subscriber-facing capabilities. (TBD)
- Context Help — Help for this Page is extended for new tabs, updated as needed, and linked to Help Site. (TBD)
Integrating Change - Build
- 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)
- CheckOnly After Merge — (sf) On merge to develop, the updated develop branch is validated (checkOnly) with the packaging org or production branch. (TBD)
- You Break It — Failed builds are raised up in email alerts for handling by the developer responsible for the last change. (TBD)