Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Our scope of work for AVI includes multiple project streams as well as ongoing support items. 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 AVI the client (through their nominated representative, IT Team

  2. Monthly Journey 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 (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)

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

  5. Any conflict 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

  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 to be discussed by Vertic and AVI before proceeding New Components when created, are to always be added to the AVI - Lightning Components (for both Journey & Project Work).

    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

Info

Both journey and individual project development streams to be are managed via separate Jira boards linked to the parent AVI client Confluence space.

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 AVI

Info

Project or PDEV sandboxes will be created or refreshed before the commencement of any new project development as required, Journey or JDEV sandboxes to be refreshed every two months

...

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

Info

Additional field or object data can be excluded, encrypted, invalidated or deleted at the request of the client.

Deployment Management and Jira Workflows

The below diagram details the typical deployment cycle across environments;

Info

We will solely use the UATPC (Partial) Environment for QA/UAT Testing.

The idea being upon a regular monthly refresh which is in-line with the amendment to the deployment structure (2nd Tuesday of each month), we will utilise the ‘Reference Data’ sandbox template and AVI IT will create test records for users when a development piece becomes available.

...

...

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

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

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

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

Project or PDEV sandboxes will be created or refreshed before the commencement of any new project development as required, Journey or JDEV sandboxes to be refreshed every two months

 

Info

Jira tickets also contain attributes to track an environment attribute for tracking the environment that the piece of development have progressed to and can be tested in and time spent (for Journey tickets)

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

    • Simple estimates are provided here, which can then be broken down further on request.

...

/reviewed in.

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 AVI 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 AVI 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 Clickset ID

...

  • ClicksetId

Info

Any Changeset or Clicksets being deployed to the Production environment should include field/object level visibility and security settings, but NO profile administrative settings or permissions (unless specifically required).