Demo Environment Set up and Upgrade Process

Objective

This document aims at defining the process to be followed for the set-up and management of the demo environment. For the Urban mission, a demo instance is already in place and this has to be upgraded after every major release of DIGIT.

Key stakeholders

DIGIT demo instance is targeted to be used by the following people-

1. eGov team

2. Implementation partners

3. Ecosystem partners

4. Other people accessing the digit website, who are interested in DIGIT

Standard operating procedures

There needs to be an infrastructure provisioned in the cloud for setting up the demo environment. This will have the minimum configurations to start with and it can be scaled up based on the volume of usage. This instance is to be up and running 24 hours on all days (exception only when the upgrade happens). SMS server to be configured with sufficient credits so that OTP will be made available for citizen login.

When to upgrade

The upgrade should be done ideally after one week of release and before the release webinar. Normally DIGIT will have one release per quarter; this way the upgrade will be a once in a quarter affair. However, if there are critical patch releases done, the same needs to be replicated in the demo environment too.

Ownership

Below listed are the teams involved in upgrading and maintaining the demo instance -

• Product Team - They are the primary owner of this instance. They will provide the master data to be loaded into this instance. Localization keys, SMS templates and workflow configurations are to be shared by the product owners.

• Technical Team (Engineering and Implementation) - Set-up, configuration and ongoing upgrades are done by this team. To start with one person from the engineering and implementation team. These two will be coordinating all the communication related to the upgrades with other teams.

• QA Team - One QA engineer will be aligned for this environment qualification.

• DevOps Team - Any infrastructure and secret key related tasks for the set-up and upgrade will be done by this team.

• Partnership Team - All communications to the external stakeholders like notifying the demo instance downtime and upgrade completed are done by this team.

• Documentation Team - This team will help in updating the website with the downtime

Communication process

Once the engineering team announces the DIGIT release officially, the partnership team is informed about the tentative dates for the demo environment upgrade. They will communicate the same with the partners and get a formal buy-in from them. In case the partners have some critical demos to be done on the proposed dates, eGov is open to pushing the upgrade for a couple of days.

Once the upgrade dates are agreed upon, the digit website will be updated with the downtime information. Generally, it will take one week to upgrade and certify the same. All the teams involved in this process are informed about this activity upfront, for better planning.

How to upgrade

The demo environment is configured for two tenants majorly- City A and City B. Owners from the engineering team and implementation team will do the following-

• Follow the respective release notes published on the website and make all changes mentioned. 

• All master data and configurations will be done as per the instruction of the product team.

• Before deploying the new builds take a snapshot of the existing images and take a backup of the database.

• If any new SMS are introduced, then template to be received from the SMS provider and append with localization keys.

• If any secret keys are required as part of the upgrade, then the DevOps team will help in managing the secret keys in the configuration
  

Once the builds are upgraded, the designated QA engineer is supposed to do the following-

• Load the localization and workflow data as per the release notes, using the standard set of APIs.

• Do sanity testing of all the modules. The test cases published as part of the release needs to be used for the qualification. All modules have to be tested using both City A and City B using both English and Hindi. This is to ensure that all the configurations and master data are properly loaded for both tenants. 

• Before handing over for product sign off, they are expected to test the demo credentials creation utility feature available on the digit website.

Timeline- Upgrade tasks including the QA are supposed to be completed within 5-8 days.

Once the environment is certified by the QA team, it is communicated to the product team for functional sign off. 

The product team is expected to do the following-

• Check the functional flow of all modules

• Check the master data loaded are appropriate

• If there are any major bugs or issues uncovered at this stage, this needs to be filed in Jira and the same has to be informed to the responsible parties from the technical team.

Timeline- Product sign off for all modules should not take more than 2-4 days.

Once the product owners sign off, the partnership team is informed about the completion of the task which is then communicated back to the partners. The downtime message from the digit website will be removed by the documentation team. Validate access digit link.

Dos and Don’ts

1. City A is earmarked to be used by the eGov team, primarily the product team, for giving demos to clients and partners. 

2. City B is to be used by all external stakeholders. When someone registers for user credentials from the website, credentials are created for this user under City B.

3. No data from City A and B is to be deleted as part of the upgrade.

4. City A credentials are not to be shared with the external stakeholders

5. At any point, the demo environment is supposed to be working seamlessly with City A and City B in both English and Hindi.

6. Any bugs or issues reported by the internal and external team are logged in the engineering Jira account. These bugs will be either fixed in a patch release or the upcoming major release, based on the severity of the bug.

7. SMS pack to be renewed periodically to ensure the OTP delivery is not impacted at any time.

8. A retrospective of this entire exercise will be carried out by the responsible folks from the engineering and implementation team who is driving this. This includes the list of slipped defects and the reason for the same. The report of this is shared with all the stakeholders involved in this activity.

9. No deployment or changes in master data should be done without the knowledge of the product team.

10. User deletion or deactivation should not happen in CITY A without the knowledge of the product team. Also, any existing user’s details should not be modified without approval.