Sprint testing (folio-testing-sprint)

The purpose of the Sprint testing environment is to validate the functionality implemented by development teams during the sprint (2 weeks).

According to the internal processes and flow Sprint testing environment should be provisioned/updated and read on the 2nd Wednesday of the sprint.

As this environment is based on the big dataset (Bugfest) we recommend for the DevOps team start environment preparation in advance on the 2nd Tuesday of the sprint.

Preparation (2nd Tuesday of the sprint)

1) Destroy the current environment (namespace)

First of all, we need to destroy the current revision of the Sprint testing environment. We expect that all testing-related activities have been finished to this date.

The purpose of this exercise (why do we need to destroy instead of just update?) is to validate all new functionality and migration in conditions close to the real customer process, when customer environments update from the previous release to the current one.

Example:

• R1-2023 → Snapshot (Sprint 170) - Correct
• R1-2023 → Snapshot (Sprint 169) → Snapshot (Sprint 170) - Incorrect

For namespace termination, we use deleteNamespace pipeline, more detailed reference we can find here Delete project/namespace

2) Run Data Migration pipeline

As mentioned above, the purpose of this activity is also to measure the time of backend modules migration (update) and schema validation to compare DB schemas in clean and migrated setup.

During this activity, we also should follow the same approach with versions. This means that we should run Data Migration pipeline to compare the previous release with the current one (Example: R1-2023 → Snapshot (Sprint 170)).

Result of running Data Migration pipeline:

• Schema Diffs Report
• Data Migration Time Report
• JIRA tickets if schema inconsistency

NOTE: In the development process

3) Provision environment (namespace) based on Bugfest DB snapshot

Provision Sprint testing environment from previous release Bugfest RDS snapshot (For example (R1-2023): opbf-bugfest-snapshot-04-12-2023).

Requirements:

• DB: RDS
• Kafka: Shared (AWS MSK). But also possible built-in with at least 50Gb of disk space and 2 brokers
• OpenSearch: Shared (AWS OpenSearch)
• Config type (For backend modules): testing or performance

4) Update to the latest previous release version

Generally, we take a Bugfest snapshot at the beginning of the release cycle (to avoid populating dummy and invalid data).

That is why we need to first actualize all module versions to the latest version of the previous release after environment provisioning and before upgrading to the current release version to include all hotfixes, etc.

For module updates, we use deployModulesFromJson pipeline, more detailed reference we can find here Deploy modules from json list

Example: R1-2023-GA → R1-2023-hotfix-2

5) Update to the latest current release version (snapshot)

At this stage, we update the environment to the latest current release versions of modules. 

For module updates, we use deployModulesFromJson pipeline

Example: R1-2023-hotfix-2 → snapshot

6) Run indexation

SEARCH_BY_ALL_FIELDS_ENABLED=true

Final update (2nd Wednesday of the sprint)

1) Update to the latest current release version (one more time)

We expect that it could be the situation that some development features have been merged in the morning or during the previous day, that is why we should update env one more time with deployModulesFromJson  pipeline to the latest current release versions (snapshot)

2) Create additional tenants

NOTE: In the development process

At this stage, we need to create some additional tenants (if required) with createTenant pipeline

For the current moment required tenants are:

• tenantId: aqa

Known issues

UPDATE fs09000000_mod_inventory_storage.call_number_type
SET jsonb = jsonb ||
  '{
     "name": "Dewey Decimal classification (local)"
   }'
WHERE jsonb->>'name'='Dewey Decimal classification';
UPDATE fs09000000_mod_inventory_storage.call_number_type
SET jsonb = jsonb ||
  '{
     "name": "Library of Congress classification (local)"
   }'
WHERE jsonb->>'name'='Library of Congress classification';
UPDATE fs09000000_mod_inventory_storage.call_number_type
SET jsonb = jsonb ||
  '{
     "name": "National Library of Medicine classification (local)"
   }'
WHERE jsonb->>'name'='National Library of Medicine classification';
UPDATE fs09000000_mod_inventory_storage.call_number_type
SET jsonb = jsonb ||
  '{
     "name": "Other scheme (local)"
   }'
WHERE jsonb->>'name'='Other scheme';
UPDATE fs09000000_mod_inventory_storage.call_number_type
SET jsonb = jsonb ||
  '{
     "name": "Superintendent of Documents classification (local)"
   }'
WHERE jsonb->>'name'='Superintendent of Documents classification';

INSERT INTO fs09000000_mod_inventory_storage.call_number_type(id, jsonb)
    VALUES ('fc388041-6cd0-4806-8a74-ebe3b9ab4c6e','{
  "id": "fc388041-6cd0-4806-8a74-ebe3b9ab4c6e",
  "name": "Superintendent of Documents classification",
  "source": "system"
}'), ('6caca63e-5651-4db6-9247-3205156e9699','{
  "id": "6caca63e-5651-4db6-9247-3205156e9699",
  "name": "Other scheme",
  "source": "system"
}'), ('054d460d-d6b9-4469-9e37-7a78a2266655','{
  "id": "054d460d-d6b9-4469-9e37-7a78a2266655",
  "name": "National Library of Medicine classification",
  "source": "system"
}'), ('95467209-6d7b-468b-94df-0f5d7ad2747d','{
  "id": "95467209-6d7b-468b-94df-0f5d7ad2747d",
  "name": "Library of Congress classification",
  "source": "system"
}'), ('03dd64d0-5626-4ecd-8ece-4531e0069f35','{
  "id": "03dd64d0-5626-4ecd-8ece-4531e0069f35",
  "name": "Dewey Decimal classification",
  "source": "system"
}');