CAF to DDS Delivery Flow

Overview

This document describes the flow from the time a new CAF is signed to the delivery of a DDS.

Completed CAF - Found in Lotus Notes Workspace/US CAF Workspace

1. CAF has been signed by Contracts Admin/Sales/Engineering Director/Management
2. Code name has been assigned and content defined/confirmed by Engineering Director
3. Release coordinator is notified of new customer CAF by Engineering Director or Project Manager

• TODO - define generic project model

Create new customer program page in ProjectManager

1. Project is created in ProjectManager by the Project Manager.
2. New customer is added to Active Customers list in Customer&Sales by Project Manager.

• TODO - confirm other activities associated with setting up a new customer.

Create new customer accounts, wiki pages, and DDS

The following tasks are completed by the release coordinator

1. Create Upload and Screencast accounts
2. Create Project wiki using information from CAF
3. Create customer package using information from CAF
4. Build DDS
5. Create release wiki

Testing DDS

1. Testing requests sent by release coordinator
   1. OA testing is done per table in the release wiki
   2. Manual testing is performed by engineering per table in the release wiki
2. OA test report created and notification of completion sent to release coordinator and QA by OA team
3. Manual test report created and sent to release coordinator by Engineer performing test

Finalize Release Wiki

The following tasks are completed by the release coordinator

1. Confirm all links e.g. Test Report, Release Notes, OA test report
2. Verify final content is correct
3. Notify QA release is ready

QA Activities

The QA Reports are being added to the Release Wiki pages as an improvement to consolidate where information for a release is located.

The following tasks are completed by QA.

Review OA test report

1. OA sends QA/PLPLM an email when testing is completed
2. From the OA test email, QA clicks on the link to Release Wiki and/or OA Testing Wiki Page
3. QA reviews OA report for DDS name, timestamp and known issues

Review of DDS

1. Copy DDS to //nx3000/qa - follow instructions in Lotus Notes:PTC Computer Operations:QA Rollout Procedure. Login using QA credentials.
2. Change permissions on DDS by running ../perms2.sh
3. Evaluate the distribution. The following questions need to be answered:
   1. Does the product install?
   2. Does hello-world work as documented?
   3. Does editing work?
   4. Does uninstall work?
   5. Is the documentation up to date and consistent?
      1. Does the timestamp in the cover letter match what is documented on the Release Wiki and OA report?
      2. Does the version of OA in the cover letter match the version in the OA report?
   6. Does the distribution actually contain what the "paperwork" says it does in terms of components and versions?
      1. Perform diff -rq between last approved release and this one.
      2. Review the diff result to verify difference match documentation on the Release Wiki.
   7. Run find_broken_links.py on all media level documentation.
4. Document results in QA Report and add to the Release Wiki.
5. Once approved, copy to //nx3000/ship/dds/windows/approved
6. Notify release coordinator DDS available to ship

DDS Tsunami

The steps documented above need to be performed on the Sales DDS. The following steps need to be performed on the following releases not requiring additional OA testing:

1. Copy DDS to //nx3000/qa - follow instructions in Lotus Notes:PTC Computer Operations:QA Rollout Procedure. Login using QA credentials.
2. Change permissions on DDS by running ../perms2.sh
3. Evaluate the distribution. The following questions need to be answered:
   1. Is the documentation up to date and consistent?
      1. Does the timestamp in the cover letter match what is documented on the Release Wiki and OA report?
      2. Does the version of OA in the cover letter match the version in the OA report?
   2. Does the distribution actually contain what the "paperwork" says it does in terms of components and versions?
      1. Perform diff -rq between last approved release and this one.
      2. Review the diff result to verify difference match documentation on the Release Wiki.
   3. Is testing sufficient (e.g., if no additional testing, is it documented?)?
4. Document results in QA Report and add to the Release Wiki.
5. Once approved, copy to //nx3000/ship/dds/windows/approved
   1. cd /dev/fs/D/userdata/unix
   2. mv qa/dds/windows/dds... ship/dds/windows/approved
6. Notify release coordinator DDS available to ship

Sample QA Report

Sample QA Report

Ship to Customer

The following tasks are completed by the release coordinator

1. Zip the DDS from the //nx3000 ship area using the following command: zip -r DDS-ddsname DDS-ddsname or
   tar -cf <dds-docker-image>.tar --group=root --owner=root --mode=go-w,a+rx -C //nx3000.ddci.com/ship/dds/ubuntu/approved/DDS-docker-<name> .
   
2. Release to customer
3. Update release wiki to completed
4. Update Project wiki milestone to done
5. Update Project on Project Manager

Ted will follow up with a license file for new customers. Currently, the same license works for Windows and Linux distros, but the license server must be Windows-based.

Rationale for no -j or -J: The vast majority of the content is a docker image which is compressed using .xz so compressing again is a time sink and can actually increase the size of the image.

NOTE: The tar command *MUST* be executed from a Cygwin shell in order to ensure that the "mode" on the script files is set properly. The files going into the tar file are on a windows share which does not properly encode the "mode", but Cygwin has special hacks to ensure that files with shebang lines get set to the equivalent of chmod a+x.