Versions Compared

Old Version 35

changes.mady.by.user Samuel Valdez (Unlicensed)

Saved on

compared with

New Version Current

changes.mady.by.user Samuel Valdez (Unlicensed)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

3 - Create a Bitbucket issue to track the activities for a particular release.  Issues #255 and #264 EAS-255 and EAS-264 are good examples of this.  Then update the link in the section The Next Release above.

...

6 - Notify DBI staff by email of the proposed release date, and the proposed contents of the release.  Give DBI staff at least two weeks of lead time because both IT, and Central Permit Bureau, staff must respond.  The email should be addressed to DT-EAS-DBI-Staff and CC-ed to DT-EAS-Support.  Examples of this email were sent on 111/7/2018 2019 2:10 45 PM, and 1/728/2019 210:45 PM21 AM, and can be found in Outlook's Sent Items, or Deleted Items, folders.

NOTE: This will impact operations at DBI's Central Permit Bureau because the EAS will not be available for address creation and maintenance during the release.

7 - Draft a version deployment details (VDD) page for the new release by copying a completed VDD page.  The "draft status" of the draft VDD page can be indicated by inserting the following text (and formatting) directly below the table of contents: *** THIS IS A DRAFT AND IS NOT COMPLETE ***

...

9 - After approval of the proposed release date by DBI staff has been received, create a Change Request in ServiceNow at least two weeks prior to the release date.  The Change Request number will be included in the announcement that will be sent in Step 13.  Example change requests that can be used as a model for the new one include CHG0103391 and CHG0103523.

10 - Create a release meeting in Outlook to reserve the time for the release team members.  An example of this meeting invitation was sent on 1/17/2019 3:37 PM, and can be found in Outlook's Sent Items, or Deleted Items, folders.

11- Create a release planning meeting in Outlook for the release team members.  An example of this meeting invitation was sent on 1/17/2019 1:27 PM, and can be found in Outlook's Sent Items, or Deleted Items, folders.

12 - Create a placeholder meeting in Outlook to set the time aside for DBI staff whether or not they will participate in the release activities.  An example of this meeting invitation was sent on 1/17/2019 4:09 PM, and can be found in Outlook's Sent Items, or Deleted Items, folders.

13 - Some time during the week before the release date, say on a Wednesday, email a formal announcement of the upcoming release to the larger EAS community.  The email should be addressed to DT-EAS-User-Group and CC-ed to DT-SFGIS-User-Group.  Examples of this email were sent on 12/5/2018 5:41 PM, and 1/10/2019 11:09 AM and 2/11/2019 12:48 PM, and can be found in Outlook's Sent Items, or Deleted Items, folders.

14 - At the same time that Step 13 is performed, the announcement will be sent to the All Company group on Yammer because a Yammer account (DT-EAS-Yammer) is included (and buried) in the DT-EAS-User-Group email distribution group.  The sender of the announcement from Step 13 will receive an email from Yammer asking whether to post the email to the All Company group in Yammer.  Click the Post Message button that is in the email, and when the posting is shown in your Web browser, edit this raw posting by clicking the "EDIT" icon at the bottom of the post.  Editing at this point will consist of cleaning up the links and the layout of the post.  Examples of edited Yammer posts are from December 5January 10, 2018 2019 at 712:42 04 PM and January 10February 11, 2019 at 12:04 53 PM.

...

16 -If any consultants are going to participate in the release, then ask them to verify their VPN connectivity to all of the relevant machines during the week before the release.  This will allow about one week to fix and test any issues that may be discovered.  SER0210791 is a good example of a service request to extend the VPN access of an SFGIS consultant.

17 - Re-send the announcements that were sent in Steps 13 and 14 on the Tuesday before the release (assuming a Friday release).

18 - EAS code freezes generally occur on the Tuesday before the release (assuming a Friday release).  When an EAS release candidate has been identified, deploy it to the EAS QA environment (SF QA *) on the day after the code freeze.

19 - Formally qualify the release candidate in the EAS QA environment per the instructions that are here a day or two before the release.  Store the test results in the (artifact) directory that is specified in the Bitbucket issue that was created in Step 3.

...

  If the release candidate was not successfully qualified, then proceed to Section 5 below, Cancel the Release.

...

  • Find the comment in the issue that should be pinned to the top, and then pin it.
  • Update the value of the "Actual: " milestone that is in the issue's description, for example, with "2019-02-12-A".
  • Update the version of the issue to the version of this release, for example "1.3.8".
  • Update the milestone of the issue to "---------" (none).

21A - Visit every issue that was not resolved in every milestone that is part of this release, and perform the following tasks.  This is the first step in rolling these issues into a future milestone:

  • Insert the value of the "Target: " under the last targeted milestone that is in the issue's description.
  • Update the milestone of the issue to "high", "medium", or "low".  The most likely choice is "high".

22 - Update the Sprints and Product Releases table for all of the milestones that are in this release with the new information (see the lists of table columns below), ideally on the day before, or of, the release.

  • Actual SV, Actual DK, Actual Total
  • Difference SV, Difference DK, Difference Total

23 - During the morning of the release, the person who will perform the release, and their backup, should verify their VPN connectivity to all of the relevant machines.

24 - On the day of the release, re-send the announcements that were sent in Steps 13 and 14, for the last time, and preferably in the morning.

...

25 - A few minutes after the scheduled start of the release, send an announcement that the release is about to begin.  The email should be addressed to DT-EAS-User-Group and CC-ed to DT-SFGIS-User-Group.  An example of this email was sent on 1/18/2019 3:05 PM, and can be found in Outlook's Sent Items, or Deleted Items, folders.

26 - Follow the instructions that are in the release's draft version deployment details page that was created in Step 7 above, and edit them as needed.

...

27 - Send an announcement, that is analogous to the one that was sent in Step 13 above, that heralds the successful release.  The email should be addressed to DT-EAS-User-Group, and CC-ed to DT-SFGIS-User-Group and DT-EAS-New-Release-Announcement.  This is related to issue #234.  An example of this email was sent on 1/18/2019 6:02 PM, and can be found in Outlook's Sent Items, or Deleted Items, folders.

28 - Complete the change request that was created in Step 9 above.

29 - Update the Bitbucket issue that was created in Step 3 above by setting the version of the issue to the version of this release, for example "1.3.8", and then close the issue.  Do not forget to find the comment in the issue that should be pinned to the top, and then pin it.

29A - Close every issue that was resolved in every milestone that is part of this release.

...