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, 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.
Project and Journey Development
Some basic rules relating to new development items;
No new development can be undertaken without the explicit engagement of AVI IT Team
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)
Bug fixes to be actioned and deployed according to support agreement (refer to SLA)
Project development to be managed and scheduled according to project SOW
Any 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).
Both journey and project development streams to be managed via separate Jira boards linked to the parent AVI Confluence space.
Instance Management
To help separate project development streams (that can occur over significant periods of time) from an ongoing journey and support development, new DEV sandboxes will be spun up (or refreshed from existing DEV sandboxes that are no longer in use).
Separate PDEV sandbox for each project development stream
Alternating JDEV sandboxes for ongoing Journey development
JDEV sandboxes to be refreshed every two months (or monthly if all in-progress development items are deployed
UATPC (Partial Copy) Sandbox for QA and internal testing
UATPC refresh can be scheduled when agreed by Vertic and AVI
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
Deployment Management
The below diagram details the deployment cycle across environments;
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.
Both project and client journey will be managed using the Vertic Jira workflow process steps;
Backlog (not yet approved for development)
Selected for Development (approved for development)
In Progress (currently assigned to a developer and under development)
Vertic Review (assigned to project lead fo internal QA testing and review)
Client Review (ready for testing/review by relevant AVI team member)
Deployed (successfully deployed 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
Jira tickets also contain attributes to track the environment that the piece of development 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:
An estimate for the effort has been provided by Vertic and that has been approved by AVI via a comment; or
The ticket has been discussed and approved for Development in a Journey Planning Meeting; or
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.
AVI has acknowledged that a detailed breakdown of an estimate (in excess of 30+ mins) is considered billable time.
Production Deployment Scheduling
Scheduling for deployments into the AVI 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 IT Team and the Project Manager
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
Deployed tickets to include a link to the relevant Changeset or the Clickset ID
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.