Content Comparison

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 production 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. No new development can be undertaken without 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

   cycle - items selected for development at the monthly scheduling meeting to be deployed to production within that cycle (UAT completion and monthly journey hours permitting)

3. Bug fixes to be actioned and deployed according to support agreement (refer to SLA)

4. Project development to be managed and scheduled according to project SOW

5. Any conflict

   1. , 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

6. 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

7. 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

   be discussed by Vertic and AVI before proceeding 

   1. production release

   2. 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 an ongoing journey and support development, new DEV development sandboxes will be 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 Alternating JDEV (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 deployedreleased

• UATPC (Partial Copy) Sandbox 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;

...

...

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 of or senior developer for internal QA testing and review)

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

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

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

...

Ticket Approval Process - Journey

To help facilitate a smoother development process for Journey Tickets, Vertic & AVI have discussed and created the following guidelines surrounding Ticket Progression for the Journey Board. It is important that this process is followed in order to mitigate any clashes that the IT Team has with other business units in its organisation.

Typical Rules of the Development Cycle

Tickets created in the Backlog should not be moved into Selected for Development until:

1. An estimate for the effort has been provided by Vertic and that has been approved by the client via a comment; or

2. The ticket has been discussed and approved for Development in a Journey Planning Meeting; or

3. AVI requires an urgent piece of development and are still within their development cycle.

Issue Type Management

...

Bugs are errors, flaws or faults in development which produces SF to act in an unintended way.

• should automatically be moved into Selected for Development.

...

Stories are requests for larger work which are then divided into subtasks.

• as these are larger tickets, each subtask is required to be given an estimate for that particular ticket.

• These issue types require greater information surrounding estimates compared to Tasks when work is in excess of 2.5hours.

Tasks are used for single updates

...

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

...

• 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 Team /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 ASAP basis 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