Releases

Backend Services

Before starting a release, please open a Back-End Release issue and append it to the Development Board with the appropriate Sprint/Iteration. Update the release issue as you make progress through the release.

Step 1: GitHub Release

1. The first step is to tag the branch (main) from which the image will be built.
2. The tag can be created as part of the GitHub Release UI

3. When you create a tag in the format v* (for example, v7.1.2), a GitHub workflow will trigger to build and push an image to AWS ECR.
4. Select the branch that the tag will be attached to and add a release title
5. Please always click on the Generate release notes buttons to have GitHub create the release notes based on the commit messages added between the last release and this one
6. Then click Publish release to start the workflow that will build out the image and push it to AWS ECR

Step 2: Create Snapshot Backups

1. Before deploying new releases to the production environment, you should create snapshots of the databases in case the release requires a rollback.
2. To do this on the AWS console, go to the RDS service and click on DB Instances under Resources.
3. There are currently three instances to create snapshots for: customers, services, and postgres.
4. Create a snapshot for each of them by selecting the database and selecting Take snapshot.

5. Create the snapshots with names in the format <db-name>-<current-date>-<current-time> (e.g., esp-customer-8-25-12-25-1453).
6. Wait for the snapshots to be created and then move onto the next section.

Step 3: Create Task Definition & Deploy

1. The next step is to create the task definition for the service you are going to release.
2. A task definition is how AWS defines the blueprint to build your application in ECS
3. Usually, this just means updating the image URI used in the task definition.
4. First, go to Elastic Container Registry (ECR). Here you should see the image you created in Step 1 at the top of the list.

1. Select the image and then click Copy URI. This will be pasted in when we update the task definition.
2. Next, go to Elastic Container Service (ECS) and click on Task definitions in the left-hand tab.
3. You will see a list of all task definitions; we have task definitions for each tenant and for each central service.
4. This means if you want to perform a rollout for the customer tenants, you need to update the task definition for each individual tenant.

Important : Steps 5 to 12 have to be repeated for each customer tenant that you want to update

5. Click on the service you wish to update.
6. From here, click Create new revision, and then select Create new revision again.

7. In most cases, we are only going to be updating the Image URI that we copied before. Paste the Image URI here, scroll down to the bottom of the page, and click Create.

8. From here, go back to the Elastic Container Service and click on the service for the task definition that you have just updated.
9. Then click on Update Service.

10. Click on the Revision dropdown and select the task definition revision you just created. This will be marked with 'Latest'.

11. Scroll down to the bottom and click Update. This will trigger the new deployment.
12. You can monitor the deployment's progress from the previous page. From there, you can check the logs and see if the container deploys successfully.

Frontend Applications

This section will cover the process of releasing a new version of a frontend application.

• Platform APP - *.own.esprofiler.com
• Vendor Portal - vendor.capability.exchange
• Account Portal - my.esprofiler.com

Before starting a release, please open a Front-End Release issue and append it to the Development Board with the appropriate Sprint/Iteration. Update the release issue as you make progress through the release.

Step 1: Production Build

1. Ensure all code intended for production release is merged into the main branch.
2. Navigate to the repository, and while on the code tab, click tags found to the right of the branch selector.
3. Click the releases button, then click Draft a new release button.
4. Click on Select tag dropdown and at the bottom of the list, click Create new tag, in the prompt enter the version number, vX.X.X and click create.
5. For the Taget field, the main branch should be selected by default.
6. Enter a release title Release vX.X.X
7. (Optional) Under Release Notes select the previously released version tag that comes immediately before this new tag if you don't trust the default Auto option (I don't).
8. Click Generate Release Notes -- this will populate the Release Notes field with the commit messages since the last release.
9. Scroll down to the bottom of the page and click Publish Release, this will trigger the Publish Tag workflow where it should be visibily running in Actions.
10. Once the workflow completes, this will have created a new tag and pushed the build application to AWS Bucket in a folder reflecting the version number.
11. Inform the backend team that the new version is ready for Production Tenant Rollout.

Step 2: Tenant Rollout

Currently the backend configures the frontend that the user will see for a given tenant

In order to update the version of the frontend the tenant is using we have to update the SPA property in the SPAProperties class in the platform-api repo.

In this case the frontend version is 3.9.7 to update it to, for example 3.10.0 we would replace the targetString value from v3-9-7 to v3-10-0

The backend release process then has to be followed for the change to take effect. Please see Backend Release.

Staging: Release Candidate

Upon merge of a pull request to main, a release candidate will be automatically built and deployed to staging.own.esprofiler.com.

Staging: Review Apps (TBC)

• When to use
• How to use

Frontend Websites

TBC