Salesforce Environment Management

Due to the complex nature of overlap and conflict between items of development within a typical Salesforce implementation, there are significant challenges with managing version control of deployed components. The purpose of this document is to outline our agreed strategy for management of sandbox instances and our deployment cycle from development, through client testing and finally, production releases.

Project and Journey Development Process

Some basic rules relating to new development items;

1. New development requires the explicit engagement of the client (through their nominated representative, IT Team (or similar)

   1. For project related work, this approval can be obtained through a formally approved project proposal or signed statement of work

   2. For Journey or support development, a request can be made via a Jira ticket on the appropriate board

   3. For development of new features or enhancement of existing features, an estimate is recorded against the ticket before the client indicates they would like to proceed

   4. For bug or defect resolution, these are prioritised and if covered by warranty period or agreement, are non-billable (refer to SLA)

2. Monthly Journey development cycle

   1. Journey development is conducted across a monthly recurring planning, development, testing, release cycle

   2. A planning meeting is conducted to review development items, discuss requirements and schedule the appropriate scale of development for the upcoming month

   3. This is followed by a development sprint and a release to the nominated testing environment for the client to perform their UAT

   4. Following any necessary reworking, if approval is granted, we then deploy the relevant components to Production on the agreed upon monthly release day

3. Project development according to the approved project proposal/SoW

   1. Project development scheduling is governed by the development sprint and release timeline agreed with to with the client

   2. Sprint structure includes provision for requirements gathering, development, showcases and demos, testing and feedback, reworking and production releases

4. Conflict or overlap between project development and journey development items

   1. Any potential conflict between development streams for a single client are managed through the use of separate development instances

   2. Separate development streams are generally merged into a singe UAT environment for testing prior to production release

   3. In cases where separate development streams contain updates to a shared component, separate test environments and releases may be required

Instance Management

To help separate individual project development streams (that can occur over significant periods of time) from ongoing journey and support development, new development sandboxes are spun up (or refreshed from existing DEV sandboxes that are no longer in use) on a needs basis.

As a general rule, we aim to keep our sandbox and UAT environments as closely aligned with the Production environment as feasibly possible. For this reason, we have a structured process in place for the management, creation, refresh and destruction of these environments, across the lifecycle of a project or support engagement;

• Standard PDEV sandbox naming convention is used for each project development stream (we may defer to a client’s preference for sandbox naming convention)

• JDEV named sandboxes for ongoing Journey development

• PDEV sandboxes are to be refreshed or destroyed at the conclusion of the final production release

• JDEV sandboxes to be refreshed every two months (or monthly if all in-progress development items are released

• UATPC (Partial Copy) sandbox for QA and internal testing

• UATFC (Full Copy) sandbox for client UAT and QA testing

• UATPC and UATFC refresh or desctruction can be scheduled only when agreed by Vertic and the client

Partial and Full Copy Sandboxes - Sensitive Data Management

Both Partial and Full Copy sandbox environments are cloned copies of the production instance that include either a limited (partial) or complete (full copy) copy of the data from the production environment. When creating or refreshing these environments we take several steps to invalidate sensitive data. By default we invalidate Contact email addresses (to ensure no emails are sent to real contacts) and payment token IDs (where relevant instance includes a payment gateway integration) to ensure no payments can be processed in error.

Deployment Management and Jira Workflows

The below diagram details the typical deployment cycle across environments;

Open

Our Jira ticket lifecycle and process flows reflect the depicted workflow. Both project and Journey/support tickets are managed using the Vertic Jira workflow process steps;

1. Backlog (not yet approved for development)

2. Selected for Development (approved for development)

3. In Progress (currently assigned to a developer and under development)

   1. Failed Testing (reverted from either the internal testing or client testing resource with feedback)

4. Vertic Review (assigned to project lead or senior developer for internal QA testing and review)

5. Client Review (ready for testing/review by relevant client team member)

6. Client Approved (fully tested and approved for release to production environment by the client)

7. Done (successfully deployed/released to production environment)

Issue Type Management

Jira items can be categorised into various issue types for ease of reporting, filtering, assignment and management of workflows. The issue types included in our Jira workflows are defined below;

• Epics major development streams that can encompass various components and elements and can be shared across projects and boards

  • Can contain many stories, tasks and sub-tasks

• Bugs are errors, faults or defects in components where expected behaviour is not observed

  • This issue type is automatically moved to the Selected for Development status and prioritised (according to SLA)

• Stories issue types are most often utilised for user stories provided by clients or gleaned from requirements gathering workshops

  • Used to document requirements or requests from clients

  • Can contain many tasks and sub-tasks

  • Not usually assigned to developers directly

• Tasks and sub-tasks used for technical definitions of development work, usually created, written and managed by the consultancy and technical teams

  • Usually contain technical specifications translated from requirements

  • Used for development resource planning and estimates

Production Deployment Scheduling

Scheduling for deployments into the client’s live production environment will be dependant on whether it is project-related development or Journey development.

• Project go live or production deployments are to be determined by the agreed project timelines and subject to approval by both the client’s IT/project team and/or the Project Manager or Sponsor

• All Client Journey development tickets with a “Client Approved” status will be deployed on the agreed monthly deployment date

• Critical bug fixes, warranty items or other agreed-upon urgent items will be deployed on an adhoc basis, dependant on severity and impact (defined further in the SLA)

• Deployed tickets to include a link to the relevant Changeset or the ClicksetId