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.
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):
- For any developer org*, ensure that all changes belonging to work-in-progress** have been committed into the respective git branch (mainly feature branches). Changes that have not been committed will be lost after the refresh.
- If there is any pre-deployment or post-deployment manual task required for the work-in-progress**, ensure that it’s properly documented in the respective jira ticket using the “pre-deployment task” or “post-deployment task” fields.
After Tuesday 23th (after Dev sandboxes refresh):
Note: Before doing any of the next steps, the release manager should have completed the required actions for the developers orgs (the release manager has completed the retrofit), and this will be finished around 23th July. The reason of this is that in order that devs can safely redeploy the work-in-progress**, it’s important that first we restore the developer orgs with the user stories that were in INT or UAT but not in production, as there may be dependencies.
There are 2 ways in which the developer can restore the work in progress:
- (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).
- (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.
Approximate 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.
**Work in progress refers to changes that have not been deployed to any org, and this typically happens for user stories that are in the build phase, and changes are still taking place in the developer org.
***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).
- Refresh the different orgs and the different tasks that this implies, as indicated in the above tables
- Follow Copado documentation to update the Credential & Environment records https://docs.copado.com/articles/#!copado-ci-cd-publication/sandbox-refresh
- Restore all user stories in middle-environments, such as UAT:
- Do a SOQL Query of the user stories belonging to UAT. If we are doing this for INT, it should also include stories for UAT (as these also need to be deployed to INT because are not in production)
- Update the credential to a lower environment, such as INT (even though this does not mean that the story is in INT, this is only temporary)
- Create a Copado promotion from INT to UAT, which will re-deploy all the stories to UAT
- Make sure that the user stories have the same status as before re-incorporating them into the org
- Restore user stories of upper environments into dev orgs, such as INT and/or UAT (depending on the org, by looking at the pipeline). Note that this includes weeklyInt, monthlyInt, Bugfix.
- Run a mass-back promotion of the user stories in INT & UAT to the lower environments
- Note that back promotion should appear as available for these stories, given that the previous back promotion should have status "outdated", however, if the back promotion does not appear as available, we can delete the previous back promotion records and force it to appear.
- 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 for Copado:
- Bugfix: Will maintain Bugfix and Bugfix_old (weekly to be renamed) pointing to UAT, work done in Bugfix_old and move to UAT will be backpromoted to Bugfix
- MonthlyDev & MonthlyInt & INT: We take all user stories of Almond, latest weekly, latest bugfixes and the previous weekly release, we temporarily update the credential to WeeklyInt(*), we promote all to INT, then backpromotion will be available for WeeklyInt and therefore WeeklyInt. Be mindful that after the redeployment & backpromotions, we need to restore the original credential per each user story (that we got using SOQL). The risk is that during this operation a developer building samosa requires any dependency from Almond that is backpromoted in this operation.
- WeeklyDev & WeeklyInt: & UAT: We take all user stories of latest weekly, latest bugfixes and the previous weekly release, we temporarily update the credential to MonthlyInt, we promote all to INT, then backpromotion will be available for WeeklyInt and therefore WeeklyInt. The only risk is that during this operation a developer building samosa requires any dependency from Almond that is backpromoted in this operation. Be mindful that after the redeployment & backpromotions, we need to restore the original credential per each user story (that we got using SOQL).
(*) 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):
- For any developer org*, ensure that all changes belonging to work-in-progress** have been committed into the respective Copado user story. Changes that have not been committed will be lost after the refresh.
- If there is any pre-deployment or post-deployment manual task required for the work-in-progress**, ensure that it’s properly documented in the respective jira ticket using the “pre-deployment task” or “post-deployment task” fields.
After Tuesday 23th (after Dev sandboxes refresh):
Note: Before doing any of the next steps, the release manager should have completed the required actions for the developers orgs, and this will be finished by 23th July. The reason of this is that in order that devs can safely redeploy the work-in-progress**, it’s important that first we restore the developer orgs with the user stories that were in INT or UAT but not in production, as there may be dependencies.
There are 2 ways in which the developer can restore the work in progress:
- (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).
- (Using Copado) - Steps are:
- Update the Copado User Story Credential to a temporary credential (provided by release manager) (*), for each of the user stories that are work-in-progress**. This temporary org credential will sit in the pipeline just before the developer org where the work-in-progress has to be restored.
- Execute a deployment, simply checking the field "Promote and Deploy" of each user story or creating a promotion to bulkify several user stories, from the source org (temporary dummy credential), to the specific dev org being restored
- Inform the release manager to delete the temporary credential from the pipeline as it's no longer required.
(*) 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.
Approximate 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.
**Work in progress refers to changes that have not been deployed to any org, and this typically happens for user stories that are in the build phase, and changes are still taking place in the developer org.
***Non-developer orgs are INT and UAT