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 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.
- 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 this.
*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
- 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: 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).
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.
- Developer must re-deploy the work-in-progress. To do this, the easiest way is to: (wip)
- Update the Copado User Story Credential to the upper environment (this is temporal, for example), for each of the user stories that are work-in-progress**
- Execute a back-promotion from the upper environment to the specific dev org being restored, which includes the user stories that need to be restored in the dev org
- Revert the change of the Copado Credential and set again the original dev org credential
- For example, if I have StoryA and StoryB, that are currently in DevMonthly org, I can update the copado credential of these 2 copado records to MonthlyInt, run a backpromotion including these 2 stories from MonthlyInt to DevMonthly, and then upon successful back promotion, I can update again these 2 stories records to have the DevMonthly credential.
- Note: Other approaches can be seen in https://docs.copado.com/articles/#!copado-ci-cd-publication/how-to-push-work-in-progress-back-to-refreshed-org
TODO: Add estimation on required time for this.
*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