Desktop Release Procedures

Key things to know

• Final release is available and announced the morning of the 15th . If the 15th falls on a Friday, or a weekend, the release date should be adjusted so that it doesn’t put our customers or our support teams in a difficult support position with a weekend or holiday release.
• Final ECR cutoff for release is generally by noon on the business day before the release
• Final ECR cutoff should be communicated to the teams at least 3 days before cutoff
• Alpha Test Needed ECRs should be reviewed and communicated to the team beginning at least a week before final cutoff
• ECRs that are to be included on the Release Notes must be fully documented in the ECR Release Data tab, and should not be released if they are not fully documented

Review ECRs that need to be tested – One week before release, and throughout the week of release

1. ECR Report - Run the list of ECRs that need Alpha Testing, handle any discrepancies and ‘lost’ ECRs, and share the list of ECRs in danger of not making the release cutoff.
   • Asset Tag should be ‘ADJDESK’
   • ‘Alpha Test Needed’ should be checked
   • Requested Start Date should be the previous month of the previous year to catch any outliers (i.e. if you are prepping the 08/2017 release, use ‘07/01/16’
   • Complete Status should be ‘Complete’
2. Review the list for issues and anomalies, and clean up as many discrepancies as possible.
   • Some ECRs in the list may still be in development with minor issues that have not been resolved. No action is needed.
   • Some ECRs may have been tested and released in a previous month without the ECR getting completed properly. Review carefully, confirm any questions with development, and manually fix the ECR so it will not keep showing up in the list.
   • Some ECRs may be internal/ABIS-only changes that can be completed and marked as Exclude RN.
   • Some ECRs may be for services, wireless warehouse programs, integration code, etc. that are handled directly with sub-programs. These may be able to be manually completed. Check with development if unsure.
3. The remaining list should be shared with the teams to encourage testing and completion as soon as possible.
4. Request, review, and share this list with the teams again as the final cutoff approaches.

Review ECRs that are marked for release – A few days before release cutoff

1. ECR Report – Run the list of ECRs that are fully tested and will be included on the release.
   • Asset Tag should be ‘ADJDESK’
   • ‘Alpha Test Comp, But Not Moved’ should be checked
   • Requested Start Date should be the previous month of the previous year to catch any outliers (i.e. if you are prepping the 08/2017 release, use ‘07/01/16’
   • Complete Status should be ‘Complete’
   • ‘DocComp’ Should be ‘No’ to return all ECRs that have not been approved for release yet (marking Doc Complete in the Release Data tab ‘approves’ the ECR for release).
2. Review this list for issues that will affect the quality of the release.
   • Doc Comp must be checked for any ECRs that are going to be included on the release. The Doc Comp flag can generate customer emails, so make sure that the release write-up details are complete before setting the flag. Review the write-up, setup options, rule maintenance, and Wiki entries for accuracy and completeness. Forward each ECR that needs documentation completed back to the ECR submitter and any testers asking that the Release Data get completed, or that the ECR get marked as Exclude RN.
   • Exclude RN should be checked for all ECRs that are NOT considered enhancements and should be kept off the Release Notes. These ECRs should also have the Doc Comp box checked so that the final release filters work.
   • ECR Module should be filled in for all ECRs. It is critical for ECRs that will be included on the Release Notes, and it is helpful for future research even on ECRs that are Exclude RN.
   • Program/Process should be a simple, short description of the screen/report/feature affected – not a summary of the change requested. Edit as needed.
   • Preview the list using the ‘RELEASE MODERN’ form to look for typos, missing information, Wiki Link issues, and any other issues that would affect the quality of the Release Notes. Flag the ‘Exclude RN’ check box in the Results grid to show only the enhancement ECRs.

Perform a check for ECRs that are not marked Dev Complete - A few days before release cutoff

1. Run the same report selects used to generate the list of ECRs marked for release (prior step), but leave the Complete Status filter empty.
2. Any ECRs that show on this list have gone through development, and internal testing, but will not get set for release because they have not been marked complete.
3. Review any ECRs that show up with Development. The typical resolution is to have them marked complete, but there are other reasons why these ECRs may be kept off the release.

Perform a final review of ECRs that need testing and ECRs ready for release – Day before final cutoff

1. Run the two reports above and clean up the lists as much as possible.
2. Any enhancement ECR without Doc Comp should be excluded from the final release until the ECR is fully documented. The ‘Doc Comp’ filter should be set to ‘Yes’ for the final list.

Create the Final Move List – At final cutoff time

1. This will be the list of all ECRs that are included on the monthly release. Run the Alpha Test Complete, But Not Moved list.
   • Asset Tag should be ‘ADJDESK’
   • ‘Alpha Test Comp, But Not Moved’ should be checked
   • Requested Start Date should be the previous month of the previous year to catch any outliers (i.e. if you are prepping the 08/2017 release, use ‘07/01/16’
   • Complete Status should be ‘Complete’
   • DocComp filter should be set to ‘Yes’
2. Make sure the Exclude RN box IS NOT CHECKED for this report.
3. Review the list for completeness and accuracy. Email the list using the ‘MOVELIST’ form to yourself. Forward that email to David with comments that this is the final move list for the monthly release. Include any timing needs (if needed) so David can plan his work.
4. David will create the release build and share the build number back to you.
5. Safety Check If you leave the list generated by this step open and minimized, it can act as a safety check to verify that the number of ECRs doesn’t change from this moment to the moment you create the Release Notes and update the final build info.

Update all ECRs with the Build Info – When the release is ready to go live

1. Once you receive the build info from David, the release version has been created, and is ready to have all selected ECRs included on the release version.
2. Using the same ECR Report filters used to create the move list (previous step), generate the same list of ECRs. If there are any differences between this list and the move list, stop and reconcile the differences.
3. In the ECR Report Results tab, select ‘Upd Build Info’ and fill out the Alpha details. BE EXTREMELY CAREFUL in this step. It is a one-shot chance. Once the build info is set, it can’t be easily changed.
   • Check the Update box next to Alpha
   • Fill in the EXE # from David’s email (format is YYMM of release)
   • Fill in the Build# from David’s email and remove any suffix – just the number should be entered (triple-check and confirm with David if you have any doubts)
   • Click Update
4. It is important to note that once this step is complete, all Adjutant users will be able to see the new release available in the End User Update screen.

Generate the Release Notes document – After all Build Info has been set

1. It is important that this step happens after the Build Info has been updated, because the Build Info is printed on the Release Notes. We never want to send out Release Notes with incorrect build details.
2. Run the ECR report to select all ECRs in the build that just got established.
   • Alpha/Beta Test Status should be set to ‘None’
   • Complete Status should be ‘Complete’
   • Enter the same EXE # value in both boxes for Exe Build (it is a range select)
   • Enter the same Build # value in both boxes for Build Number (also a range)
3. Perform a final review of this list. You still have an opportunity to edit any Release Data or Module/Program details before creating the Release Notes.
4. Check the ‘Exclude RN’ box in the Results tab. This will prevent non-enhancement ECRs from showing up in the Release Notes.
5. Sort the list by Module. The Release Notes form uses the grid sorting to generate the report. We always want the Release Notes to be grouped by Module. There should be no empty Module values by this point.
6. Email the report to yourself using the ‘RELEASE MODERN’ form and save the file in the same format every time (i.e. ‘1708.9999.PDF’). Follow the file naming conventions from the Wiki Release Notes page links as a guide.

Generate the ECR List by Customer email and send to consultants document

1. With the ECR List still loaded from the previous step, re-sort the list by Organization, and un-check the ‘Exclude RN’ box.
2. Email the report to the ‘Consultants’ distribution list. Update the subject line to ‘ECR List by Customer – Month DD Release’

Update the Adjutant Desktop Release Notes Wiki

1. Upload the PDF for the current release to the current year’s Release Notes folder using the File Management tool in the Wiki. Upload the file using the correct file naming convention.
2. Edit the Wiki page for the current year’s Release Notes to add the current month.
   • Copy and paste the previous month’s line to the top of the list
   • Update the Month label
   • Update the file name link details
   • Update the version details

Mass-Email the Release Notes to subscribed users – Early in the morning of the 15th

1. Log in to Mail Chimp and select Campaigns.
2. Using the most recent Release Notes campaign, select Replicate. (the option shows up in a drop-down list when you hover to the right of the campaign)
3. Update the Campaign Name to reflect the correct release details and remove any “(copy 01)” garbage.
4. Edit the release details and date in the email body (an ‘edit’ box should be visible when you hover over the preview). The edit screen will be in the right-hand pane.
5. Edit the hyperlink for ‘Click here to download the PDF’ by double-clicking the link. Copy and paste the direct link to the current month’s release PDF document from the Wiki. The link should open the PDF directly, not just go to the Release Notes page. Triple-check that this link is correct, then Save your changes and close.
6. On the next screen, edit the Pain-text email line.
   • Select Regenerate from HTML
   • Hit Save
7. Select Send and follow the prompts to Send the email to all the subscribed customers. You can’t stop or change the email once it has been sent. Be sure you have reviewed carefully!