1.3.8 Release Checklist

Owned by Samuel Valdez (Unlicensed)
Last updated: Feb 16, 2019

1 The Next Release

The next release of the EAS is version 1.3.8.

2 Pre-release Activities

Begin performing the activities below at least two to three weeks prior to the proposed release date.


1 - Select a release date and time (typically on a Friday during the late afternoon), and confirm that staff will be available to perform the release.

2 - Re-set all of the names and dates that are in the tasks below.  It may help to start with the later steps and work backward.

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

4 - Ensure that the EAS roadmap is current because that information will be referenced on the page that will be updated in Step 5, and in the announcement that will be sent in Step 13.

5 - Update the Sprints and Product Releases page with the new release information.

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 1/7/2019 2:45 PM, and 1/28/2019 10:21 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 ***

      Finished examples of version deployment details pages include 1.3.5, 1.3.6, and 1.3.7, though the layout and content continues to evolve. The link to this VDD will be pasted in to the Implementation plan field of the change request that will be created in Step 9.

8 - Create a reminder meeting in Outlook so that release team members will be reminded to check this page every day, leading up to the release date.  An example of this meeting invitation was sent on 1/25/2019 8:47 PM, and can be found in Outlook's Sent Items, or Deleted Items, folders.

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 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 January 10, 2019 at 12:04 PM and February 11, 2019 at 12:53 PM.

15 - Because the DT Change Advisory Board meets on Thursday mornings, and the EAS is typically released on a Friday, it is better to attend the two DT Change Advisory Board meetings prior to the release so that the timing of the release is less "surprising" (the next day) to the DT Change Advisory Board.

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.

20 - If the release candidate was successfully qualified, then apply version tags to the qualified changesets of the eas and sfeas_config repositories.  For each repository, note the changeset to which the tag was applied, not the new changeset that was generated because of the new tag.  Capture these changesets in the release's draft version deployment details page that was created in Step 7 above.

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

21 - Visit every issue that was resolved in every milestone that is part of this release, and perform the following tasks.  This will allow us to create a succinct query to show which issues were resolved in this 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.

3 Version Release

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.

4 Post-release Activities

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".  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.

30 - Congratulations!  The new version of the EAS has been successfully released!

5 Cancel the Release

If the release candidate was not successfully qualified in Step 19 above, then cancel the release by performing the following steps:

31 - Email a formal announcement of the release cancellation to the larger EAS community.  The email should be addressed to DT-EAS-User-Group and CC-ed to DT-SFGIS-User-Group, and sent at least one day before the announced release date.  One example of this email was sent on 12/13/2019 12:47 PM, and can be found in Outlook's Sent Items, or Deleted Items, folders.

32 - At the same time that Step 31 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 31 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.  One example of this kind of an edited Yammer post is from December 13, 2018 at 1:01 PM.

The release of the new version of the EAS has been successfully canceled.