Service Delivery Team Onboarding and Service Delivery Guide

Version 1.1

Version control table

Version	Date	Comments
0.1	20/10/2022	Initial Draft
1.0	22/11/2022	Published Document
1.1	12/09/2023	Amendments – Updated Introduction – Updated Onboarding Stage – Updated Development Process – Updated Going Live – Added Service fixes and iterations – Added README file link – Added CHANGELOG file link

Table of contents

Introduction

The purpose of this guide is to explain all the necessary actions that need to be taken and prerequisites that have to be met by a service delivery team to collaborate, develop and deploy a new service or a ‘bucket’ of services on the DSF infrastructure (currently an Azure AKS Cluster) using the DSF Service Standard and DSF Design System along with the actions to be taken concerning service fixes and iterations. A Service Delivery Team could be either an internal team (within the Government of Cyprus) or an external vendor (A private company collaborating with a Government Ministry/Department bound by a Framework Agreement for the Digital Transformation of Government Services or by any other type of a government contract. The process of onboarding a service delivery team in order to successfully deliver a service or a ‘bucket’ of services is described in detail in the sections that follow.

The process of delivering a Service, in this document, is read as the “project”.

Project Initiation Process

Onboarding Stage

Prior to the implementation of the service, the Project Manager of the Contracting Authority shall fill in a Service Delivery Initiation Form for each service/iteration to be delivered. This form contains service basic technical information along with the targeted outcome (outcome-based approach).

All communication between the DSF Tech Team and the Service Team shall be initiated exclusively by a Governmental Technical Officer (Solution Integration Officer) and the technical DSF team. In the event of the absence of a Technical Officer, the role shall be assumed by the Project Manager. The email account dsf-tech@dits.dmrid.gov.cy will serve as the designated point of contact for the Tech Support Model.

The onboarding stage shall be initiated by a meeting of all stakeholders. If needed, other meetings can follow to communicate the goals of the project and identify the service’s boundaries by all parties involved.

Initiation Stage

Following the onboarding stage described above, the Service Architecture Document shall be submitted by the Project Manager of the Contracting Authority to be reviewed by the Digital Services Factory (DSF) Team. A formal response by DSF shall be communicated back to all involved parties with an initial draft of a Service Delivery Roadmap.

A kick-off meeting between the DSF Team and the Service Delivery Team shall be arranged by the Project Manager of the Contracting Authority, to officially initiate the project. Any issues, problems and clarifications will be discussed to bring all involved parties aligned with the goals. An agile project management approach shall be used with sprint goals defined. Members from both teams, the DSF Team and Service Delivery Team shall participate as needed in agreed meetings to resolve possible issues.

Service Workflow Process

The service shall undergo the following workflow process as per the Service Standard; Service Design, User Research, Content Design etc.

Using the DSF Infrastructure

Development Process

All development and deployment processes shall be done using the DSF Infrastructure.

Diagram 1.1

The source code of the service must be uploaded along with the relevant documentation (README file) and will be maintained on a per-project pre-specified DSF Github Source Repository. Access shall be granted to the Service Delivery Team’s member(s) upon request.

Prerequisites: At least a paid GitHub account (Team or Enterprise with 2-factor authentication enabled) on the service delivery team’s end is necessary.

CI/CD Pipeline

A per-service DSF CI/CD pipeline shall be configured and run to test, build and store the service container image in the DSF’s Github Container Registry (ghcr.io, see Diagram 1.1). It is the responsibility of the Service Delivery Team to have a successful build of the project as a container image using a Docker file in the root folder of the repository.

The service shall be deployed on the DSF’s Azure Kubernetes Service (AKS) cluster, initially on the DSF’s Infrastructure Staging Environment, using a configuration script (number of pods, # of vCpu, RAM etc., performance and CPU intensity info shall be needed to be provided from the service team’s part to size the pods appropriately).

Later, during the testing process (see. the Testing Process section in this document), a performance and analytics tool shall be used to better assist with the final sizing of the service pods (A “Pod” is a service instance that runs on the AKS cluster; A service can have more than one pod running for high availability and performance).

Authentication Requirements

If Citizen/User authentication is required by the service, authentication requirements shall ONLY be fulfilled through the CyLogin Open ID Connect authentication service using the CyLogin access token to access the required data.

Notification (SMS & Email) Requirements

If citizen notification (either by email or by SMS) is required by the service, Notification requirements shall ONLY be fulfilled through CyNotification Engine. To use the Notification Service, a “Notification Client Account” (provided by the CyLogin Team) is required for each deployment environment (Production and Development).

Payment Requirements

Citizen payment requirements shall ONLY be fulfilled through “CyPayment Engine”. To use the Payment Engine, a “Payment Client Account” (provided by the CyLogin Team) is required for each deployment environment (Production and Development).

Data Access and Storage Requirements

Any data access or data storage requirement shall be handled by the service delivery team’s end, using or developing a backend API (shall be developed by the Service Delivery Team or by the Backend’s Support Team based on the requirements scoped for the service) and shall be exposed to DITS API Gateway (CyLogin Team) for the service to have access to. The DSF API Standard must be followed when developing the service API.

Diagram 1.2

Domain Name Registration Process

A service name shall be provided to the DSF tech team to register the Domain Name of the service. All DSF-hosted services shall have qualified names under these two domains:

<service_name>.service.gov.cy for the production, ie.do-a-thing.service.gov.cy and
<service_name>.staging.service.gov.cy for the staging environment, ie. do-a-thing.staging.service.gov.cy

For naming the service and naming the service’s end-point URLs please refer to the “Service name and URLs” section of the ‘Content Design Standards for Services.

Testing Process

Testing shall be conducted by the Service Delivery Team as needed on the DSF’s Staging Environment (DSF-SE). It is the service team’s responsibility to conduct all necessary tests including UAT (User Acceptance Test), unit tests, performance and load/stress testing. A WASA (Web Application Security Assessment) should also be conducted before the service is sent to DSF for Quality Assurance assessment. The WASA must be executed by an independently certified penetration (PEN) tester with at least 3 years of experience in PEN testing. The PEN Testing results report shall be disclosed along with the Data Protection Impact Assessment (DPIA) report to the Personal Data Protection Commissioner.

When all the necessary tests are performed successfully, the service shall be available for the quality assurance assessment.

Assurance Process

The service shall undergo the DSF assurance process to obtain the “Comply” or “Meet” result in order to proceed with the deployment process.

Deployment Process

The deployment of the service to the DSF Production environment is done by the DSF Tech Team. The DSF Tech team shall be informed, by the service delivery team within a reasonable period of time prior to deployment of the service, on the date and time the service should be published.

Going Live

It is recommended when the service goes into production, a ‘controlled release’, usually a week’s duration, is introduced. The ‘controlled release’ precedes the full ‘going live’ phase and it is a non-advertised production use of the service by a pre-selected group of users/citizens that are eligible to use it in order to test the whole end-to-end process in the actual production environment. All citizen’s applications/requests during this phase shall be officially processed and all the outcomes shall be considered valid. After an assessment of all outcomes of the “controlled release” by the service team, the service shall be advertised and published on the “gov.cy” portal for full public access.

Project Closure

Project closure is reached when all project requirements are met including receiving the final “Service Standard Verified” seal.

Service fixes and iterations

Any service fixes/iterations performed by the service team shall be communicated to the DSF Team by the Project Manager of the Contracting Authority.

The Project Manager of the Contracting Authority shall request a redeployment of the updated service by providing adequate documentation with reference to the Assessment Report Number of the service and describing all new service fixes/iterations performed on the service (an updated service CHANGELOG file shall also be included in the request). Upon reviewing the request, the DSF Assurance team shall respond with a direct order for re-deployment or with a request for a new service assessment. In the case of the latter, the order for re-deployment shall be given based on the assurance result.

After acceptance from the Contracting Authority of any service fixes/iterations issued by the service team, they shall be communicated to the DSF Team (dsf-qa@dits.dmrid.gov.cy) via the Project Manager of the Contracting Authority.

The Project Manager of the Contracting Authority must send the files, including a CHANGELOG file for documentation on the bugs/fixes/the iterations, to the DSF Assurance Team. The DSF Team will handle each request accordingly and decide whether a new assessment is required before deploying the fixes/iterations of the service. The deployment procedure is as described in the Deployment Process above.