Table of Contents

Environment refresh events

• Bugfix: from 18th to 22nd July, a new BugFix org will be generated. This won’t have any impact if a bug needs to be fixed during these dates, as we will keep the current bugfix org (weekly org).
• Dev Sandboxes: from 22th to 24th of July, the refresh for the developer sandboxes (including projectInt) will be taking place, and therefore the Dev Orgs will not be functional. Almonds release has been updated and the scope closure will be on 19th, therefore developers won’t require developer sandboxes for Almonds build. During the days 22nd and 23rd, as the developer sandboxes won’t be available, we recommend dedicating time to non-development tasks, such as spike, documentation, or others.
• INT: From 22nd to 24th, INT refresh will take place, therefore it won’t be available during these dates. There is no impact as the release calendar does not include any INT testing or validation during these days.
  
• UAT: From 25th to 29th, refresh will take place, therefore it won’t be available during these dates. There is no impact as the release calendar does not include any UAT testing or validation during these days. We recommend Business to be informed about UAT unavailability, if you think is relevant.

Timelines and orgs are as well included as part of the release calendar.

       Image Modified

Required actions from developers

As the last part of the refresh, the work in progress (which refers to user story changes that have never been deployed from the developer org to upper environments) will need to be restored. It’s required for developers to take care of the restore for developer orgs (including WeeklyInt and MonthlyInt), while Release Managers will take ownership of the rest.

Actions for developers will be required before and after the refresh, see below for Gitlab (CORE) or Copado (ICARE).

Gitlab - Restoring work in progress

Release Manager required actions

From 17th and 29th of July (see release calendar for the dates on which each kind of sandbox refresh will be taking place).

• Refresh the different orgs and the different tasks that this implies, as indicated in the above tables
• Recreate org branches (for all refreshed sandboxes) from master
• Merge release branches (containing user stories that were in INT or UAT but not in production) into the respective org branches, following the next approach:
• Bugfix: retrofit master branch, which contains the latest monthly (jalapeño) and weekly, this has to be done after friday 19th weekly release to production.
• WeeklyDev & WeeklyInt & UAT:  latest bugfixes branches, latest weekly branch (not monthly branch of almonds)
• MonthlyDev & MonthlyInt & INT: latest bugfixes branches, latest weekly branch, latest monthly branch

Developers required actions

By Friday 19th (before Dev sandboxes refresh):

...

1. (Simplest) - If the work in progress is tracked in a local IDE such as VSCode, or IntelliJ, the developer can simple redeploy only the specific components (important to not redeploy the whole application).
2. (Using Gitlab branches) - Developers must re-deploy the work-in-progress by deploying the feature branches where the changes have been committed before the refresh. If any pre-post deployment step is required, the developer can as well read and execute these from the Jira fields.

TODO: Add estimation on required time for thisApproximate 1 day of developer work required for post-refresh restore of work in progress.

*Developer orgs are BugFix, Weekly_Dev, Weekly_Int, monthly_int and monthly_dev.

...

***Non-developer orgs are INT and UAT

Copado - Restoring work in progress

Release Manager required actions

From 17th and 29th of July (see release calendar for the dates on which each kind of sandbox refresh will be taking place).

...

(*) Note that another alternative is to create a dummy temporary credential, which in the pipeline is positioned just before the org where we need to re-deploy the user stories, and use it as a temporary source org for the deployment.

Developers required actions

By Friday 19th (before Dev sandboxes refresh):

...

(*) Note that this is a temporary credential used only to restore the work, nothing has to be done in this temporary org, only the release manager will set it up in Copado to facilitate the restore of work in progress to the developer org.

TODO: Add estimation on required time for thisApproximate 1 day of developer work required for post-refresh restore of work in progress.

*Developer orgs are BugFix, Weekly_Dev, Weekly_Int, monthly_int and monthly_dev.

...